Further Exploration of KB5019964 Kerberos Changes

NOTE: See https://geekmungus.co.uk/?p=3619 for the most up to date article!

The following is my analysis going going deeper into my recent article: https://geekmungus.co.uk/?p=3532, hopefully this will give you a bit more context and information, but also allowed me to work through the issue in my head through documentation.

Synopsis

The patch KB5019964 changes what the allowed “default” type(s) are for the Session Keys within a TGS ticket, it removes: RSADSI RC4-HMAC(NT) as the allowed type and replaces it with: AES-256-CTS-HMAC-SHA1-96 (or AES-128), which if you have services (servers etc.) that don’t support these either cipher types you may find you have authentication issues.

What is the difference between the “KerbTicket Encryption Type” and the “Session Key Type” ciphers?

#0>     Client: USER123 @ DOMAIN.COM
        Server: krbtgt/DOMAIN.COM @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 11/16/2022 10:59:20 (local)
        End Time:   11/16/2022 20:59:20 (local)
        Renew Time: 11/23/2022 10:59:20 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: DC1.DOMAIN.COM

KerbTicket Encryption Type: The encryption type that is used to encrypt the Kerberos ticket.
Session Key Type: The encryption algorithm that is used for the session key.

So what does this actually mean in practice?

A Kerberos ticket is basically two keys, one wrapped inside the other. So the “KerbTicket Encryption Type” is the “outside” ticket, and the “Session Key Type” is the “inside” ticket, both of which can have the same or different encryption types depending on the encryption types supported by the KDC, the client and the service (that the client wants to access.)

So accessing a service means you need a TGT (ticket granting ticket) and then also obtain a TGS (Ticket Granting Service Ticket) from the KDC for the particular service you wish to access. The TGS ticket is encrypted with the “Session Key” from within the TGT (i.e. the “outside” ticket), but the “inside” ticket, i.e. the “Session Key” part within the TGS, has been encrypted with the service’s password hash. What this means is the client can decrypt the TGS ticket, but it can’t decrypt the “Session key” (i.e. the “inside” part), this can only be decrypted by the target service.

Also note that the TGT can’t be read by the client, it is only issued to the client (i.e. a specific user or computer account) for use for a finite period of time. The client when requesting a service ticket (TGS) would send the TGT along with the request. The TGT is only needed to be “read” by domain controllers (KDC’s) in the domain, from a client point of view, once issued a TGT, it doesn’t need to be able to open it, just having it means the client can then use it to gain access to other resources, so from a client’s point of view a TGT is just a token (of access).

Some Examples

My client machine is running Windows 10, the Domain Controller Windows 2016 Server, so both support AES256 encryption. So my TGT looks like this:

#0>     Client: USER123 @ DOMAIN.COM
        Server: krbtgt/DOMAIN.COM @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 11/16/2022 10:59:20 (local)
        End Time:   11/16/2022 20:59:20 (local)
        Renew Time: 11/23/2022 10:59:20 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: DC1.DOMAIN.COM

Now if as a client I wanted to access something that didn’t support AES256 (or 128) such as a really old NetApp filer, then the KDC (on the domain controller) would need to ensure the TGS ticket issued had encryption types used that were supported by the NetApp filer (or it would be unable to read the ticket). When a machine is joined to the domain and has a computer account created for it, it populates the “OperatingSystemVersion” attribute of the object. The Microsoft KDC uses this field to determine the compatibility for Kerberos encryption.

In the case of Windows 10 and Server 2016 both support AES256 cipher types, so the TGT can be encrypted with these types, no problem.

So here is a TGS ticket that was issued for my really old NetApp filer, as you can see its using RC4 cipher for both the “KerbTicket Encryption Type” (i.e. “outside”) and the “Session Key Type” (i.e. “inside”), this being that the NetApp filer only supports RC4.

#1>     Client: USER123 @ DOMAIN.COM
        Server: cifs/server1.domain.com  @ DOMAIN.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 11/16/2022 14:12:26 (local)
        End Time:   11/16/2022 23:47:44 (local)
        Renew Time: 11/23/2022 13:47:44 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)
        Cache Flags: 0
        Kdc Called: DC1.DOMAIN.COM

Now we know this what happens when stuff goes wrong?

Okay so let’s say that a setting is changed on the domain controller (KDC) that means it no longer supports the RC4 cipher for Session Keys (i.e. “inside” keys). In this situation when attempting to get a TGT nothing changes, both the client and the KDC support AES256 so all good. But when the client makes the request for a TGS, it gets back a TGS where the Session Key (i.e. “inside” key) has been encrypted with the AES256 cipher type instead of RC4, when passed to the old NetApp it can decrypt the “outside” part of the ticket as this was still encrypted with RC4, but the session key (i.e. the “inside” key) has been encrypted with AES256 which it doesn’t support. So now you have a problem, the NetApp can’t authenticate the client because it doesn’t support the cipher type used to encrypt the session key (i.e. the “inside” key).

Of course its also possible that the TGS “KerbTicket Encryption Type” (i.e. “outside”) key is set to something that the service (e.g. NetApp) doesn’t support so it can’t decrypt this either.

Okay, so digging in deeper to the problem, what happens then?

This Microsoft article really provides a good overview: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797 but i’ll distill the relevant point(s) here.

First up the article says this: “The session key selected for the TGT must be compatible with the client and the domain controllers of the issuing domain. The session key selected for a service ticket must be compatible with the client and the server hosting the resource.”

Which means that in the example above, my TGT where the KerbTicket Encryption Type is AES-256-CTS-HMAC-SHA1-96 and the Session Key Type is AES-256-CTS-HMAC-SHA1-96 is fine because both client and KDC support these types (being recent Windows).

