Microsoft Dynamics CRM Team Blog: Enabling Kerberos for Microsoft Dynamics CRM 2011

[Blog bot]

Источник: http://blogs.msdn.com/b/crm/archive/...-crm-2011.aspx
==============

Evolution of Authentication Protocols

The Windows Challenge/Response (NTLM) authentication protocol (more here) is provided in Windows to address backwards compatibility. As initially implemented in the early days of computing, authentication was performed by using a challenge/response mechanism. For Microsoft Dynamics CRM, this meant that a client computer running Windows would initiate a connection to an application server by sending the username. The application server would in turn respond with a randomly generated number, which would serve as the challenge. The client computer would encrypt the challenge with a hash of the user’s password and return that response to the server. If the user credentials provided to the application server corresponded to the information maintained by the domain controller, then the user would be authenticated.

Beginning with Internet Information Server (IIS) 5.0, Microsoft included a faster, more reliable, and safer default security support provider, the Negotiate security package (more here). The Negotiate security package can use either Kerberos (more here) or NTLM, but it defaults to using Kerberos. Kerberos authentication is initially handled between the client computer and the application server. These are the first two nodes that do a little “security dance” (read more) to verify that each likes the Kerberos music. If either doesn’t work with Kerberos, the authentication protocol will default to NTLM.

Benefits of Using Kerberos

Kerberos has some key improvements over NTLM that make it the preferred method for authentication:

• Authentication is faster and requires less resources to complete
• Authentication is mutual, such that both the client and server can be requested to authenticate
• Kerberos supports authentication delegation (which is needed to run reports on a dedicated reporting server separate from the SQL server)
• Kerberos is an open standard
• Kerberos supports smart card logon and thus two-factor authentication

Overview of the Differences between NTLM and Kerberos

Authentication events are logged in the Security event log, which you can review by using the Event Viewer (Start, Run, ‘eventvwr’). The differences between NTLM-related security events and Kerberos-related security events are evident in a comparison of the following illustrations:



Figure 1. Logon Process: NTLmSsp



Figure 2. Logon Process: Kerberos

Moving to Kerberos

For deployments that are not using Kerberos as the authentication protocol, first determine whether the servers (IIS Security Configuration) are configured to support only NTLM, in which case you should configure additional authentication provider using the instructions below. If the servers are instead configured to use the Negotiate security package, which for one reason or another cannot take advantage of using Kerberos, review the configuration to identify why Kerberos authentication is failing.

Prior to developing a plan for enabling Kerberos authentication, determine answers to the following three questions:

1) What is the configured authentication provider for the CRM web site(s)?

Kerberos authentication will only work of your IIS server is configured to use it. Ensuring the right authentication provider is configured is the first step to enable Kerberos.

2) What is the identity used by the CRM web site(s) application pool?

The Kerberos authentication happens under the credentials of the CRM website’s application pool. To enable the identity to perform authentication, it is important to know which identity is in use.

3) Is Kernel mode authentication enabled?

Kernel mode authentication is performed by the system account and thus needs special attention especially if you’re using a service account as the identity of your application pool.

What is the configured authentication provider for the CRM web site(s)?

A default installation of Microsoft Dynamics CRM configures ‘Negotiate’ as the authentication provider for the IIS web site. The ‘Negotiate’ provider tries first to use Kerberos, but it will revert to using NTLM if either the client computer or the server is unable to authenticate by using Kerberos. In many situations, especially for Microsoft Dynamics CRM deployments installed using primarily default settings, NTLM authentication will be configured.

To identify the authentication protocol in use, perform the following steps:

1. In the IIS Manager console (Start, Run, inetmgr), under Connections, expand the organization node, expand Sites, and then click on Microsoft Dynamics CRM.

2. In the center of the screen, in the IIS section, double-click Authentication.





3. Under Name, click Windows Authentication, and then on the right, in the Actions pane, verify that the Windows Authentication service is enabled.

Note: If Windows Authentication is not enabled, in the Actions pane, click Enable.

4. In the Actions pane, click Providers.



