Kerberos Event ID 27

Twitter warning: Like all good things this is mostly correct, with a few details fuzzier than others for reasons: a) details are hard on twitter; b) details are fudged for greater clarity; c) maybe I'm just dumb.

The event log text:

While processing a TGS request for the target server class/service.domain.com, the account abc@DOMAIN.COM did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 9). 

The requested etypes were 23  3  1. 

The accounts available etypes were 23  18  17.

TGS-REQ: hopefully obvious by now -- you've authenticated already. You've exchanged your password or whatever for a TGT. TGT is good.

You're requesting a ticket to an SPN class/service.domain.com.

Key ID = 9: poorly labelled -- means the action the key is needed for. It's an internal mapping for us for debugging because from a customer diagnostics perspective it's all the same.

9 is service ticket encryption. That means the KDC could not find a key to encrypt the ticket.

Okay, why can't it find a key? How does it decide which key to pick?

It finds the intersection of 3 sets: 

Requested ETypes
Account keys
KDC supported ETypes

Two of those sets are listed in the event.

Requested ETypes is literally the requested ETypes in the Kerberos TGS request body. "As a client, I only support XYZ ETypes".

Account keys are the actual keys stored in the database.

KDC supported ETypes is what's recorded in the registry as... supported.

Let's do some math.

1=DES1
3=DES2
17=AES128
18=AES256
23=RC4

23, 3, 1 ∩ 23, 18, 17 = 23

Okay, only one common key, and that is...RC4. Yeeeugh.

But that should work, shouldn't it? RC4 is terrible, but selected EType is selected EType.

Except we're missing an intersection against KDC supported etypes. That's this policy applied to the DC. Default is 0, which means pick whatever Windows thinks is best. Most people pick AES and/or Future encryption types.

The policy most folks choose is AES/Future. It's good and safe. That means we're working with a written value of 0x7FFFFFF8. Let's decode that. Remember start at the right.

0x7FFFFFF8 => 0111 1111 1111 1111 1111 1111 1111 1000
DES1 -----------------------------------------------^
DES2 ----------------------------------------------^
RC4 ----------------------------------------------^
AES128 ------------------------------------------^
AES256 ----------------------------------------^
AES-SK ---------------------------------------^

Okay, back to math.

23, 3, 1 ∩ 23, 18, 17 = 23
23 ∩ 18, 17 = null

Bang. Oops. 

Time to write the event.

Okay, well there's clearly a fault here. Why is the request only asking for RC4 and worse DES?

Well, because that's what the client was configured to send.

Why was it configured to send that? Because machine policy said so.

Addendum

Because of course it's always a little more complicated. After reports of clients also being configured for AES-only I reviewed the code again.

The "Requested ETypes" values in the log may also refer to the service account msDS-SupportedEncryptionTypes attribute.

The logger will choose which one to record based on a couple of conditions, so of course it's not actually guaranteed to be what's in the request, just sometimes. exasperated.gif

And for completeness if that attribute is zero, it pulls the value from the default enctype registry value.

So the above logic is still correct for why it fails. You asked for X, system said it only supports X, but the service in question is configured for Y.