Where the issue comes is when the TGS ticket type and/or the session key within is being encrypted with the wrong type, for example, the below. In this case the TGS Ticket (i.e. “outside”) is being correctly encrypted with RC4 which is all that the NetApp (service) happens to support, but and here is where the problem comes, the KDC settings change (due to a patch) has meant that it now the “Session Key Type” (i.e. the “inside” key) has been set to AES256, which the NetApp (service) doesn’t support.

#1>     Client: USER123 @ DOMAIN.COM
        Server: cifs/server1.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 11/16/2022 10:59:20 (local)
        End Time:   11/16/2022 20:59:20 (local)
        Renew Time: 11/23/2022 10:59:20 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DC1.DOMAIN.COM

Which means the client can’t be authenticated against this resource.

So now what?

Well, by default TGS ticket’s (i.e. Service Tickets) will be encrypted with RC4 for compatibility, unless the computer object has the msDS-SupportedEncryptionTypes attribute set otherwise or you have a GPO that defines the supported types (which might not include RC4).

When it comes to the session key (i.e. the “inside” key) of the TGS (service ticket) that cipher type is decided by the KDC based on the client request and the msDS-SupportedEncryptionTypes attribute of the target account, i.e. the NetApp’s computer account. Again with this normally it defaults to RC4. However if a setting is changed (due to a config change and/or update) the behaviour might have changed and so you find yourself with a ticket issued that the service (in this case the NetApp) can’t read.

What i’m seeing in the above is that KerbTicket Encryption Type is RSADSI RC4-HMAC(NT), which is fine, but the session key type is being forced to: Session Key Type: AES-256-CTS-HMAC-SHA1-96

Well, how do you fix this then?

Assuming you’re not going to be removing the November 8, 2022—KB5019964 which started all this by changing the behaviour, you need to manually configure any computer objects where the service to which it belongs, e.g. the NetApp in this example to force the KDC to still issue RC4 session keys. See: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797 for what values should be used.

The update above made the behaviour change for computer accounts with NULL value for msDS-SupportedEncryptionTypes attribute, so instead of issuing RC4 by default it now issued AES-256, thus creating the problem.

This: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/what-happened-to-kerberos-authentication-after-installing-the/ba-p/3696351 article goes into the real detail of what changed. Specifically this:

Prior to the November 2022 update, the KDC made some assumptions:

If the User’s/GMSA’s/Computer’s/Service account’s/Trust object’s msDS-SupportedEncryptionTypes attribute was NULL (blank) or a value of 0, the KDC assumes account only supports RC4_HMAC_MD5.

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/what-happened-to-kerberos-authentication-after-installing-the/ba-p/3696351

But now, after November 2022 Update the KDC Makes the following decisions:

If the User’s/GMSA’s/Computer’s/Service account’s/Trust object’s msDS-SupportedEncryptionTypes attribute was NULL (blank) or a value of 0, it defaults to an RC4_HMAC_MD5 encrypted ticket with AES256_CTS_HMAC_SHA1_96 session keys if the DefaultDomainSupportedEncTypes registry value is not configured on the KDC. If this value IS configured, then it uses the value defined in the registry.

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/what-happened-to-kerberos-authentication-after-installing-the/ba-p/3696351

This is exactly the behaviour we are seeing, the TGS (Service Ticket) is being encrypted with RC4, yep that’s right, we are seeing that: KerbTicket Encryption Type: RSADSI RC4-HMAC(NT), but the Session Key type (i.e. the “inside” key) is being set to: Session Key Type: AES-256-CTS-HMAC-SHA1-96.

To resolve this post update, we must set the DefaultDomainSupportedEncTypes registry value, https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d#registry5021131, this must be set to whatever we want the TGS (Service Ticket), session key encryption types to be (as default) which we want to continue to be RC4 until such a time that we can get rid of this ancient NetApp.

Basically it means you need to carry out the steps within: https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d#registry5021131 to each (and all) of your Domain Controllers (KDCs) to set what we want the “default” to be post patch, to ensure the default behaviour is not to select AES256 but continue to select RC4 (as well) for now.

The bit flag values can be found here: https://learn.microsoft.com/openspecs/windows_protocols/ms-kile/6cfc7b50-11ed-4b4d-846d-6f08f0812919

Basically in our situation we need to set the following within the registry of each domain controller, you’d then need to ensure that any tickets are purged and reissued using the desired cipher type. The default is as follows:

Registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC
Value: DefaultDomainSupportedEncTypes
Data type: REG_DWORD
Data value: 0x27 (Default)
Restart required? No

https://stories.schubergphilis.com/potential-fix-for-kdc-kerberos-issues-after-patching-for-cve-2022-37966-a12b6fba167f states:

According to KB5021131 and this linked article when this registry key is not set, its default value is (now?) 0x27 (39 dec.) which signifies that DES-CBC-CRC, DES-CBC-MD5, DES-CBC-RC4 and AES128-CTS-HMAC-SHA1–96 is supported and that RC4-HMAC, AES128-CTS-HMAC-SHA1–96 and AES256-CTS-HMAC-SHA1–96 are turned off.

So in which case the required RC4-HMAC will be disabled. So we need to change the “Data Value” to the below to put the behaviour to what it was pre-patch:

Hex: 0x1C (Decimal: 28, Binary: 00011100)

Which allows for: RC4-HMAC(MD5), AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96 which is basically where we want to be for now.

Alternatively to support all the types you could go with:

Hex: 0x1F (Decimal: 31, Binary: 00011111)

Which allows for: DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC(MD5), AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96.

• https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797
• https://learn.microsoft.com/en-us/archive/blogs/petergu/interpreting-the-supportedencryptiontypes-registry-key