5. In the Providers dialog box, under Enabled Providers, verify that Negotiate appears as the first entry.

Note: If Negotiate does not appear, add the Negotiate provider from the selection box, and then click Add.



Important: Providers are listed in priority order, so ensure that Negotiate appears at the top of the provider list when configuring Kerberos.

Note that you can also check the authentication provider setting for IIS websites by reviewing the ApplicationHost configuration file, which is available on the IIS server at %SystemDrive%\Windows\System32\inetsrv\config\ApplicationHost.config. Within the file, find a node for which the path=”Microsoft Dynamics CRM”. Under System.webServer\Authentication\windowsAuthentication, you’ll find a list of the configured providers. Note that the windowsAuthentication node actually has a few additional attributes (read more), such as useKernelMode. Using these additional attributes might be required upon deeper analysis of a specific scenario.

Note: A good way to determine what is happening from a security perspective is to use one of several network tracing tools that can listen in on the traffic between the server and the client computer. Most of these network tracing tools provide a way to filter the traffic collected. If you log into a client computer, start the network tracing tool, and then type in the CRM website address, you will have the best chance of capturing the full security conversation. Applying a filter for Kerberos traffic (which is sent over port 88) will quickly show whether or not Kerberos is in use.

What is the identity used by the CRM web site(s) application pool?

The Microsoft Dynamics CRM web site is configured with an application pool, the identity of which executes the Kerberos process. As a result, the application pool’s identity should be connected to the correct Service Principal Names (SPNs) (more here). The identity associated with the application pool can be either a Network Service account or a domain user account.

To determine the identity used by the CRM web site(s) application pool, perform the following steps:

1. In the IIS Manager console (Start, Run, inetmgr), under Connections, expand the server node, expand Sites, and then click on Microsoft Dynamics CRM.

2. On the right, in the Actions pane, click Advanced Settings.



3. In the Advanced Settings dialog box, under (General), note the value to the right of Application Pool (the default name of the application pool is ‘CRMAppPool’), and then close the Advanced Settings dialog box.

4. In the IIS Manager Console, under Connections, click on Application Pools, and then in the center of the console, select the application pool entry associated with the name you noted in step 3, and then in the Actions pane, click Advanced Settings.

5. In the Advanced Settings dialog box, under Process Model, make a note of the value to the right of Identity, which represents the identity in use by the application pool.



Note: The identity listed is an important variable in enabling Kerberos. A best practice is to use a domain account. Specifying a domain account will have an impact on the Kerberos configuration as we’ll further investigate below.

Are you using Kernel mode authentication?

Internet Information Services (IIS) 7.0 enables kernel mode authentication by default (more here), and with Windows Server 2008, kernel mode authentication runs under the machine account. However, Microsoft Dynamics CRM can be configured to run under a domain account, so Kerberos service ticket decryption will fail if kernel mode authentication is enabled (more here).

To determine whether or not a Microsoft Dynamics CRM deployment is using kernel mode authentication, perform the following steps:

1. In the IIS Manager console (Start, Run, inetmgr), under Connections, expand the organization node, expand Sites, and then click on Microsoft Dynamics CRM.

2. In the center of the screen, in the IIS section, double-click Authentication.



3. In the Advanced Settings dialog box, if the Enable Kernel-mode authentication check box is selected (which it is by default), then the deployment is using kernel mode authentication.

4. Select Windows Authentication, and then on the right, in the Actions pane, click Advanced Settings.



5. In the Advanced Settings dialog box, if the Enable Kernel-mode authentication check box is selected (which it is by default), then the deployment is using kernel mode authentication.



Note that Kerberos authentication can be used whether or not kernel-mode authentication is enabled If kernel-mode authentication is enabled, it will force IIS to use the machine account. It is recommended to configure the account that is used to perform IIS kernel-mode authentication to use the application pool account when configured with a domain account.

