After all that setup, I could use Internet Explorer to browse to the site fine – integrated Windows Authentication would let me in. However, as the DNS had yet to be set up, and the web server and the website had the same IP address, I was browsing using the machine name, e.g. http://machine.domain/website instead of http://dnsname.co.uk/website.

When the DNS was set up and I tried to browse to the website, I got a Windows user name & password box popping up. After 3 tries I was denied access (a 401 error). Just changing the DNS name to the machine name in the location bar let me in, even though they were both the same IP address!

Using Fiddler, I could see the initial client GET request, and the server’s 401 challenge response, including a WWW-Authenticate header set to “Negotiate”. This occurred in both cases (browsing to the DNS name and to the machine name). However, the client response to this challenge was different in each case. The Negotiate token the client sent to the DNS name was much shorter than the one sent to the machine name. Clearly something was telling the client not to send the proper Kerberos authentication token to the DNS name.

Just looking at the HTTP traffic was not enough here – for cases like these a lower-level tool like Microsoft’s Network Monitor is required, or Wireshark if you’re feeling hardcore. This showed that the client was encountering a Kerberos error. A bit of searching around this and…

A magic SPN setting will solve this, all explained in a handy MSDN article. You will need to run this command (I ran it on the web server itself, however this may not be necessary):

setspn -A HTTP/[dns name of the site] [machine name]

Then a reboot of the web server, and a few hours’ wait for the settings to propagate around the domain. This will allow clients to send complete Kerberos authentication tokens to the website. Problem solved!

It’s fairly simple to set this up once you know what needs doing. Getting to that stage wasn’t the most fun I’ve ever had – the MSDN articles on the subject are useful, but they seem to want to cover at least 3 topics at a time, which can be a little confusing.

The scenario was this: an intranet web application would authenticate users using Windows Authentication, granting access based on their Active Directory roles. The application would access the back-end SQL Server database using Integrated Security, with the credentials of the current user. This gives two main advantages – you don’t have to setup or administer a separate account or accounts for the database, and auditing via SQL triggers is easy. However, this approach is only really suited to an intranet scenario, as database connection pools are used on a per-user basis. Too many users and the database will not be happy.

The setup is in four parts.

ASP.Net

Under the <system.web> section of your web.config, add the following:

<authentication mode="Windows"/>
<identity impersonate="true"/>

Also, make sure you’re using a connection string that uses Integrated Security.

IIS

I’m using IIS7, which has some more detailed settings than IIS6. In the website or virtual directory, ensure that Anonymous Authentication and Forms Authentication are disabled, and ASP.Net Impersonation and Windows Authentication are enabled. IIS should pick this up from web.config.

IIS7 lets you specify “providers” for Windows Authentication. You must use the Negotiate:Kerberos provider. Choosing this provider will mean that “Kernel-mode authentication” cannot be used. This is disabled under the Advanced Settings within the Authentication section.

Active Directory

The web server’s Active Directory properties must be edited to enable Delegation of credentials onto the SQL server. There’s a great explanation with a screen grab of the Active Directory property page in a post from Ken Schaefer.

Windows Server 2003 domains and later support Constrained Delegation, which can constrain the delegation to a specific service on the target machine. This is obviously more secure. To delegate to SQL Server, MSSQLSvc is the service you need.

SQL Server

All you need to do at the database level is grant the relevant permissions for the users or roles you want accessing the database.

Now it should all magically work!

UPDATE: That might not be all! See Part 2.

Device Manager said there was a problem with the drivers, but no new ones could be found automatically, and rolling back didn’t work as they hadn’t actually changed. An interweb search for drivers turned up nothing. There were no physical connection issues, all looked fine.

After a while I investigated the Event Log and saw the following error occurred in the System log every boot-up:

The following boot-start or system-start driver(s) failed to load:
Imapi
redbook

I searched again with this info, and stumbled across a handy Microsoft article, “Your CD drive or DVD drive is missing or is not recognized by Windows or other programs”. This pointed me to some obscure registry key to do with CD burning, and a value called “UpperFilters”. This contained two values, “Sidney” and “GEARAspiWDM”. I deleted the value then restarted, and the DVD drive was back!

I checked the registry again, and the “UpperFilters” value was back, but “GEARAspiWDM” was not. It turns out that this is some kind of burning driver that was probably installed by iTunes, but not removed from the registry during the uninstall. Thanks Apple! iTunes can still be a pain after death.