The Five Trials of Kerberos
I said in my previous post I would discuss how I’d got the Kerberos lab working. The thing is my notes were scrappy and instead of tidying them up it came to me that I’d created a common real-world scenario: a poorly-documented system.
Often such systems are encountered by operations staff when said systems are no longer working so let’s break things and see what needs to happen to fix them. (If you want to go hard-core you could try setting your alarm for 2 a.m and pretend it’s a call from the service desk before reading the rest of the post)
But here are some pointers. For Kerberos authentication to work, the Firefox browser needed a setting changed:
…and the IIS webserver needed configuring:
http://woshub.com/configuring-kerberos-authentication-on-iis-website/
A couple of things needed to happen on the KDC but they’re covered in the link above as I recall.
I have grandly titled these five scenarios as the The Five Trials of Kerberos just because we’ve got a bit of a mythological thing going on and it’s got a ring to it.
The First Trial
You browse to the website and you see…
You break out Wireshark to see what’s going on and you see…
This one’s an easy one; all answers at the bottom of the post
The Second Trial
You browse to the website and see…
There are no Kerberos packets in the trace this time.
The Third Trial
Now this trial is a little unusual in that I did something that broke Kerberos but the website continued working and authentication was happening. I was a little surprised by this myself though it made sense when I worked out what was going on. Anyway, the Kerberos error was this:
If I showed much more of the trace then you’d probably work out what was going on and it is supposed to be a trial…. so instead I’ll tell you that if the webserver was busy you would notice the authentication server’s CPU usage has gone up compared to its usual baseline.
The Fourth Trial
This follows the pattern of the previous trial in that Kerberos stops working but access to the website continued for the same reasons as above. However, this time there was more in the Kerberos trace:
Of the Kerberos errors supplied thus far these are probably the least helpful.
The Fifth Trial
The fifth and final trial is the trickiest as you might expect. You’d probably need to be fairly unlucky to see this one in the wild…
This time it’s properly broken…
There’s no Kerberos at all in the Wireshark trace. There is an attempt at NTLM but obviously that’s not good enough.
I won’t dwell on this one and so to the answers…
Answer One
The ticket is not yet valid. This is because I moved the time ahead on the KDC server. Kerberos will give you 5 minutes leeway but I moved it ahead an hour. If the client time is behind you will see the error.. I tried this the other way around… so the client was at 9:35 am and the KDC at 7:34 am and the authentication still worked!!
I put this down to the token being within the valid time range. There are probably ways to stop this happening but we’ll move on..
Answer Two
The eagle-eyed amongst you would have noticed the website was not being accessed by the URL ‘web.labtinker.net’ but instead ‘www.labtinker.net’ for which a CNAME entry had been created. It is possible to get to the website by a different URL but more work needs to be done. More on this later.
Answer Three
On this occasion I had deleted the SPN on the KDC by using the command:
Setspn -d HTTP/web.labtinker.net iis_kerb
This meant there was no mapping between a service principal and a user. The authentication carried on working because NTLM took over when Kerberos failed.
When you specify negotiation schemes you can’t explicitly specify ‘Kerberos’ but instead specify ‘negotiate’ and this will try Kerberos then try NTLM. In Trials 1 and 2 there was no failback to NTLM, in this trial there was… not altogether sure why the difference in behaviour.
This does lead us on to spn’s. To make the negotiation work for www.labtinker.net we have to do the three following things:
1/ Set up a DNS A record for www.labtinker.net (CNAME didn’t cut it)
2/ For firefox add it to the following parameter in ‘about:config’:
3/ Input the following setspn command where iis_kerb is a domain user.
Then when we browse an d get authenticated see a ticket containing the www.labtinker.net URL.
Answer Four
I saw this error when I disabled the AD account ‘iis_kerb’ which the setspn statement maps to. The website continued to be authenticated because like in Trial 3 authentication failed back to using NTLM
Answer Five
For this particular error I went into the configuration of the webserver itself and into the IIS configuration. I right-clicked on ‘Windows Authentication’ which is set correctly to issue the HTTP 401 Challenge
Then I got this…
Here, I unticked ‘Enable Kernel-mode’ authentication. I must admit at the time I speed-read this as Kerberos, not Kernel but it still broke authentication!!