To configure IIS to use the application pool account, add an attribute to the application host file (ApplicationHost.config) on the IIS server at %SystemDrive%\Windows\System32\inetsrv\config\. Search for a node for which the path equals ”Microsoft Dynamics CRM”. Under System.webServer\Authentication, add an ‘useAppPoolCredentials’ attribute configured with a value of ‘true.’ The correct addition would appear as follows:



Alternatively, you can also use the appcmd command to set the parameter:

%windir%\system32\inetsrv\appcmd.exe set config-section:windowsAuthentication /useAppPoolCredentials:"True"/commit:apphost

Putting it all together

In general, there are three scenarios in which a Microsoft Dynamics CRM environment should be enabled to work with Kerberos:

• The application pool identity for your CRM web site is using the Network Service. If you’ve installed Microsoft Dynamics CRM using the Network Service account, you’re probably best of enabling kernel-mode authentication. Basically leaving everything by default will force IIS to use the computer account to verify Kerberos tickets by encrypting them with the computer account and using the HOST service principal names that should be on any windows server by default.
• The application pool identity for your CRM web site is using a domain account. If you’re using a domain account, you will have to create service principal names (SPN) for that account (more here). This is needed to have your domain controller (Active Directory) find the CRM application pool identity (account) that matches the SPN, and create a ticket for the user. If you’ve configured a domain account as the CRM application pool identity, verified Kerberos is used but you keep getting prompted to log on to Microsoft Dynamics CRM and you are never granted access, it is likely that the SPNs are absent or not properly configured. Verify that there is one SPN registered on the domain account (no duplicates) and that the SPN is registered on the HTTP/netbios and HTTP/netbios.fqdn DNS names associated with what you see in your browser’s address bar (more here). If your Microsoft Dynamics CRM environment separates multiple services on different machines, such as having a dedicated reporting server and SQL server, the domain account used should be trusted for delegation (more here).
• The Microsoft Dynamics CRM web site(s) is configured to use Kernel mode authentication. If you have kernel-mode authentication enabled and you’re using a domain account as the CRM application pool identity, make sure you configure IIS to useAppPoolCredentials in the ApplicationHost file (see above).

There is a simple way to increase performance of Kerberos authentication. By default, Kerberos will require each HTTP request to be authenticated. You can change this behavior to not require each request to be authenticated with the same keep alive session. This will decrease network traffic and use less resources on you machines (more here).

There exists a way to limit traffic when Kerberos authentication is enabled. By default IIS requires the client to be re-authenticated for each HTTP request when you use the Kerberos authentication protocol. This behavior causes network traffic to increase. This behavior differs from the behavior in IIS 5.0. In IIS 5.0, a client that is authenticated by the Kerberos protocol after an initial HTTP request stays authenticated during the HTTP keep-alive session.

To enable this improvement, set the value of the authPersistNonNTLM property to True at the server level in IIS 7.0. To do this, perform the following steps:

1. Click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type the following commands, and then press ENTER:

cd %SystemRoot%\System32\inetsrv appcmd set config /section:windowsAuthentication /authPersistNonNTLM:true

Note The authPersistNonNTLM property controls the reauthentication requirement of Kerberos authentication. By default, this property is set to False.

Important: If you still have problems enabling Kerberos, refer to the troubleshooting details provided in the blog posting Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0/7.5.

More Information

• Answers to frequently asked Kerberos questions
  http://support.microsoft.com/kb/266080
• Kerberos Explained
  http://technet.microsoft.com/en-us/l.../bb742516.aspx
• Netmon's view of Kerberos communication, when accessing resources across domains in the same forest.
  http://blogs.technet.com/b/abizerh/a...me-forest.aspx
• Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0/7.5
  http://blogs.msdn.com/b/saurabh_sing...h-iis-7-0.aspx
• Kerberos? Kerberos! ….en CRM (Dutch blog on Kerberos)
  http://blogs.microsoft.nl/blogs/stev...-kerberos.aspx
• Dynamics CRM 4.0 Kerberos Configuration
  http://social.technet.microsoft.com/...cles/6450.aspx

Martijn Bronkhorst

Premier Field Engineer




Источник: http://blogs.msdn.com/b/crm/archive/...-crm-2011.aspx