Blocking RC4 in the Kerberos Protocol and Transition to AES
For many years, it has been recommended to stop using (block) the RC4 cipher and completely transition to AES. The 11/2022 update made a small step in this direction. We described the theory in the previous article Kerberos deactivation RC4 part 1 - protocol principle and encryption types. To understand the practical impacts and special situations, it is good to familiarize yourself with it.
Of course, we must not have systems in the network that do not support AES. This includes Windows Server 2003, Windows XP, or some old non-Microsoft systems. There may also be issues with network devices, such as old storage arrays used as file servers. It seems there is also a problem with support on standalone ESXi (vCenter supports AES, and ESXi for uses other than Kerberos as well).
Identifying Tickets Encrypted with RC4
Before changing settings (blocking RC4), it is good to find out where RC4 is used. The optimal procedure is to test the change for certain systems. Some situations require configuration changes.
Detection of Tickets Issued with RC4
If we have auditing enabled for Audit Kerberos Service Ticket Operations (Auditing Windows security events in a domain), we can find information about issued tickets in the Security log on the domain controller (DC). Among the information, the encryption type used (Ticket Encryption Type) is also listed.
The codes for the main encryption types are
- 0x3 (3) - DES-CBC-MD5
- 0x11 (17) - AES128-CTS-HMAC-SHA1-96
- 0x12 (18) - AES256-CTS-HMAC-SHA1-96
- 0x17 (23) - RC4-HMAC
- 0x18 (24) - RC4-HMAC-EXP
This is event Event ID 4769 for Service Ticket and Event ID 4768 for TGT. The content looks as follows
A Kerberos service ticket was requested.
Account Information:
Account Name: bouska@FIRMA.LOCAL
Account Domain: FIRMA.LOCAL
Logon GUID: {dad1327c-bdf9-564f-6a17-d8ce4788d2dc}
Service Information:
Service Name: app-sso
Service ID: FIRMA\\app-sso
Network Information:
Client Address: ::ffff:10.0.10.2
Client Port: 63670
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Failure Code: 0x0
Transited Services: -
Note: In some PowerShell examples below, a special character ` is used to split the line (command) for better display on the web (normally, a line break can follow | and ,).
If we have centralized logging, we can search the logs in our tool. Otherwise, we need to go through individual DCs using Event Viewer. The article HOWTO: Detect Kerberos tickets that are encrypted using RC4 provides a nice PowerShell script that simplifies this search. We need to run it on each DC. It displays information about Service Tickets issued with RC4 encryption.
$Events = Get-WinEvent -Logname security `
-FilterXPath "Event[System[(EventID=4769)]]and Event[EventData[Data[@Name='TicketEncryptionType']='0x17']]or Event[EventData[Data[@Name='TicketEncryptionType']='0x18']]" |
Select-Object `
@{Label='Time';Expression={$_.TimeCreated.ToString('g')}},
@{Label='UserName';Expression={$_.Properties[0].Value}},
@{Label='IPAddress';Expression={$_.Properties[6].Value}},
@{Label="ServiceName";Expression={$_.properties[2].value}},
@{Label="EncryptionType";Expression={$_.properties[5].value}}
$Events | Out-Gridview
Alternatively, we can run it centrally, calling it remotely for all domain controllers. For information about TGT, change the Event ID to 4768.
$dcs = Get-ADDomainController -Filter * | Select Name -ExpandProperty Name
$Events = ForEach ($dc in $dcs) {
Get-WinEvent -ComputerName $dc -Logname security `
-FilterXPath "Event[System[(EventID=4769)]]and Event[EventData[Data[@Name='TicketEncryptionType']='0x17']]or Event[EventData[Data[@Name='TicketEncryptionType']='0x18']]" |
Select-Object `
@{Label='Time';Expression={$_.TimeCreated.ToString('g')}},
@{Label='UserName';Expression={$_.Properties[0].Value}},
@{Label='IPAddress';Expression={$_.Properties[6].Value}},
@{Label="ServiceName";Expression={$_.properties[2].value}},
@{Label="EncryptionType";Expression={$_.properties[5].value}},
MachineName
}
$Events | Sort-Object TimeCreated -Descending | Out-Gridview
In the list, we will see Service Tickets encrypted with RC4, i.e., actively used services. It depends on how long our history is; some less used services may not appear here. In practice, we often see service accounts for which a Keytab file is issued.
Note: In event 4768, we can see that RC4 was used for the TGT. But often it is the encryption of the Session Key (and not the ticket). If the client only supports RC4, during pre-authentication, the Session Key for the TGT is encrypted with RC4, but the actual TGT is encrypted with AES.
Verifying Tickets on the Client
The second option is to display issued tickets on the client. We can work with the most informative systems (services) and then display the tickets using the klist command. More information can be found in the previous article Information about Obtained Kerberos Service Tickets on the Client.
Checking Accounts in Active Directory
Using PowerShell, we can find a lot of information about accounts in AD and list accounts with certain values. We can use cmdlets like Get-ADUser, Get-ADComputer, Get-ADServiceAccount, or Get-ADObject. Some attributes can be read as a regular user, but for many, we need sufficient permissions (Domain Admin).
Various scripts can be found on the internet that perform bulk checks. An interesting one is 11Bchecker, although it is focused on issues with the 11/2022 update. Another script is QuickChecks (description How Do I Know If My AD Environment Is Impacted By The November 8th 2022 Patch?), from which we can draw information. It focuses on displaying information where RC4 is not allowed, but we can modify it. There is a defined function Get-ETypeDefinition that can display encryption types instead of attribute codes msDS-SupportedEncryptionTypes.
Last time, we mentioned Values of the msDS-SupportedEncryptionTypes Attribute.
User (Service) Accounts (without AES)
Interesting are user accounts that have a Service Principal Name (SPN) set. These are used as service accounts for a particular service. Listing all these accounts.
Get-ADUser -filter 'servicePrincipalName -like "*" -properties msDS-SupportedEncryptionTypes, servicePrincipalName, whenCreated | Select sAMAccountName, servicePrincipalName, msDS-SupportedEncryptionTypes
In some situations, it may be useful to display when the account was created and when the password was last changed.
Get-ADUser -filter 'servicePrincipalName -like "*" -properties msDS-SupportedEncryptionTypes, servicePrincipalName, whenCreated, passwordLastSet, LastLogonDate | FT sAMAccountName, servicePrincipalName, msDS-SupportedEncryptionTypes, whenCreated, passwordLastSet, LastLogonDate, Enabled
Note: The last login date in the LastLogonDate (lastLogonTimestamp) attribute may not contain the correct information. For an accurate value, we need to read the LastLogon attribute from all DCs and take the latest value. Below is an example of displaying dates for the user USER.
Get-ADDomaincontroller -Filter * | % {$DC = $_.name ; Get-ADuser USER -properties * -Server $_.name |
Select @{n="LastLogon";e={[datetime]::FromFileTime($_.lastlogon)}},@{n="DC";e={$DC}} }
We can list only those accounts that do not have the attribute msDS-SupportedEncryptionTypes filled in, so the default value is used.
Get-ADUser -filter 'servicePrincipalName -like "*" -and (msDS-SupportedEncryptionTypes -eq 0 -or ` msDS-SupportedEncryptionTypes -notlike "*")' -properties msDS-SupportedEncryptionTypes, servicePrincipalName | Select sAMAccountName, servicePrincipalName, msDS-SupportedEncryptionTypes
Or those accounts where RC4 is allowed.
Note: The bitwise operator band (AND) filters values where the given bit is set.
Get-ADUser -filter 'servicePrincipalName -like "*" -and msDS-SupportedEncryptionTypes -band 0x4' ` -properties msDS-SupportedEncryptionTypes, servicePrincipalName | Select sAMAccountName, servicePrincipalName, msDS-SupportedEncryptionTypes
Another option is to list all objects that have RC4 set but neither AES128 nor AES256. That is, they only allow the use of RC4.
Get-ADObject -Filter 'msDS-SupportedEncryptionTypes -bor 0x4 -and -not msDS-SupportedEncryptionTypes -bor 0x18' ` -properties msDS-SupportedEncryptionTypes | Select Name, objectClass, msDS-SupportedEncryptionTypes
Old accounts that had their password set before AES support have only DES and RC4 keys created. They need to have their password changed twice (e.g., to the original) to create all keys. We can display accounts where the password was changed earlier than a certain year. We will discuss this issue in more detail in the next chapter.
Get-ADUser -filter * -properties whenCreated, passwordLastSet | Where-Object {$_.PasswordLastSet -lt (Get-Date -Year 2009)} |
Sort-Object PasswordLastSet | FT sAMAccountName, distinguishedName, whenCreated, passwordlastset
Probably a historical thing. On a user account, we can set that only DES is allowed. This sets the bit 0x200000 (UF_USE_DES_KEY_ONLY) of the UserAccountControl attribute. Check if it is set somewhere.
Get-ADUser -Filter 'UserAccountControl -band 0x200000'
When dealing with various accounts, we can search for which computer a certain account was used on. The solution is to search the Security log on the domain controller. A hint of possibilities, which could be greatly improved, is given below.
Get-WinEvent -FilterHashtable @{logname='security';id=4624;data='USERNAME'} |
Select-Object -Property timecreated,
@{label='username';expression={$_.properties[5].value}},
@{label='computername';expression={$_.properties[11].value}},
@{label='IP';expression={$_.properties[18].value}}
Computer Accounts (without AES)
Another area is computer accounts. Almost all of them have an SPN set. They usually also have the msDS-SupportedEncryptionTypes attribute set, but not always. We can list how many accounts exist with which attribute value.
Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes | Group-Object msDS-SupportedEncryptionTypes |
Select Count, Name
Count Name
----- ----
613 28
1 16
16 31
5
1 24
And then display which computers are in a certain category. The first example displays computers with an attribute value of 31 (DES, RC4, AES), the second with an empty attribute.
Get-ADComputer -Filter 'msDS-SupportedEncryptionTypes -eq 31' -Properties msDS-SupportedEncryptionTypes | Select Name, DNSHostName Get-ADComputer -Filter 'msDS-SupportedEncryptionTypes -notlike "*"' -Properties msDS-SupportedEncryptionTypes | Select Name, DNSHostName
We can list computers in a specific AD container, along with the value of the msDS-SupportedEncryptionTypes attribute.
Get-ADComputer -Filter * -SearchBase "OU=Počítače,DC=firma,DC=local" -Properties msDS-SupportedEncryptionTypes | Select Name, DNSHostName, msDS-SupportedEncryptionTypes
Some devices connected to the domain (such as Synology NAS, VMware vCenter) or special accounts (AZUREADSSOACC) may not have the msDS-SupportedEncryptionTypes attribute filled in, so they default to using RC4. Alternatively, (some) Linux systems have all ciphers enabled 0x1F (31).
Accounts without (usable) AES keys
In the previous part, we described the principle of the Kerberos protocol. From this, it follows that it is necessary to have appropriate keys issued for the account to use a certain encryption type.
User Login (TGT)
When logging in (issuing a TGT), the user uses their key to encrypt the Authenticator, and the DC uses it to encrypt the response with the Session Key. If the user's account in AD has only an RC4 key, it is encrypted using RC4. However, if both the client (computer) and the DC support AES, the TGT and Session Key are issued with AES (examples of Kerberos packets are in the first part Choosing the Encryption Type for TGT). Nowhere in the log or ticket listings will we see that the user has only an RC4 key. RC4 encryption support is necessary for the user to log in, even if it is only used for encrypting the initial communication.
Only when we block RC4 on the DC or the client's computer (using a policy) will the client not obtain a TGT (the DC has only an RC4 key, but this cipher is not allowed). The AS-REQ request will return an error KRB5KDC_ERR_ETYPE_NOSUPP.
Note: It should be added that, by default, if the user fails to log in using Kerberos, it falls back to NTLM, and the user logs in (but Kerberos does not work, of course). However, the user can no longer change their password (typically on this computer) because the Kerberos service is used. The error The encryption type requested is not supported by the KDC. will be displayed. If we block RC4 on the Exchange server, the password cannot be set even through OWA. Although logging into OWA or, for example, ActiveSync works (event ID 14 is logged in the System log on the DC ... did not have a suitable key for generating a Kerberos ticket).
Service Login (Service Ticket)
When logging into a service (issuing a Service Ticket), the DC uses the service's key to encrypt the Service Ticket. If the service account has only an RC4 key, RC4 is used. Only when we block RC4 on the DC will the Service Ticket not be issued. The msDS-SupportedEncryptionTypes attribute should apply to the service account, but even if we set only AES there, Service Tickets will still be issued with RC4. We mentioned that RC4 is added automatically for compatibility. The information that the ticket was issued with RC4 can be found in the DC log.
When we block RC4, and the account does not have available AES keys, an event should be logged on the domain controller in the system log (source Microsoft-Windows-Kerberos-Key-Distribution-Center) that a Kerberos ticket cannot be issued. During tests, the message sometimes did not appear, only in the Security log event ID 4771 Kerberos pre-authentication failed.
ID 14 ... did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 3. The accounts available etypes : 23.
And why doesn't an account have AES keys issued?
Most often because it was created earlier than when AES support was added to our domain (which came with Windows Server 2008, domain functional level 2008). And subsequently, there were no two new settings/changes to the password. There is a way to determine when AES support was added to the domain. It is the creation date of the Read-only Domain Controllers group. We can display it
(Get-ADGroup -filter * -properties SID,WhenCreated | where-object {$_.SID -like '*-521'}).WhenCreated
Tuesday, January 19, 2010 4:58:14 PM
If the account had its password last changed before this date, it definitely does not have AES keys. Example of searching for different types of objects.
$AESdate = (Get-ADGroup -filter * -properties SID,WhenCreated | where-object {$_.SID -like '*-521'}).WhenCreated
Get-ADObject -filter * -properties whenCreated, pwdlastset | Where-Object {$_.pwdlastset -gt 0 -and $_.pwdlastset -lt `
$AESdate.ToFileTime()} | Sort-Object pwdlastset | FT Name, ObjectClass, distinguishedName, whenCreated,
@{Label='passwordlastset';Expression={[DateTime]::FromFiletime([Int64]::Parse($_.pwdlastset))}}
It is easier to work only with user accounts (which often may be sufficient for us).
Get-ADUser -filter * -properties whenCreated, passwordLastSet, LastLogonDate | Where-Object {$_.PasswordLastSet -gt 0 `
-and $_.PasswordLastSet -lt $AESdate} | Sort-Object PasswordLastSet | FT sAMAccountName, distinguishedName, whenCreated,
passwordlastset, LastLogonDate, Enabled
Double Password Setting - Key Creation
On these accounts, we need to set the password again to create AES keys. When we subsequently look at the cmdlet Get-ADReplAccount, we will see in the KerberosNew section the created Credentials AES and DES (previously the section was empty). It looks exactly the same as when we create a new account (the password is set when created).
But AES does not work, and if we block RC4, the account will not log in with Kerberos. In the Kerberos response, where Pre-Authentication is required, only RC4 is offered. Only when we set the password a second time, we see Credentials and OldCredentials, and AES starts working correctly.
This probably applies only to old accounts that were created without AES support. They need to have the password set twice. When we now create a new account and set the password only when created, AES works correctly.
Therefore, we need to find accounts that were created before AES support and have only had the password changed once since then. This is a problem. We can list accounts created before a certain date (possibly limiting the password change to a recent period). For individual accounts, we can display available keys using the cmdlet Get-ADReplAccount.
Get-ADUser -filter * -properties whenCreated, passwordLastSet, LastLogonDate | Where-Object {$_.whenCreated -lt $AESdate} |
Sort-Object PasswordLastSet | FT sAMAccountName, distinguishedName, whenCreated, passwordlastset, LastLogonDate, Enabled
Get-ADUser -filter * -properties whenCreated, passwordLastSet, LastLogonDate |
Where-Object {$_.whenCreated -lt $AESdate -and $_.PasswordLastSet -lt (Get-Date -Year 2022)} | Sort-Object PasswordLastSet |
FT sAMAccountName, distinguishedName, whenCreated, passwordlastset, LastLogonDate, Enabled
Setting Up AES Usage
It is advisable to gradually change the settings of accounts that currently use RC4 and test if everything works correctly. Finally, we can block RC4 on the domain controller, so it cannot be used in communication with the DC.
Service Account and Keytab File
A common case where RC4 appears is service accounts for a web application that handles SSO login. In practice, they are created as user accounts and then a Keytab (key table) file is issued for them. A user account typically does not have the msDS-SupportedEncryptionTypes attribute set and uses default encryption. We want to change this.
It is important whether we specified, when creating the keytab using ktpass, with the crypto parameter, which keys (encryption types) should be issued into the file. It is often recommended to create all supported encryption types. If we did not specify, the file does not contain AES keys, and we need to issue it again.
Simply put, if we allow only AES on the account and SSO to the application stops working, we need to issue a new Keytab file. In rare cases, there may also be a problem that the server (application) does not support AES and needs to be addressed there.
Keytab File - AES Keys and Salt
As we mentioned in the previous part in the chapter Encryption Keys. For AES keys, salt is added, which contains the Realm (domain) and username. RC4 keys are created only from the password (so it does not matter what the name is and it can be changed). This can cause problems in some situations.
I came across an article Lessons in Disabling RC4 in Active Directory (or another On Adding AES Support to Kerberos.NET). From it, it seems that the sAMAccountName is used as the username, and when changing the UPN suffix of accounts (domain in User Principal Name), the salt changes, and thus the AES keys (when changing the password). But my tests (outputs from the Get-ADReplAccount command and capturing Kerberos communication) show that the domain is used for the salt (not the UPN suffix, which can be changed freely), and the username is taken from the User Principal Name (UPN), formatting the part before the @.
However, another problem may arise. When setting the password for the account, the entered password, domain, and username from the UPN account are taken (for AES), and keys are created from them. When creating a Keytab file using the ktpass command (we can also use another tool that has no communication with the domain, such as ktutil in Linux), the entered parameters are taken, and keys are created in the file from them (nothing is read from the account in AD). The Principal Name (princ) parameter is used, from which the username and domain are taken, and the Password (pass) parameter.
The problem is that princ also represents the Service Principal Name (SPN), which is used to find the service. For the keys in the Keytab and AD to be the same, we need to change the UPN of the account. The ktpass command does this by default, but we must not use the -setUpn parameter (which I used before). Some information is in the old discussion Enabling AES-encrypted single sign-on to Apache in a Win2008 domain.
If we want to keep the UPN of the account, we can, when creating the Keytab file with the ktpass command, use the -rawsalt FIRMA.LOCALusername parameter. Here we enter the salt that will be used when creating the keys in the Keytab (we enter the salt value from AD).
ktpass -out myweb.keytab -princ HTTP/myweb.firma.local@FIRMA.LOCAL -mapUser firma\\myweb-sso -mapOp set -pass password -ptype KRB5_NT_PRINCIPAL -kvno 0 -crypto AES256-SHA1 -rawsalt FIRMA.LOCALmyweb-sso -setupn
Entra Seamless SSO
If we use Seamless SSO in Entra ID (formerly Azure AD), we will probably see that the issued Service Tickets use RC4.
#2> Client: bouska @ FIRMA.LOCAL
Server: HTTP/autologon.microsoftazuread-sso.com @ FIRMA.LOCAL
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize
Start Time: 1/11/2024 13:18:08 (local)
End Time: 1/11/2024 22:18:12 (local)
Renew Time: 1/18/2024 12:18:12 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: dc.firma.local
It is recommended to set the msDS-SupportedEncryptionTypes attribute of the AZUREADSSOACC account to 0x10 (AES256). Then new Kerberos keys need to be issued for this account. Official information Microsoft Entra seamless single sign-on: Technical deep dive, further description Secure Active Directory + Azure AD SSO and disable RC4-HMAC.
The second special computer account related to Entra ID that we may have in the domain is AzureADKerberos. It is used for logging in with a FIDO2 security key or Windows Hello for Business. This account does not have an SPN set and has an empty msDS-SupportedEncryptionTypes attribute. Its setting may have no effect, but I tried setting it to 0x10 (AES256) and everything works.
Special Computer Accounts
Computer accounts used for issuing tickets. And that do not have the msDS-SupportedEncryptionTypes attribute set or have ciphers allowed that we want to block. We can try to reset and test functionality. In my case, I encountered a problem only with an old test ESXi 6.0, which apparently AES for Kerberos does not support (for other uses it does).
If we need to change in bulk, we can reconfigure the entire group with PowerShell.
Get-ADComputer -Filter 'msDS-SupportedEncryptionTypes -eq 31' -Properties msDS-SupportedEncryptionTypes | Set-ADComputer -KerberosEncryptionType AES128,AES256 Get-ADComputer -Filter * -SearchBase "OU=Počítače,DC=firma,DC=local" | Set-ADComputer -KerberosEncryptionType AES128,AES256
Setting Allowed Encryption Types on Computers Using Group Policy
In the previous part, we mentioned the policy Group Policy - Configure encryption types allowed for Kerberos, which we can set on computer accounts to allow only AES. From these computers, only the specified encryption types can be used for Kerberos.
This policy setting on clients (computers) does not affect the encryption type for the Service Ticket that the client obtains. Only if set on the server where the service runs and the service uses the computer account.
Blocking RC4 in the Domain
When we set the policy Network security: Configure encryption types allowed for Kerberos on domain controllers and allow only AES, we should effectively block the use of RC4 in the domain. As we mentioned, the domain controller chooses the encryption type for the Session Key and Service Ticket, and it must be one that is allowed.
Note: I came across a discussion where someone mentioned that they tested with various OS for DC, and the restriction worked only from Windows Server 2019. I have not tested older OS, but it seems to me that it should work everywhere in principle.
Registry DefaultDomainSupportedEncTypes
On domain controllers, we can set Default Domain Supported Encryption Types. We create the DefaultDomainSupportedEncTypes key in the registry at HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\services\\KDC. And set (for example) the value 24 (AES128, AES256). It may not be necessary if we set the policy on the DC to allow only AES. I mentioned my practical test that AES is used even with the default value.
Strange Behavior - Issuing RC4 Service Ticket
In practice, I encountered various behaviors that seemed strange or wrong. Gradually, I understood everything as I delved into the detailed principles of Kerberos. One example is here.
There is a user account under which a service runs on a Windows Server. When the client logged into the service using the application, they obtained a Service Ticket with RC4 and a Session Key with AES256. That would be normal. But after setting the msDS-SupportedEncryptionTypes attribute of the user account to the value 24 (AES128, AES256), there was no difference (in all other cases, this setting worked). Later, I read that RC4 is automatically added among the supported types. Therefore, when AES could not be used, RC4 was used.
I found the cause of the problem only after setting the policy on the DC to allow only AES. At this point, the ticket was not issued, and the event Kerberos-Key-Distribution-Center ID 16 was logged with the text
The requested etypes were 18 17 23 3 1. The accounts available etypes were 23.
After checking the account, it turned out to be very old and had only DES and RC4 keys created. After changing the password twice, everything started working, and the Service Ticket was issued with AES256.
Error Checks After Enforcing AES
Events from the source Microsoft-Windows-Kerberos-Key-Distribution-Center are logged in the system log of Windows on the DC (found in the Event Viewer filter as Kerberos-Key-Distribution-Center). We can go through all errors and warnings. The most common problem can be seen in the events:
- Event ID 14 - Kerberos Key Integrity (KDCEVENT_NO_KEY_INTERSECTION_AS)
- Event ID 16 - Kerberos Key Integrity (KDCEVENT_NO_KEY_INTERSECTION_TGS)
- Event ID 26 - KDC Encryption Type Configuration (KDCEVENT_UNSUPPORTED_ETYPE_REQUEST_AS)
- Event ID 27 - KDC Encryption Type Configuration (KDCEVENT_UNSUPPORTED_ETYPE_REQUEST_TGS)
The event text is very similar in all cases. The meaning is that a suitable encryption type could not be found.
While processing an [AS/TGS] request for target service %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes were %4. The accounts available etypes were %5. [Changing or resetting the password of %6 will generate a proper key.]
In some cases, the error provides clear information, but often it does not. It shows what encryption types were in the request and what keys the account has available. Missing is information on what encryption types the account has allowed and what is set on the DC. Various examples are given in the article What happened to Kerberos Authentication after installing the November 2022/OOB updates?.
For example, when the client supports (and requests) only AES, the account has RC4 and AES keys but the msDS-SupportedEncryptionTypes attribute is set to 4 (RC4). The ticket is not issued and an error is logged.
ID 16 ... Kerberos ticket (the missing key has an ID of 8). The requested etypes were 18 17. The accounts available etypes were 23 18 17.
Another example where the client supports RC4 and AES, the account has only RC4 keys, and only AES is allowed on the DC.
ID 16 ... Kerberos ticket (the missing key has an ID of 9). The requested etypes were 18 17 23 3 1. The accounts available etypes were 23.
A computer account for a standalone ESXi server connected to the domain that does not support AES. When RC4 is disabled in the domain, it does not get a TGT.
ID 26 ... Kerberos ticket (the missing key has an ID of 3). The requested etypes were 23. The accounts available etypes were 23 18 17.
If a user account does not have (usable) AES keys and only AES is allowed on the computer, it does not get a TGT.
ID 14 ... Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 3. The accounts available etypes : 23.
Important information is hidden in the text the missing key has an ID of %3, where the ID does not identify the key but the key operation. Unfortunately, Microsoft keeps the meaning of these identifiers secret. I found some information in the article Kerberos Event ID 27. According to it, ID 9 means Service Ticket Encryption and ID 8 means a missing AES key (the key may exist, but the account is set to only RC4, so AES cannot be used).
Events from the log can be listed using PowerShell from all DCs.
$dcs = Get-ADDomainController -Filter * | Select Name -ExpandProperty Name
$Events = ForEach ($dc in $dcs) {
Get-WinEvent -ComputerName $dc -FilterHashtable @{LogName='System'; Id=14,16,26,27} |
Where-Object {$_.ProviderName -eq "Microsoft-Windows-Kerberos-Key-Distribution-Center" } |
Select-Object TimeCreated, MachineName, Id, Message
}
$Events | Sort-Object TimeCreated -Descending | Out-Gridview
There are no comments yet.