Web Sites, Databases and Kerberos

For some reason the documentation on how to set up Kerberos in your environment seems to be very sketchy out there. So I will write out what you need to do to get things to work.
In my example we will think of a system where we have a user, a web application server, and a database server. In our situation the database server is set up so that the user is granted execute access to the stored procedures called by the web application.

1. ALL servers that you will be using need to be trusted for delegation in AD. No exceptions. If any servers involved are not trusted for delegation, the chain fails and the user credential will not propagate to the next hop. That means that all web servers, all database servers, and whatever application servers you have in your environment need to be trusted, regardless of the next steps.
2. All users involved need to be trusted for delegation. This includes the end users, and any service accounts that may be running your application pools.
3. If you are using a DNS alias for your web site a Service Principal Name needs to be created for that alias. This is where things get tricky.
   
   • If there is only one web server in your environment you would register the DNS alias with that server. You would then use the Network Account as the ID to run your application pool under.
     
     • setspn -a HTTP\MyDNSName WEBSERVER
   • If you have a web farm, the IP that owns the DNS alias exists on some other device, so what server do you register your SPN under? You need a domain account to register your DNS SPN. If you are using IIS 6, you will need to use this account that the DNS SPN is registered under as the ID that your application pool uses for its identity. If you are using IIS 7 and up, you do not need to use this account, but any account the application pool uses as its identity will be need to be trusted for delegation.
     
     • setspn -a HTTP\MyDNSName MyDomain\ServiceAccount
4. Any database that is used will need to be registered with a SPN as well. If you are using a named instance as your server, you will need to register the instance as ServerName:PortNumber. Again, you will need a domain user, trusted for delegation, to register your database instances under. This account does not necessarily need to be the account you installed SQL under, but it does need to be a valid domain account.
   
   • setspn –a MSSQLSvc/ServerName:PortNumber MyDomain\SQLServiceAccount
5. In IIS, the web site must be set to Integrated Windows Authentication. You still need to get the user credential from the user, this is how it is obtained. No other type of authentication will work, it must be Windows Authentication.
   
   • If your application is a .NET application, you will want to make sure that your authentication tag in your web.config is set to Windows.
     In IIS 7 and up, just by clicking Windows Authentication will update your web.config file, but in IIS 6 you will have to make sure it is there.
   • If your app is not a .NET app, IIS will handle the authentication part for you, however the next step might be tricky...
6. Next, you will need to tell your application to impersonate the user that is logging on to the system. In IIS 7 and up that is easy, you simply check the box in the Authentication section that says ASP.NET Impersonation, and you are done. In IIS 6 you will need to add an identity tag to your web config, then set impersonation equal to true (<identity impersonate=true />)
   
   • If your app is not a .NET application, and you are not using IIS 7 and up, you will need to follow whatever steps your platform uses to impersonate users.
7. 
   Finally, you will need to write your connection string so that it uses integrated windows authentication. For a MS SQL server that is Integrated Security=SSPI. That is all you need do, no user name, no password.
   
   • If you want to use Integrated Security, but instead of the end user, you wanted to use the application pool identity, all you would need to do is uncheck ASP.NET Impersonation option (IIS 7 and higher), or remove the >identity /> tag (IIS 6) from the web.config. The IIS impersonation credential hierarchy is user, app pool, web site anonymous account.
     

I hope this helps. I have found that where I tend to make mistakes is making sure my applications are set to Windows Security, and the Database instances have SPNs.

First Post

This blog is mainly so I don't forget stuff... I create cool fixes or find something out just to document it at a company, only to loose that information later on when I leave that company. I don't want that to happen anymore, thus the blog.
I will attempt to phrase my posts so that others can read and use my Ramblings, but don't expect them to make much sense.
If you want to leave a comment, you will have to follow my blog, I get too much spam by leaving it open. I will attempt to respond to every posting. The only stupid question is the one not asked.