{"id":324,"date":"2020-10-18T13:06:50","date_gmt":"2020-10-18T12:06:50","guid":{"rendered":"http:\/\/www.labtinker.net\/?p=324"},"modified":"2020-10-18T13:06:50","modified_gmt":"2020-10-18T12:06:50","slug":"the-five-trials-of-kerberos","status":"publish","type":"post","link":"http:\/\/18.135.13.153\/?p=324","title":{"rendered":"The Five Trials of Kerberos"},"content":{"rendered":"\n

I said in my previous post I would discuss how I\u2019d got the Kerberos lab working. The thing is my notes were scrappy and instead of tidying them up it came to me that I\u2019d created a common real-world scenario: a poorly-documented system.<\/p>\n\n\n\n

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)<\/p>\n\n\n\n

But here are some pointers. For Kerberos authentication to work, the Firefox browser<\/strong> needed a setting changed:<\/p>\n\n\n\n

https:\/\/thycotic.force.com\/support\/s\/article\/Configuring-Firefox-for-Integrated-Windows-Authentication<\/a><\/p>\n\n\n\n

…and the IIS webserver<\/strong> needed configuring:<\/p>\n\n\n\n

http:\/\/woshub.com\/configuring-kerberos-authentication-on-iis-website\/<\/a><\/p>\n\n\n\n

A couple of things needed to happen on the KDC but they’re covered in the link above as I recall.<\/p>\n\n\n\n

I have grandly titled these five scenarios as the The Five Trials of Kerberos just because we\u2019ve got  a bit of a mythological thing going on and it’s got a ring to it.<\/p>\n\n\n\n

The First Trial<\/strong><\/p>\n\n\n\n

You browse to the website and you see…<\/p>\n\n\n\n

\"\"
Figure 1: 401 error.<\/figcaption><\/figure>\n\n\n\n

You break out Wireshark to see what’s going on and you see…<\/p>\n\n\n\n

\"\"
Figure 2: Time to break out Google.<\/figcaption><\/figure>\n\n\n\n

This one’s an easy one; all answers at the bottom of the post<\/p>\n\n\n\n

The Second Trial<\/strong><\/p>\n\n\n\n

You browse to the website and see\u2026<\/p>\n\n\n\n

\"\"
Figure 3: Not again!<\/figcaption><\/figure>\n\n\n\n

There are no Kerberos packets in the trace this time.<\/p>\n\n\n\n

The Third Trial<\/strong><\/p>\n\n\n\n

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:<\/p>\n\n\n\n

\"\"
Figure 4: Kerberos Error<\/figcaption><\/figure>\n\n\n\n

If I showed much more of the trace then you\u2019d probably work out what was going on and it is supposed to be a trial\u2026.  so instead I\u2019ll 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.<\/p>\n\n\n\n

The Fourth Trial<\/strong><\/p>\n\n\n\n

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:<\/p>\n\n\n\n

\"\"
Figure 5: Skew what now?<\/figcaption><\/figure>\n\n\n\n

Of the Kerberos errors supplied thus far these are probably the least helpful.<\/p>\n\n\n\n

The Fifth Trial<\/p>\n\n\n\n

The fifth and final trial is the trickiest as you might expect. You\u2019d probably need to be fairly unlucky to see this one in the wild\u2026<\/p>\n\n\n\n

This time it\u2019s properly broken\u2026<\/p>\n\n\n\n

\"\"
Figure 6: Credentials please!<\/figcaption><\/figure>\n\n\n\n

There\u2019s no Kerberos at all in the Wireshark trace. There is an attempt at NTLM but obviously that\u2019s not good enough.<\/p>\n\n\n\n

\"\"
Figure 7: Will this do?<\/figcaption><\/figure>\n\n\n\n

I won’t dwell on this one and so to the answers…<\/p>\n\n\n\n

Answer One<\/strong><\/p>\n\n\n\n

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\u2026 so the client was at 9:35 am and the KDC at 7:34 am and the authentication still worked!!<\/p>\n\n\n\n

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..<\/p>\n\n\n\n

\"\"
Figure 8: Well, it’s in the range<\/figcaption><\/figure>\n\n\n\n

Answer Two<\/strong><\/p>\n\n\n\n

The eagle-eyed amongst you would have noticed the website was not being accessed by the URL 'web.labtinker.net' but instead '18.135.13.153\/' 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.<\/p>\n\n\n\n

Answer Three<\/strong><\/p>\n\n\n\n

On this occasion I had deleted the SPN on the KDC by using the command:<\/p>\n\n\n\n

Setspn -d HTTP\/web.labtinker.net iis_kerb<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\"\"
Figure 9: Kerberos is a no-no but NTLM worked.<\/figcaption><\/figure>\n\n\n\n

When you specify negotiation schemes you can\u2019t explicitly specify \u2018Kerberos\u2019 but instead specify \u2018negotiate\u2019 and this will try Kerberos then try NTLM. In Trials 1 and 2 there was no failback to NTLM, in this trial there was\u2026 not altogether sure why the difference in behaviour.<\/p>\n\n\n\n

This does lead us on to spn\u2019s. To make the negotiation work for 18.135.13.153\/<\/a> we have to do the three following things:<\/p>\n\n\n\n

1\/ Set up a DNS A record for 18.135.13.153\/<\/a>  (CNAME didn\u2019t cut it)<\/p>\n\n\n\n

2\/ For firefox add it to the following parameter in ‘about:config’:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

3\/ Input the following setspn command where iis_kerb is a domain user.<\/p>\n\n\n\n

\"\"
Figure 10<\/figcaption><\/figure>\n\n\n\n

Then when we browse an d get authenticated see a ticket containing the 18.135.13.153\/ URL.<\/p>\n\n\n\n

\"\"
Figure 11: Token with 18.135.13.153\/<\/figcaption><\/figure>\n\n\n\n

Answer Four<\/strong><\/p>\n\n\n\n

I saw this error when I disabled the AD account \u2018iis_kerb\u2019 which the setspn statement maps to. The website continued to be authenticated because like in Trial 3 authentication failed back to using NTLM<\/p>\n\n\n\n

Answer Five<\/strong><\/p>\n\n\n\n

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<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"
Figure 12<\/figcaption><\/figure>\n\n\n\n

Then I got this…<\/p>\n\n\n\n

\"\"
Figure 13:<\/figcaption><\/figure>\n\n\n\n

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!!<\/p>\n","protected":false},"excerpt":{"rendered":"

I said in my previous post I would discuss how I\u2019d got the Kerberos lab working. The thing is my notes were scrappy and instead of tidying them up it came to me that I\u2019d created a common real-world scenario: a poorly-documented system. Often such systems are encountered by operations staff when said systems are […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-324","post","type-post","status-publish","format-standard","hentry","category-authentication"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts\/324","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=324"}],"version-history":[{"count":0,"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts\/324\/revisions"}],"wp:attachment":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=324"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}