On Kerberos
This one is not about how Kerberos work, rather it is about few things to watch out. If you want Kerberos literature check here: https://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx
Few things to watch out when working with Kerberos:
Timing everything: tickets generated by KDC are time stamped. The client, the server & the service have to have their time synchronized. How this works in a Windows environment https://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx
Tickets are issued to specific services: this simple mechanism ensures that your client will not be spoofed by a fake service provider. This works by assigning an service principal name (SPN) to the identity running the service. incorrect SPN configuration is the reason of most Kerberos failure. Use setspn.exe tool always use –f –s (not –a flag). These flags ensure that there is no duplicate SPN in the forest. Check how setspn.exe tool works https://technet.microsoft.com/en-us/library/cc773257(WS.10).aspx
Use A records not CANME records when aliasing your services: SPNs are assigned to identities in form of <SERVICE NAME>/<HOST NAME> for example HTTP/web.contoso.com. when you use an CNAME (web.contoso.com) to alias your machine (websvr1) it will resolve to “websvr1.contoso.com” causing the Kerberos authentication to fail since tickets were issued to web.contoso.com (most probably this will be witnessed as NTLM login attempts not Kerberos in your even log, since windows will fall back to NTLM when authentication fails). A Records on the other hand resolves to IPs causing the correct alias being using in the authentication process.
IIS Kernel Authentication mode: IIS is a fascinating little thing. HTTP.SYS is a kernel level driver handing all the requests routing them correct app pool which are running using configurable identities. This case happens if you are using anything other than network service to run your app pool. What happens is Kernel Authentication Mode (works within HTTP.SYS) caches user authentication across app pools allowing IIS to serve requests faster. Here is what happens:
1- HTTP.SYS runs using network service regardless what your app pool identity is. Meaning it will carry the service principal name of HTTP/<Server Name> assigned to “machine account“ (default configuration when you install IIS).
2- Your app pool carries an identity of “WebUser” which have SPN of HTTP/<A Record> assigned to it.
3- HTTP.SYS will attempt to decrypt to the ticket using its own SPN which will fail causing the browser to authenticate using NTLM.
you can work around that by disabling “Kernel Mode Authentication” in IIS might result into performance benefits loss – obviously not the best thing to have in a production environment, when you want to squeeze as much as you can out of your H/W investments. The alternative is to enable “useAppPoolCredentials” flag in the configuration, causing the HTTP.SYS driver to use the app pool identity to decrypt the Kerberos ticket. Follow this article on how to do that. https://blogs.msdn.com/b/webtopics/archive/2009/01/19/service-principal-name-spn-checklist-for-kerberos-authentication-with-iis-7-0.aspx (an important note: when you modify the configuration ensure that you are modifying the correct web site configuration by comparing the “path” attribute)
Other Things: get your arsenal of tools ready before jumping into troubleshooting Kerberos, Use Network Monitors, Resource Kit Tools among other things according to your poison of preference :-) – more on this on the below reference
Because of the distributed nature of Kerberos; troubleshooting it is not intuitive, hence you need to read a lot about it mainly start with this: https://technet.microsoft.com/en-us/library/cc728430(WS.10).aspx
Find me on Twitter: https://twitter.com/khnidk