This week we set up Kerberos for a client. There are plenty of articles and blogs on how to do it so instead of writing another one I’ll just focus on what I believe will save you hours if not days if you are doing it for the first time. Namely how to avoid some gotchas.
My tips.
- Firstly the article with the best step by step instructions was this. - http://technet.microsoft.com/en-us/library/cc263449.aspx
- As the Technet article does, get SQL working with Kerberos first before doing anything else.
- Don’t guess the SPN’s. You will end up with a mess. Keep a record of which SPN’s you set so you can reverse them. Keep them all in one script.
- Know your setspn commands
- setspn – a (add)
- setspn – d (delete)
- setspn – l (list)
- If you can’t debug Kerberos you will struggle. You NEED these tools & don’t be afraid to use them.
Wireshark, - http://www.wireshark.org/
ldifde & setspn - Windows 2003 resource kit
and some scripts I’ll mention in a sec.
Using Wireshark
The most common problems you can encounter with Kerberos are as follows:
1. Non-synchronized time on servers
Cause:
Kerberos depends on time and if time on servers is different, Kerberos authentication will fail.
How to find out:
Run WireShark utility, start a packet capture and set the packet filter to the „kerberos“ expression. You should see a packet with error code KRB_AP_ERR_SKEW.
Solution:
Synchronize time on all servers with AD server time.
2. Duplicate or missing SPNs
Cause:
If you have multiple service accounts of one class (i.e. HTTP, MSSQLSvc) registered for one IP address or SPN wasn’t registered at all, Kerberos authentication will fail.
How to find out:
Run WireShark utility, start a packet capture and set the packet filter to the „kerberos“ expression. You should see a packet with error code KDC_ERR_C_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE.
Solution:
On AD server use the ldifde.exe utility to find out the duplicate SPN.
ldifde syntax:
ldifde -f c:\[output file name] -t 3268 -d "" -l servicePrincipalName -r "(servicePrincipalName=HTTP/[server name]*)" -p subtree
Example:
ldifde -f c:\spn_out.txt -t 3268 -d "" -l servicePrincipalName -r "(servicePrincipalName=HTTP/my-moss-server*)" -p subtree
3. Response too big packet
Cause:
On some Windows servers system you can encounter a problem with UDP packet overflow that can result in the authentication failure.
How to find out:
Run WireShark utility, start a packet capture and set the packet filter to the „kerberos“ expression. You should see a packet with error code KRB_ERR_RESPONSE_TOO_BIG.
Solution:
1. Start Registry Editor (Regedt32.exe).
2. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos
3. On the Edit menu, click Add Key, and then add the following registry key:
Key name: Parameters
4. On the Edit menu, click Add Value, and then add the following registry value:
Value name: MaxTokenSize Type: REG_DWORD
Radix: Decimal
Value: 65535
5. Quit Registry Editor.
1. Open the web application for which you enabled Kerberos and monitor the server’s security logs in event viewer for errors. Remember, if Kerberos doesn’t function properly the server falls back to NTLM.
2. Run the following SQL query on SQL server. You can see which services use Kerberos or NTLM authentication.
SELECT login_name, program_name, host_name, auth_scheme
FROM sys.dm_exec_connections C INNER JOIN sys.dm_exec_sessions S
ON C.session_id = S.session_id
3. Add an RSS webpart onto site homepage and use a list on subsite as the RSS source URL. If the RSS webpart displays RSS feeds then Kerberos authentication is working. RSS feeds from subsites do not work in MOSS without Kerberos.
Hope that saves someone time. Good luck with your Kerberos config!!!