Note: Originally, I wanted to put together a brief article describing how to stop using the RC4 cipher in the Kerberos protocol. What checks and changes to make to avoid problems after blocking it. But it turned out to be much more complicated. Understanding many situations requires knowing more and more details, especially for solving various problems. It was very challenging to find out some of these details. The article is now quite extensive (I have divided it into two parts). I try to provide accurate information, but many things are simplified and focus on the principle.
Types of Encryption and the RC4 Cipher in the Kerberos Protocol
For encrypting Kerberos tickets, the weak RC4 cipher is used by default (unless otherwise set), although AES (AES128 and AES256) has been supported since Windows Server 2008 and Windows 7. Before Windows 7 (where it started to be blocked by default), DES was also supported. In practice, RC4 is used in a smaller percentage of cases, but it is good to address this issue and ultimately block RC4.
A certain change occurred after installing the November 2022 update (or newer, hereinafter referred to as update 11/2022) on the Domain Controller (DC). Since then, AES256 has been used as the default for the Session Key, but for the Service Ticket, it can still be RC4 (more information later in the article).
Weak RC4 Cipher
RC4 has long been considered a weak cipher. When used with Kerberos, there is a known attack called Kerberoasting, where breaking it is about 800 times faster than when using AES. When RC4 is used for the Session Key, the vulnerability CVE-2022-37966 - Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability can be exploited.
Note: It is always important for security to have a sufficiently long (and complex) password.
Types of Encryption (Encryption Types)
Encryption Type (abbreviated as etype) is a specific combination of an encryption algorithm (cipher) with an integrity algorithm (hash function) to ensure data confidentiality and integrity. Basic information can be found in the article A general introduction to data encryption.
Microsoft globally supports encryption types:
- DES-CBC-CRC - etype 0x1 (1)
- DES-CBC-MD5 - etype 0x3 (3)
- RC4-HMAC - etype 0x17 (23)
- AES128-CTS-HMAC-SHA1-96 - etype 0x11 (17)
- AES256-CTS-HMAC-SHA1-96 - etype 0x12 (18)
Update 11/2022 adds a special variant that enforces AES Session Keys when using old ciphers (RC4)
- AES256-CTS-HMAC-SHA1-96-SK
Lists of ciphers can be found at Microsoft, for example in Network security: Configure encryption types allowed for Kerberos and more recently Supported Encryption Types Bit Flags.
Principles of the Kerberos Protocol and Encryption of Keys and Tickets
To understand other things, it is necessary to know the basics (and sometimes details) of how the Kerberos protocol works. I wrote a series of articles on this topic some time ago, Kerberos protocol with focus on SSO in AD DS, basic information can be found in the articles Kerberos part 4 - key terms of the Kerberos protocol and Kerberos part 5 - the principle of Kerberos authentication. There you will find important details, but I did not cover the encryption algorithms, which are of interest in this article.
On the Microsoft website, there is a popular article about disabling RC4 for encrypting Kerberos tickets, Decrypting the Selection of Supported Kerberos Encryption Types.
The official Kerberos documentation can be found in RFC4120, [MS-KILE]: Kerberos Protocol Extensions.
Basics of Kerberos
The basics of the Kerberos protocol are three communications/steps/Kerberos exchanges:
- central user authentication - the user authenticates to the Domain Controller (KDC - Key Distribution Center), communicates with the Authentication Service (AS), and obtains a TGT (Ticket-Granting Ticket)
- obtaining a service ticket - the authenticated user wants to access a specific service registered in the domain, communicates with the Ticket-Granting Service (TGS) on the Domain Controller, and obtains a Service Ticket
- authentication to the service - the user logs in (authenticates) to the service on a specific server, performing the Authentication Protocol (AP) exchange
Encryption of Objects in the Kerberos Protocol
In the Kerberos protocol, many data (keys, tickets, messages) are encrypted, and it is necessary for different parties (client, server/service, Domain Controller) to agree (support) on a specific encryption type. Various encryption algorithms and encryption keys are used for encryption.
For Kerberos, symmetric keys are mostly used, so the same key is used for encryption and decryption. Only two parties know the key, so one can verify the other by knowing the same key. This is done by encrypting the message; if the recipient can decrypt it, they must know the same key. Both parties must use the same encryption algorithm.
Below are the basic Kerberos objects that are encrypted (more precisely, a specific encryption type is used for them, and a hash function is used for the Session Key). Plus a brief principle and information on encryption, which is further elaborated in the following chapters (we focus mainly on the choice of encryption type).
- Authenticator - used to verify the user, it is an encrypted system time (timestamp), possibly also client identification, used to obtain the TGT (encrypted with the user's password, sent to the DC, the encryption type is negotiated between the client and DC based on the operating system), to obtain the Service Ticket (encrypted with the Session Key, encryption type from the Session Key) and during authentication to the service (encrypted with the Session Key, encryption type from the Session Key)
- TGT (Ticket-Granting Ticket) - used to verify the user at the DC (to obtain the Service Ticket), so the user's password does not have to be used, the client receives the TGT from the DC service krbtgt, which encrypts it with its password (account
KRBTGT), it contains the SID, Session Key, and other data, it can only be decrypted by the DC, since domain functional level 2008, AES encryption is used - Session Key - used to encrypt communication between the client and DC (when obtaining the Service Ticket, it encrypts the Authenticator and Session Key for the service) and between the client and service (encrypts the Authenticator), there is a unique Session Key for the TGT (the client receives it from the DC encrypted with its account password, the encryption must be supported by the client and DC, the client's request is evaluated) and for individual Service Tickets (the encryption type must be supported by the client and service/server, the client's request and the attribute
msDS-SupportedEncryptionTypesof the target account/service are evaluated) - Service Ticket - used to verify the user at the service, the client sends a request to the DC containing the service's SPN (Service Principal Name), TGT, and Authenticator (encrypted with the TGT Session Key), the DC creates the Service Ticket (contains the SID, user's name, Session Key for the service) and encrypts it with the service's password (it can be a computer account or a user (service) account or Group Managed Service Account), the client cannot decrypt it (receives the Session Key in the encrypted part of the
TGS-REPresponse), but sends it to the service for its verification, the DC chooses the encryption based on the attributemsDS-SupportedEncryptionTypesof the account (which has the required SPN assigned) - encrypted part of the response (Encrypted Response) - when the DC responds to requests (
AS-REP,TGS-REP), part of the message is encrypted, it contains the Session Key that the client needs to obtain, for the TGT it is encrypted with the user's password, for the Service Ticket with the TGT Session Key, the encryption type must be supported by the client and DC, it can be different from the encryption type of the contained Session Key
Principle of Kerberos Authentication (Briefly)
First, the client authenticates, sending a request for a TGT (AS-REQ) to the Domain Controller (KDC AS). Pre-Authentication is (usually) required, because it is (mostly) not included in the request, the DC returns the error KRB5KDC_ERR_PREAUTH_REQUIRED. The client creates a new request, adding the Authenticator (encrypted with the user's password). The DC decrypts and compares the timestamp (Authenticator), thus verifying the user. It creates the (TGT) Session Key and TGT (encrypted with AES256 and the KRBTGT password). It sends a response to the client (AS-REP), which contains the TGT (which contains the Session Key) and the Session Key in the encrypted part of the response (encrypted with the user's password).
When the client wants to log in to the service, it first requests a Service Ticket (TGS-REQ) from the Domain Controller (KDC TGS). The request includes the service name, domain, TGT, Authenticator (encrypted with the TGT Session Key), and other data. The DC creates the (Service Ticket) Session Key and Service Ticket (encrypted with the target service's password), each can use a different encryption type. It sends a response to the client (TGS-REP), which contains the Service Ticket (which contains the Session Key) and the Session Key in the encrypted part of the response (encrypted with the TGT Session Key).
For logging in to the service, the client sends an authentication request to the service (AP-REQ). It contains the Service Ticket and the Authenticator (encrypted with the Service Ticket Session Key). The service decrypts the Service Ticket and obtains the Session Key from it, using it to decrypt the Authenticator. If everything is in order, it obtains the user's name and sends a confirmation (AP-REP), where part of it is encrypted with the Service Ticket Session Key.
Encryption Keys
For simplicity, it is stated that a password of the user, service, or account is used for encryption. The user or service is always represented by a user account, computer, or Group Managed Service Account (GMSA) in AD (we do not address inter-domain communication using Trust Account here). In reality, a secret symmetric key (Secret Key - Long-Term Key) derived from the password using a hash function is used for encryption. For some parts, a Session Key is used, which is also created using a hash function.
When creating a key from a password, a salt is usually added, which for the user is composed of the domain (Realm DNS) and the username. Example: FIRMA.LOCALbouska. Detailed (but complicated) information can be found in the official documents on the page [MS-KILE]: Kerberos Protocol Extensions and will be further described in the second part (Keytab file - AES keys and salt). The goal is for users with the same password to have different keys. However, in the case of RC4-HMAC (RFC4757), MD4 hash is used and no salt. The key is compatible (the same) with the NTLM key.
The hash function is chosen according to the set/supported encryption types for the given account. If multiple are available, multiple keys are created, which are stored with the account in AD (Account keys) along with information about the used type. Keys are created when the account password is changed/set. All variants are created by default (we have AES256 key, AES128 key, RC4 key, DES key available). The encryption key is thus composed of a combination of the key type and the key value (when used, the appropriate key is selected from the available variants according to the type).
If we have an old account whose password was set at a time when AES was not supported, even if AES is now supported, it will not work until the password is changed/set. The DC logs event ID 14 (AS-REQ) or ID 16 (TGS-REQ) from the source Microsoft-Windows-Kerberos-Key-Distribution-Center, where the information Changing or resetting the password of <account name> will generate a proper key is provided.
The solution is to change the password, during which new keys are created, but it must be done twice in a row. I came across this information on forums and verified it in practice. After the first change, the DC still claimed that the account (service) only had an RC4 key. After the second change, AES started working. We will discuss this further in the second part (Double password setting - key creation).
Determining Existing Account Keys
To find out what keys the account has generated, we can use the DSInternals PowerShell Module and the cmdlet Get-ADReplAccount (Retrieving Active Directory Passwords Remotely).
Install-Module -Name DSInternals Import-Module DSInternals $cred = Get-Credential Get-ADReplAccount -SamAccountName bouska -Server DC1 -Credential $cred
KRBTGT Account and TGT Encryption
If the Domain Functional Level is Windows Server 2008 or higher, the KRBTGT account uses default AES encryption, but it must have AES keys issued.
Before blocking RC4, it is good to check that TGTs with AES are being issued (using the klist command). If not, the KRBTGT account password needs to be changed twice, perhaps using the Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 script (password rotation should be done regularly).
Choosing the Encryption Type and Encryption Key
Some important details (such as choosing encryption types in different situations) are quite difficult to find. RFC documents are quite challenging to study. Various articles on the internet contain incomplete or even incorrect information. I have drawn a lot of information from the blog of developer Steve Syfuhs, who develops authentication in Windows. But even here, I would say that there are incorrect information (and some things I find incomprehensible).
For example, the article Kerberos Event ID 27. From it, I would understand that the choice of encryption type (for Session Key and Service Ticket) is made as an intersection of types in the request (Requested ETypes), existing account keys, and supported (allowed) types of the domain controller (KDC supported ETypes).
I conducted practical tests, captured Kerberos communication (Wireshark), and put together my idea from previous information. Subsequently, I came across an article (general description of non-Microsoft Kerberos) MIT Kerberos Documentation - Encryption types and RC4 Is Still Considered Harmful. In the end, an old Microsoft article Encryption Type Selection in Kerberos Exchanges helped me the most, thanks to which I filled in a few missing details (I still omit or simplify some things).
It is quite important that a different encryption type can be used for encrypting the Session Key than for encrypting the response from the DC, where the Session Key is securely passed to the client (since this part is encrypted, the type used for the Session Key is not visible in the Kerberos packet, only for the encrypted part of the response).
How the Encryption Type is Chosen
There is a difference whether it is obtaining a TGT, i.e., AS-REQ, or obtaining a Service Ticket, i.e., TGS-REQ. The strongest common encryption type should always be used.
The decision-making always involves:
- domain controller (more precisely KDC) - issues and encrypts/hashes the Session Key and Service Ticket, so it must have the encryption type allowed (handled systemically plus via Group Policy) that will be used
- client (user on a specific computer) - wants to access the service, sends a request
AS-REQ/TGS-REQ, in which it lists the encryption types (sorted by preference) it supports (depends on the computer, not the user), needs to decrypt the Session Key from the response (uses it to encrypt the Authenticator sent to the DC/service), but not the TGT / Service Ticket (sends it originally encrypted)
When authenticating and obtaining a TGT, the following is added:
- client (represented by its account in AD) - the account in AD must have keys stored for various encryption types (used to encrypt the Authenticator and the response containing the Session Key)
When obtaining a Service Ticket, the following is added:
- service (represented by a user, computer, or GMSA account) - the account in AD must have keys stored for various encryption types (used to encrypt the Service Ticket) and the attribute
msDS-SupportedEncryptionTypeslists the supported encryption types
The domain controller must choose the encryption type for the Session Key, Service Ticket, and part of the response in the responses.
Choosing the Encryption Type for TGT
To obtain a TGT, the client sends a request AS-REQ, which also includes the username, domain, and computer name. The DC responds that Pre-Authentication is required and includes a list of acceptable encryption types (for which it has keys for the user), for AES also the salt. The client chooses a certain type and adds the encrypted Authenticator (with its password) to the request.
When the DC compiles the response AS-REP, it bases the encryption of the Session Key on
- allowed encryption types on the domain controller
- encryption types listed in the request (supported by the client)
To encrypt the part of the response (with the Session Key), it uses the same encryption type that was used for the Authenticator (of course, the DC must support it, otherwise it would not decrypt it).
For the TGT, it uses AES256 (if not disabled on the DC).
Below is an example of the described Kerberos packets for TGT. It is a situation (discussed in the second part User Login (TGT)), where the client supports AES, but the account only has an RC4 key stored. The DC responds with an error to the first AS-REQ request, stating that Pre-Authentication is required and lists the only supported encryption type RC4.
The second Kerberos AS-REQ request with the listed encryption types supported by the client. It contains the Authenticator encrypted with RC4, which is the only common option.
The Kerberos AS-REP response, where the client receives the TGT and Session Key with AES, but the response is encrypted with RC4.
Choosing the Encryption Type for Service Ticket
To obtain a Service Ticket, the client sends a request TGS-REQ, which also includes the TGT (contains the TGT Session Key) and the Authenticator (encrypted with the TGT Session Key).
When the DC compiles the response TGS-REP, it bases the encryption of the Session Key on
- allowed encryption types on the domain controller
- service account, what encryption types are allowed in the attribute
msDS-SupportedEncryptionTypes - encryption types listed in the request (supported by the client)
To encrypt the part of the response (with the Session Key), it uses the encryption type used in the TGT Session Key (i.e., the same as was used to encrypt the Authenticator).
For choosing the encryption type for the Service Ticket, the following applies:
- allowed encryption types on the domain controller
- service account, what encryption types are allowed in the attribute
msDS-SupportedEncryptionTypesand what keys are actually present in the account (used for encryption)
In practice, different encryption types can be used, which is currently happening with the application of AES256-CTS-HMAC-SHA1-96-SK. Then the Session Key is with AES, and the Service Ticket can be RC4.
The document Encryption Type Selection in Kerberos Exchanges contains another important piece of information in the section Encryption type of the service ticket. When choosing the encryption type for the Service Ticket, the attribute msDS-SupportedEncryptionTypes is considered plus RC4 (and DES). This would mean that it is possible to issue a Service Ticket with RC4, even if this cipher is not allowed on the account. This happened to me in one case in practice (mentioned in the second part in Special Behavior - Issuing RC4 Service Ticket).
Note: But I have no idea how to interpret the note in the FAQ at update 11/2022 that after the update, the automatic addition of RC4 or AES changed.
Below is an example of a Kerberos TGS-REP packet with described parts. A Service Ticket is issued for the service HTTP/www.firma.local. Both the Service Ticket and the Session Key use AES.
Information about Obtained Kerberos Service Tickets on the Client
In Windows, we can use the command line command klist, which lists all cached Kerberos tickets (TGT and Service Tickets) that the client has obtained. It shows for which identity (Client) and service (Server) the ticket was issued, which DC issued it (Kdc Called). And also what cipher (KerbTicket Encryption Type) was used to encrypt the ticket and for the Session Key (Session Key Type).
Note: Important if we use User Account Control (UAC). Then it depends on whether the command line is run normally or as an administrator (elevation prompt). Each situation displays different tickets because in the system, it is two different sessions (a different user access token is used).
Basic Use of the klist Command
An example of part of the output of the klist command, showing a Service Ticket for a web service (using a Keytab file and a service user account). This is how it looked years ago (before the 11/2022 update).
C:\>klist
Current LogonId is 0:0x4c2b5
Cached Tickets: (10)
#2> Client: bouska @ FIRMA.LOCAL
Server: HTTP/www.firma.local @ FIRMA.LOCAL
KrbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 4/25/2014 12:53:44 (local)
End Time: 4/25/2014 22:18:52 (local)
Renew Time: 5/2/2014 12:18:52 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: dc.firma.local
Current (after the 11/2022 update) output of the same Service Ticket.
#1> Client: bouska @ FIRMA.LOCAL
Server: HTTP/www.firma.local @ FIRMA.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize
Start Time: 1/8/2024 13:09:53 (local)
End Time: 1/8/2024 23:09:53 (local)
Renew Time: 1/15/2024 13:09:53 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: dc.firma.local
The same Service Ticket after setting the attribute msDS-SupportedEncryptionTypes on the service account to use only AES.
#1> Client: bouska @ FIRMA.LOCAL
Server: HTTP/www.firma.local @ FIRMA.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize
Start Time: 1/24/2024 10:54:21 (local)
End Time: 1/24/2024 17:13:37 (local)
Renew Time: 1/31/2024 7:13:37 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: dc.firma.local
Additional Options for the klist Command
List tickets issued for the system.
klist -li 0x3e7
You can also obtain a ticket for a specific service (SPN).
klist get HTTP/www.firma.local
For testing, it is useful to clear all cached tickets (so they can be obtained again).
klist purge
Finding Service Principal Names
It can be useful to find out which domain account has a specific SPN assigned.
C:\>setspn -Q HTTP/server.firma.local Checking domain DC=firma,DC=local CN=Server SSO,OU=Objekty,DC=firma,DC=local HTTP/server.firma.local Existing SPN found!
It is important how we construct the SPN we are querying. We often use the service class HTTP (for web services). If the SPN is assigned to a user account, we use HTTP. But if the service uses a computer account (e.g., IIS), it is identified using the HOST SPN (and the HTTP Service Class acts as an alias for the HOST SPN). So if the service address is the same as the computer address, we must search for HOST/server.firma.local.
The msDS-SupportedEncryptionTypes Attribute of Accounts in AD
We have mentioned the attribute msDS-SupportedEncryptionTypes several times, which determines the encryption type. It contains a list of encryption algorithms supported by the user, computer, GMSA, or trust account.
User accounts have the attribute msDS-SupportedEncryptionTypes empty by default. Computer accounts usually have the value set to 0x1C (28), which can be changed centrally using Group Policy. A computer with a supported Windows OS will set the value itself on its account in AD.
If the attribute has no value (or is 0x0), the encryption type RC4-HMAC-MD5 was traditionally used for backward compatibility. After the 11/2022 update, the default is AES256-HMAC-SHA1-SK. This can be changed with the DefaultDomainSupportedEncTypes key in the DC registry. We will discuss this further in the next chapter.
Values of the msDS-SupportedEncryptionTypes Attribute
Some possible values for the msDS-SupportedEncryptionTypes attribute:
- 0x4 (4) - RC4-HMAC
- 0x10 (16) - AES256-HMAC-SHA1
- 0x18 (24) - AES128-HMAC-SHA1, AES256-HMAC-SHA1
- 0x1C (28) - RC4-HMAC, AES128-HMAC-SHA1, AES256-HMAC-SHA1
- 0x1F (31) - DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES128-HMAC-SHA1, AES256-HMAC-SHA1
After the 11/2022 update, we have additional variants:
- 0x27 (39) - DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES256-HMAC-SHA1-SK
- 0x38 (56) - AES128-HMAC-SHA1, AES256-HMAC-SHA1, AES256-HMAC-SHA1-SK
- 0x3C (60) - RC4-HMAC, AES128-HMAC-SHA1, AES256-HMAC-SHA1, AES256-HMAC-SHA1-SK
How the value is constructed using flags with encryption types is described in Supported Encryption Types Bit Flags.
Manually Setting msDS-SupportedEncryptionTypes
The attribute msDS-SupportedEncryptionTypes can be manually set on a user account or computer account. You directly enter the numerical value into the attribute.
On user accounts, you can also use the settings on the Account tab (in Active Directory Users and Computers).
Group Policy - Configure Encryption Types Allowed for Kerberos
For computer accounts, you can specify which encryption types the Kerberos protocol can use on the device. Use Group Policy to set the policy Network security: Configure encryption types allowed for Kerberos in the path Computer/Policies/Windows Settings/Security Settings/Local Policies/Security Options. Network security: Configure encryption types allowed for Kerberos
After applying the policy, the computer will set the attribute msDS-SupportedEncryptionTypes on its account in AD. In practice, it appears that the policy is applied to the computer without a logged-in user (sets the encryption types used), but the attribute is changed when a user logs in.
Note: Setting this policy on the domain controller affects the entire domain.
Windows Update November 2022 (11/2022)
Microsoft released updates on November 8, 2022, which change the behavior of DCs. By default, AES Session Keys are chosen as a defense against the vulnerability CVE-2022-37966. The update also includes fixes for other vulnerabilities related to Kerberos (CVE-2022-37967) and Netlogon (CVE-2022-38023) protocols (and affects their behavior).
Windows Update November 8, 2022
Immediately after, reports emerged that some users who installed this update on their domain controllers (and had RC4 blocked) experienced numerous Kerberos authentication failures. Microsoft announced that this was not the expected behavior after tightening security and was working on a fix. On November 17, 2022, a special (Out-of-band) update was released for DCs (not needed elsewhere). It is not part of Windows Update; you must manually download the standalone package or cumulative update.
Windows Update November 17, 2022 Out-of-band
The January 10, 2023 update list of fixes, for example for Windows Server 2022 - KB5022291, also includes a fix for an issue related to RC4. According to some reports, this incorporates the OOB patch (e.g., 11B checker). In any case, today (with current updates installed), I have not encountered any issues (even with RC4 blocked).
Changes in Kerberos Protocol Behavior
With the November update, MS published an article KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966, which contains certain information about changes related to RC4 (many details are in the FAQ section).
After installing this update on the domain controller, the behavior when choosing the Session Key changes. It does not affect the encryption of the Service Ticket (which can still be RC4). Additionally, only the default value changes, i.e., if the account does not have the attribute msDS-SupportedEncryptionTypes set or it is 0. Instead of the original RC4-HMAC, AES256-CTS-HMAC-SHA1-96-SK is now used (according to What happened to Kerberos Authentication after installing the November 2022/OOB updates?, this means RC4_HMAC_MD5 Encrypted Ticket with AES256_CTS_HMAC_SHA1_96 Session Keys).
Default Domain Supported Encryption Types
It is even more complicated. A new registry key DefaultDomainSupportedEncTypes of type REG_DWORD was created in the path HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC. This allows setting the default encryption type for accounts that do not have it specified (attribute msDS-SupportedEncryptionTypes empty or 0) on the domain controller. By default, the key is not created in the registry, and its default value is 0x27 (39), which means DES, RC4, AES Session Keys.
This choice by Microsoft is somewhat peculiar because DES has long been unsupported, and AES is missing here. But supposedly, it is for compatibility reasons. In practice, this should cause AES256-CTS-HMAC-SHA1-96-SK to be used most of the time, but if AES support is missing, RC4 will be used.
Tests of DefaultDomainSupportedEncTypes and msDS-SupportedEncryptionTypes
I conducted tests of some variants. If the service account has the attribute msDS-SupportedEncryptionTypes set to 0, the user typically receives a Service Ticket with RC4 and a Session Key with AES256. If the attribute msDS-SupportedEncryptionTypes is set to 4 (RC4 only), they receive a Service Ticket with RC4 and a Session Key with RC4.
If the attribute msDS-SupportedEncryptionTypes is 0 and only AES is allowed on the DC (using Group Policy), they receive a Service Ticket with AES256 and a Session Key with AES256. If only RC4 is allowed on the DC, they receive a Service Ticket with RC4 and a Session Key with RC4.
I also tried setting the key DefaultDomainSupportedEncTypes to 28 (RC4, AES128, AES256) when msDS-SupportedEncryptionTypes is 0. Then the user receives a Service Ticket with AES256 and a Session Key with AES256. When I set the value to 4 (RC4), they receive a Service Ticket with RC4 and a Session Key with RC4.
Note: Changes to the registry key take effect almost immediately. Changes to the account attribute take a few tens of seconds.
Additional Impacts of the Update
It is also stated (for example, in the FAQ section of KB5021131 or What happened to Kerberos Authentication after installing the November 2022/OOB updates?) that if an account was previously set to support only AES, an RC4 key was still created, and if only RC4 was set, AES keys were created. After installing the update, the settings in the registry, msDS-SupportedEncryptionTypes, and DefaultDomainSupportedEncTypes are strictly used. A situation may arise where the client does not have support for the encryption types set on the service account (msDS-SupportedEncryptionTypes), and the DC does not issue a ticket, so the user cannot log in (even though login worked before applying the update). I have already mentioned that this information is not very clear to me.
Discussions indicate that the 11/2022 update causes operating systems that do not support AES to stop working. The solution should be to set the key DefaultDomainSupportedEncTypes to a value such as 0x1C (RC4, AES128, AES256). However, the current value of 0x27 already includes RC4, and my tests show that it is used. It may have been an original error in the update that was fixed.
Problems with the November 8, 2022 Update
I could not find an exact description of why the problem occurred after the 11/2022 update or what changes/fixes the OOB update makes.
In descriptions, such as in the OOB update, it is stated that the problem occurs if the Group Policy Network security: Configure encryption types allowed for Kerberos is set in the domain and the RC4 cipher is excluded. It manifests as event ID 14 from the source Microsoft-Windows-Kerberos-Key-Distribution-Center being logged in the DC system log and containing the text the missing key has an ID of 1. The ID in this context does not identify the key but the key operation.
Examples of events from the internet:
While processing an AS request for target service <service>, the account <account name> did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 3. The accounts available etypes : 23 18 17. Changing or resetting the password of <account name> will generate a proper key. While processing an AS request for target service krbtgt, the account squid did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 20 19 16 23 25 26. The accounts available etypes : 23 18 17. Changing or resetting the password ofsquid will generate a proper key. While processing an AS request for target service krbtg, the account did not have a suitable key for generating a Kerberos ticket (the missing key has an id of 1). The requested etypes 18 17 23 24 -135 3. The accounts available etypes: 23 18 17. Changing the password will generate a proper key.
Some of this information, and the advice to use the OOB update, is provided by MS in the Known issues in this update section of KB5019081.
There are many discussions on the internet indicating that the problem after the update appeared in accounts that have the attribute msDS-SupportedEncryptionTypes set and only AES is present (RC4 is blocked). Even if AES is supported by the client, service, and DC. There is a mention that it is a bug because the RC4 bit was used as a signal to select ciphers - the RC4 bit being used as a signal of whether it should use a preferred cipher list or a legacy interoperability list in a specific section of code.
Some articles discussing the situation: Microsoft patches from November 2022 cause problems, Kerberos Issues November 2022, Updates for Windows (Nov. 2022): Changes in Netlogon and Kerberos protocol - causing issues, KnowledgeBase: You experience errors with Event ID 14 and source Kerberos-Key-Distribution-Center on Domain Controllers.
Java and RC4 Support
In practice, it is not just about support/blocking of RC4 in Kerberos by Microsoft. For a long time, we may encounter the problem that logging into an application using Java stops working, often after updating the Java version. A practical example is an application on Apache Tomcat that uses a Keytab file. The solution is to set the service account to use AES and possibly reissue the Keytab.
Java has stopped supporting RC4 ciphers in Kerberos (JDK-8139348).
- JDK 17 - Released September 14, 2021
- JDK 11.0.17 - Released October 18, 2022
- JDK 8u351 - Released October 18, 2022
There are no comments yet.