IIS 7 and Kernel mode authentication
IIS 7.0 available with Windows Server 2008 is the new Application server platform from Microsoft. Just like its predecessor, it introduces various enhancements. One of the enhancements available is that authentication is now performed in kernel mode by default, which allows you to overcome certain limitations that are present with IIS 6.0. Naturally, the first question almost everyone has is, what are the advantages of kernel mode authentication? Let’s discuss…
In IIS 6.0, all applications that lived under the same website & used Kerberos authentication protocol (for delegation) must run under the same application pool. Consider the following situation.
Requirement: Default web Site has 2 applications under it (listed below) that wants to use integrated windows authentication with Kerberos. Each application needs to use its own application pool with different identities:
- HumanResource
- Training
Since site bindings can be set only at the site level, let us assume Default web site’s bindings are:
- IP: 192.168.1.10
- Hostheader: www.contoso.com
- Port: 80
Thus, clients can access the above applications as:
Now, because SPNs are mapped to a user account, you cannot have contoso.com mapped to two different accounts (as required by the applications), because it would create a duplicate SPN.
IMPORTANT NOTE: This limitation DOES NOT APPLY to applications that are at the site level. For eg: www.tailspintoys.com and www.fabrikam.com will not suffer from this limitation.
Solution in IIS 7.0: In IIS 7.0, we use the web server computer’s active directory account (ComputerName$) to decrypt the service ticket. In other words, by default, we no longer use the application pool identity to decrypt the service ticket, thus solving the limitation described above. You are no longer required to configure an SPN as long as the fully qualified domain name (FQDN) or host headers that you are using for the site resolves to the FQDN of the web server’s NETBIOS name.
IMPORTANT NOTE: It is a requirement to add an SPN if you are using an FQDN/host header that does not resolve to the web server’s fully qualified NETBIOS name OR if you are using application pool identity.
The attribute in Windows Authentication settings that controls this is behavior is:
- Attribute: useAppPoolCredentials
- Section : system.webServer/security/authentication/windowsAuthentication
Please refer to IIS 7.0: windowsAuthentication Element (IIS Settings Schema) for complete information.
Caveat: The solution described above will not work with Web farm. In a web farm, always use a domain account as the application pool identity and configure useAppPoolCredentials=”true”. Then configure the SPNs as required. For a walkthrough, please see this Technet article. The reason the above solution will not work is, in a web farm scenario the KDC cannot know in advance which web server will handle the request and you cannot register an SPN for multiple computer accounts. Thus, without proper configuration, you may see that authentication works intermittently or doesn’t work at all!
Another good news!
The SetSPN tool is now included with Windows Server 2008 and will always check if the SPN you are adding will create a duplicate SPN before adding it. Even better, it queries for duplicate SPNs forest wide. Microsoft support teams have handled many cases related to duplicate SPN & diligently provided feedback to our product teams. The end result is that this new capability has been included that will save our customers many support hours related to this problem. I encourage you to use the new SetSPN tool in Windows 2008, because using the Windows 2003 or earlier tools may result in adding a duplicate SPN by mistake.
Significant performance gain - Kernel Mode Authentication allows authentication persistence when switching the request from one application pool to another application pool. It re-authenticates only once for the first time when the request is made to that application. For rest all requests Kernel mode authentication (KA) session is maintained, which is a huge performance gain!
I am really glad about the work done in our product groups. Contrary to the popular belief, customer feedback & feedback from support cases are always reviewed and used in building the next version of our products. So if you have a feedback, please use our online feedback form. We always like to hear from you.
Comments
Anonymous
May 11, 2009
So does that mean that Kerb auth can't happen using the hostname after this configuration is put in place? I am seeing that while site name works, server FQDN does not.Anonymous
May 11, 2009
I don't see why it shouldn't work because using your hostname should resolve to the computer account if you are using network service as your application pool identity.