Myth 1 - Kerberos is hard to bring into action in Windows Domain Controllers
These days I get to deal with variety of developers working on typical business solutions. I've had a lot of interesting discussions lately and I also heard some weird things about various technical things. So I thought about starting this "Myths" column to share my thoughts with rest of the community as I believe it will certainly be mutually beneficial.
Today I'm going to start off with is this Kerberos thing as I found it very interesting among everything else. Recently I ran into a very common application scenario. There are three parts in that.
- ASP.NET web application
- WCF Web Service
- SQL Server
ASP.NET application consumes WCF web service which will in turn interacts with the SQL database. Each of these parts runs in their own server boxes and they are nodes of a domain controller. IIS hosting the web app is configured to perform Windows authentication and users sign-in to the ASP.NET web application using their domain accounts.
In this application WCF web service implements the reusable business logic. However, it still relies on the web application to perform the authentication and authorization to access various business functionality :(. This is usually not what we would expect to see. The service itself should be able to authenticate and authorize the users and thus the security becomes feature of the service.
So that's essentially the story. Interesting part of that is "why" it's being implemented that way. Obviously the ASP.NET application can be configured to impersonate the client who logs in with her domain account. However, for ASP.NET application to access remote resources on behalf of the impersonated user (e.g. access the web service running in a different node), the hosting server must support delegation. And in order to support delegation Windows authentication process should have used Kerberos instead of NTLM. This is where the myth comes to the table. I managed to find a few blogs saying that you have to do number of things to enable Kerberos in Windows 2003.
But in reality Kerberos is the default authentication package used in Windows for domain accounts. But then why doesn't it work in the scenario described above? If you run all applications as network service (i.e. computer account) and access the resources using the standard host names everything should work as soon as you enable delegation (I will show you how to do that in a moment). However, this is not the case in most circumstances. You usually use custom host names to access your web application, web services and various other resources. As soon as you do this, you have configure something called Service Principal Names in order to make Windows use Kerberos package for authentication.
Instead of repeating the very few steps to enable delegation and configuring service principal names I would like point this wonderful Q & A paper written by Keith Brown few years ago. In that Keith talks about delegating the credentials to SQL server. But you do the same stuff in the aforementioned WCF scenario as well.
However, to summarize a few things that you may want to pay attention:
- If you are using host headers for ASP.NET application or Web service make sure you register SPNs for them. Also make sure that they are HOST entries (not CNAME) in your DNS records.
- Make sure you enable impersonation in the ASP.NET application (http://msdn.microsoft.com/en-us/library/aa292118(VS.71).aspx).
- When you are testing while changing these settings, always logout and log back into your client PC to flush the Kerberos ticket cache.
Last but not least I must thank my good friend Dominick for giving me a big hand to get my demo application up and running. His blog and Keith's blogs are must reads for all of those dealing with Security tidbits :).