It has been a while since my last post. I want to talk about how you can improve massively CRM performance with Kerberos implementation. Kerberos is an authentication process that can save lots of processing time on the authentication side, rendering CRM much faster, I don't think is difficult to implement and it gives your CRM a major boost in performance.
Before I go through the steps, I will not explain the technical side of Kerberos because that is long subject, and you can find many whitepapers online covering kerberos authentication in detail, so I will focus only in the configuration requirements and how to troubleshoot.
Lets assume the below enterprise role-based configuration:
Domain: crm.domain.com
AD Configuration / SPNs
The first thing to do is to configure SPNs, we need to make sure we don't duplicate SPNs for the alias crm.domain.com, if we do kerberos will not work. The following command will show us if any duplicate SPN exists:
ldifde -f c:\spn_out.txt -d "DC=domain,DC=com" -l serviceprincipalname -r "(serviceprincipalname=*/*)" -p subtree
Analyse the spn_out.txt for any duplicate/existing SPNs with the name crm.domain.com
The following SPNs are required for Kerberos to work on our above environment, and these need to be configured under the service account domain\crm.service you add SPNs using setspn command or with ADSI EDIT
HTTP/crm.domain.com
HTTP/application
HTTP/application.domain.com
HTTP/platform
HTTP/platform.domain.com
HTTP/reporting
HTTP/reporting.domain.com
We are creating SPNs for the DNS name, and all servers in the CRM farm apart from:
SQL and reporting, because the SQL account will automatically create it's own SPNs and reporing runs under the Network Service account which happens in most deployments and by default does not require SPNs, if you run under a different service account, then you need to also add corresponding HTTP/ SPN to that service account.
with the SPN in place, we can jump to the next step IIS.IIS CRMAppPool is running under domain\crm.service account, the first setting to make sure is enabled is the windows authentication Kernel-mode authentication, to get there, highlight the website > click authentication > highlight Windows authentication > on the right menu click advanced settings. Note: this is normally enabled by default.
DNS Configuration
Make sure the domain you use for CRM is an A record this case crm.domain.com and not a CNAME record.
IIS Configuration
The second configuration is to enable the useAppPoolCredentials to true, which by default is set to false. Highlight the website and double click configuration Editor located at the Management section, below is a screenshot of the location of the windowsAuthentication key we need to configure to enable the use of the AppPool Credentials.
double click and change UseAppPoolCredentials to True
IE Configuration
At this point if you access crm.domain.com you will be prompted for credentials. We need to add crm.domain.com to the Trusted Sites and make sure this zone is configured to to Auto Logon and Windows Authentication is enabled.Delegation of Authentication
Another crucial step is to delegate authentication in AD, we need to delegate authentication to the service account domain\crm.service and the CRM servers: application and platform
With an account with permissions to delegate authentication you right-click the user account domain\crm.service in AD and click properties, click on the delegation tab, and enable:
- Trust this user for delegation to any service (Kerberos only)
- User Kerberos only
We have now all in place to test Kerberos authentication, opening crm.domain.com and not getting prompted for username/password is a good sign authentication is working, if we do get prompted, review the following configuration:
- SPNs
- Trusted Sites zone configuration and check if the domain is listed on the trusted sites list.
- Double check IIS
-Review duplicate SPNs, you just need one duplicate and it will not let you authentication, so make sure there are no duplicates.
If all is correctly configured, and we still getting prompted, I suggest you monitor the traffic between IE and the server with wireshark, capturing all communication packages and on the filter type kerberos to view packages only related with Kerberos.
If authentication works, it doesn't mean that we are necessarily using kerberos, so I suggest you confirm this with wireshark or with Fiddler. When you run Fiddler, you can capture authentication headers, below is a screenshot illustrating a kerberos tickets on the headers, a kerberos ticket always start with Y or oY
Hope this post was useful for you, and if you have any questions please feel free to leave any comments.
References:
SPN Configuration - http://rc.crm.dynamics.com/rc/regcont/en_us/op/articles/configurespn.aspx#o45872
No comments:
Post a Comment