Wednesday, 17 October 2012

Dynamics CRM troubleshooting Kerberos Authentication

This is Part 2 of my article on improving CRM performance with Kerberos http://quantusdynamics.blogspot.com/2011/12/extreme-performance-with-dynamics-crm.html

Kerberos is not the easiest protocol to troubleshoot due to it's complex architecture, I would like to share with you a few tips on how to tackle kerberos issues.

To troubleshoot kerberos I'm going to use the following tools:
  • Wireshark (we could use Microsoft network monitor but for Kerberos I think Wireshark is simpler to use and illustrate)
  • Fiddler (capture HTTP packets)
  • ADSI Edit or Command prompt setspn
  • Microsoft Kerbtray to list/purge tickets or command prompt klist.

If you read the first article on how to improve performance with kerberos, you understand that when you use  custom service accounts you will need unique SPN's configured to allow authentication to succeed. However you could use built-in accounts, the best practice and recommendations from Microsoft is to always use custom service accounts, and it's here where things get a bit more complicated. I'm assuming you have attempted to configure Kerberos based on my first article and you run Fiddler for the first time and let's assume you see this on the first attempt:











































This ticket is an NTLM ticket, Kerberos failed somewhere and we will try to find out using wireshark.

Open Wireshark start capturing network traffic and on the search field type: Kerberos














Wireshark shows a packet with error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN highlight this packet and on the below screen expand the Kerberos packet details and you find that the missing DNS is HTTP/crm.ha Kerberos is looking for this and can't find it. The next step is to register an SPN under the service account CRM website is running on.

Configuring SPN
a quick way to create visualise SPN's  is using the Microsoft command tool Setspn, open the command prompt and type:

setspn -L DOMAIN\SERVICE_ACCOUNT 
Replace DOMAIN and SERVICE_ACCOUNT with your own domain and service account. This will list any SPN's configured under that account.

If you can't find the SPN listed under that account create the SPN:
setspn -a HTTP/crm.ha SERVICE_ACCOUNT

Run again the first command and check if the SPN has been created.

Another way to create SPN's is using the ADSI Edit GUID, it's easier to manage multiple SPN's for multiple accounts etc..

To install ADSI Edit follow the following instructions:
On the Server manager under Features add new features and navigate to the following options:

























When installed  go to: Start menu > Administrative Tools > ADSI Edit

Open ADSI Edit and right click and choose connect to...
On the below screen type the name of the object you want to use, and leave default naming context and type the SERVER_NAME click ok. replace SERVER_NAME with the name of Domain controller in your network.



Below Expand the folders until you see the service account you want to configure the SPN's


 When you find the account, right-click and properties. The below screen appears. Scroll down to servicePrincipalName and click Edit.



On the below screen you can manage the SPN's and add the needed SPN, you can type HTTP/crm.ha and click OK and Apply and it's done.






















Looking for Kerberos tickets
We have configured the missing SPN, the next step is to run wireshark and look for the kerberos ticket.

Highlighting the first packet show us what request's are going through in the process.

I highlight the first HTTP packet and I already see the first negotiation using Kerberos tickets look for Authorization: Negotiate YIIUM this is a Kerberos ticket.



Below I highlight the next in line HTTP packet HTTP/1.1 found and you see a reply with a kerberos ticket again.


It looks like we are now using Kerberos. if we look back at Fiddler now, we should see the following:



Also another way to check your kerberos tickets it's using Microsoft Kerbtray or the command line prompt klist.
Usage: Klist.exe [-lh ] [-li ] tickets | tgt | purge


On the command line run:
klist [ENTER] This should show you all kerberos tickets issued to your machine and user account, you may see a number of them.

To purge the tickets do:
klist purge

You can also use a GUID tool called kerbtray you can download kerbtray from here:


Kerbtray will appear as a green icon on your tray area, right-click this icon and you can purge tickets or list the current tickets. This is the same functionality as the klist command.





Event Logs
You could also look for kerberos authentication issues by enabling Kerberos debug logging on the server, this would generate a number of detailed event logs on your server which can be quite handy:

Summary
I hope this was helpful, the article is designed to give an overview of the tools available for troubleshooting kerberos authentication issues and how to use this tools to look for the right information.

References
If you interested in learning more about Kerberos and it's architecture, I would recommend you read this article which gives a great overview on this. You may also find loads of high-level articles on this.

1 comment: