Kerberos Delegation Lab

If you want to mess around with Kerberos delegation but dont want to install any heavy multi-tiered application this lab setup might be what you are looking for.

The basic overview diagram looks like this:

On WFE01 (web front end 01) i installed the basic IIS setup. Then on the default website i simply added a virtual directory that pointed to \\SQL01\share (literally this step is just a right click on the default web site inside IIS manager – then choose NEW – Virtual Directory). I assumed this would involve Kerberos authentication and require some messing around with SPN’s and delegation settings which was exactly what i was looking for.

While running through the New Virtual Directory wizard you get this prompt which gives me hope that this will be a super lightweight and successful way to test delegation:

At the end of the wizard, i now have a virtual directory called “test” that is running on a server called “WFE01″. The way clients should access this is https://wfe01/test. The “test” virtual directory should be nothing more than a listing of the contents from my \\SQL01\share directory.

If i attempt to view the site on the WFE01 server, i would expect it to work ok without doing anything else because we dont need delegation – we just need a ticket for the SQL01 machine:

This works. And we can see Kerberos authentication in the security log on the SQL01 server.

Using klist (“klist tickets”)on the WFE01 server i can also see that i have obtained a ticket for the SQL box.

Server: cifs/sql01@CONTOSO.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
End Time: 1/2/2011 21:12:23
Renew Time: 1/9/2011 11:12:23

Now the interesting part will be how well this works for clients. I have a Windows XP client machine in the lab – should it be able to access the same site? I guess not since delegation will be required, remembering that the XP client will need a ticket for the WFE01 server, then it will be needing the WFE01 server to obtain a ticket on its behalf for the SQL01 server to retrieve the directory listing.

As expected. No joy. Lets look at the logs on the WFE01 server and SQL01 server to see what type of authentication is happening. We could also use netmon, but in the first instance this is much quicker.

On the WFE01 server, the web front end, everything looks ok:

Successful Network Logon:
User Name: tom.tester
Domain: CONTOSO
Logon ID: (0×0,0x135C48)
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name:
Logon GUID: {abb6c392-9910-601b-5b95-f426201eaa9b}
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.0.0.88
Source Port: 1310

On the SQL01 server, not so nice:

Successful Network Logon:
User Name:
Domain:
Logon ID: (0×0,0x7D820)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: WFE01
Logon GUID: -
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.0.0.5
Source Port: 0

We can see that the request to display our test user the contents of the directory was sent, but the authentication that was used was NTLM, and also that it came through as an ANONYMOUS logon from NT AUTHORITY\ANONYMOUS LOGON.

So what gives? This is the classic example of delegation not working, and its expected in this case because i havn’t allowed it yet.

The trick here is to allow the webserver to pass the credentials of the user to the next tier. Specifically in my case, for the WFE01 box to take the credentials i used for it (tom.tester credentials) and pass them to SQL01. To do this, i make a change on the computer object of the IIS server – WFE01.

With the settings above i have chosen to allow normal delegation, not the new “constrained delegation” in Windows 2003+. Before i change it to constrained i want to check that it works at all.

Logging back on to the XP client the web site displays as expected:

Looking at the event logs on the SQL01 server, things look MUCH better now. Rather than seeing NT AUTHORITY\ANONYMOUS LOGON, i see the name of the user who’s credentials are being passed. Also the authentication package is now Kerberos as expected, rather than NTLM. The other interesting point is that the authentication request is originating from 10.0.0.5 which is my web server WFE01 – so it is doing the delegation as expected.

Successful Network Logon:
User Name: tom.tester
Domain: CONTOSO
Logon ID: (0×0,0x800FF)
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name:
Logon GUID: {88478d58-81e2-2cc8-1529-439df5daab93}
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.0.0.5
Source Port: 0

Excellent, so i have a functioning Kerberos delegation lab that i can use to inspect packets and get into the guts of what is going on with. But there is an extra step i really need to do to make it more relevant. That is adding the option for “constrained delegation”. Essentially saying to the IIS box “i trust you for delegation BUT only to the SERVERS and the SERVICES i say”. To make that change i go back to the computer object of the IIS box, and modify the delegation tab:

In this case i choose ONLY sql01.contoso.com and ONLY the CIFS service – which is the one i will need for the directory listing my web page is performing.

A test of the site and everything is still working as expected. Good stuff. Lab ready.

Obviously ive skipped a lot of steps in there, and the reason is like i said in an earlier post – this site is mainly so i have notes ready to give the MCM a crack in a few weeks time. If there is anything specific ive missed that you need for your own testing please give me a shout.