- Join Windows 11 to an Active Directory domain - Thu, Jun 1 2023
- Change Windows network profiles between public and private - Wed, May 24 2023
- How to map a network drive with PowerShell - Wed, May 17 2023
Microsoft's automatic switch to stronger encryption may be hindered by an unfavorable configuration in some environments. This is the case if specific algorithms have been explicitly assigned to certain accounts.
You should also check whether certain encryption methods have been configured by group policy. The setting Network Security: Configure encryption types allowed for Kerberos is responsible for this. It can be found under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
If, among others, DES has been enabled here, which is no longer supported in Windows by default, then you should check whether the Use only Kerberos DES encryption types for this account flag in the UserAccountControl attribute is set for any accounts. If it is, the affected accounts are limited to the outdated and insecure DES algorithm, and you should disable this setting.
For individual users, you can do this in Active Directory Users and Computers under the Account tab.
If you want to find all users that were configured this way, the following PowerShell command will do the trick:
Get-ADUser -Filter 'UserAccountControl -band 0x200000'
The bitwise and of UserAccountControl with 0x200000 shows whether the DES encryption flag is set. If you want to remove this, you can do so as follows:
Get-ADUser -Filter 'UserAccountControl -band 0x200000' | foreach {Set-ADAccountControl -Identity $_ -UseDESKeyOnly $false}
Check for RC4
Active Directory is inconsistent in storing the preferred algorithms for Kerberos encryption. While the UserAccountControl attribute is used to enforce the exclusive use of DES, the general encryption configuration is stored in msDS-SupportedEncryptionTypes.
This attribute, with the data type unsigned long, also serves as a bitmask, so you have to check the status of each flag to see which algorithms are allowed. In the case of RC4, this is the third bit. Accordingly, a query would look like this:
Get-ADUser -Filter 'msDS-SupportedEncryptionTypes -band 0x4' -Properties msDS-SupportedEncryptionTypes | Select name, msDS-SupportedEncryptionTypes
Remove RC4 from the attribute
To remove RC4 from these accounts, you can proceed as follows:
Get-ADUser -Filter 'msDS-SupportedEncryptionTypes -band 0x4' -Properties msDS-SupportedEncryptionTypes | foreach{ $NewEncTyp = $_.'msDS-SupportedEncryptionTypes' - 0x4 Set-ADUser -Identity $_ –replace @{'msDS-SupportedEncryptionTypes'=$NewEncTyp} }
Subtracting 4 sets the third bit to zero, but the values for all other algorithms are preserved.
On the other hand, if you want to completely rewrite the attribute, you can use the KerberosEncryptionType parameter for this purpose:
Get-ADUser -Filter 'msDS-SupportedEncryptionTypes -band 0x4' -Properties msDS-SupportedEncryptionTypes | foreach{ Set-ADUser -Identity $_ -KerberosEncryptionType "AES128,AES256" }
In the above example, we assign the two AES algorithms to all accounts that have previously configured RC4 as a permitted algorithm. If we use "none" as the value for the parameter, then the attribute is set to 0x0, and the account thus uses the default method for encryption.
Document encryption type for all users
If you want to document the status of the AD attribute for Kerberos encryption, you can do so using the table in this blog post. It contains not only the values for the individual algorithms but also for all combinations of them.
The following script generates CSV output for all user accounts, which you can write to a file if needed:
$encTypes = @("Not defined - defaults to RC4_HMAC_MD5","DES_CBC_CRC","DES_CBC_MD5","DES_CBC_CRC | DES_CBC_MD5","RC4","DES_CBC_CRC | RC4","DES_CBC_MD5 | RC4","DES_CBC_CRC | DES_CBC_MD5 | RC4","AES 128","DES_CBC_CRC | AES 128","DES_CBC_MD5 | AES 128","DES_CBC_CRC | DES_CBC_MD5 | AES 128","RC4 | AES 128","DES_CBC_CRC | RC4 | AES 128","DES_CBC_MD5 | RC4 | AES 128","DES_CBC_CBC | DES_CBC_MD5 | RC4 | AES 128","AES 256","DES_CBC_CRC | AES 256","DES_CBC_MD5 | AES 256","DES_CBC_CRC | DES_CBC_MD5 | AES 256","RC4 | AES 256","DES_CBC_CRC | RC4 | AES 256","DES_CBC_MD5 | RC4 | AES 256","DES_CBC_CRC | DES_CBC_MD5 | RC4 | AES 256","AES 128 | AES 256","DES_CBC_CRC | AES 128 | AES 256","DES_CBC_MD5 | AES 128 | AES 256","DES_CBC_MD5 | DES_CBC_MD5 | AES 128 | AES 256","RC4 | AES 128 | AES 256","DES_CBC_CRC | RC4 | AES 128 | AES 256","DES_CBC_MD5 | RC4 | AES 128 | AES 256","DES+A1:C33_CBC_MD5 | DES_CBC_MD5 | RC4 | AES 128 | AES 256") $EncVal = Get-ADUser -SearchBase "OU=Finance,DC=contoso,DC=com" ` -Filter * -properties msDS-SupportedEncryptionTypes foreach($e in $EncVal){ try { $e.Name + "," + $encTypes[$e.'msDS-SupportedEncryptionTypes'] } catch{ $e.Name + "," + $encTypes[0] } }
The try/catch section catches errors caused by the attribute not containing any value if the user has never logged in.
According to the table, a value of 0x0 corresponds to "Not defined - defaults to RC4_HMAC_MD5". However, this changes with KB5019081 so that Microsoft will use AES as the default in the future. This should be updated accordingly in the script.
Summary
Since Kerberos tickets are often a target for attacks to gain elevated privileges, you should make sure that Active Directory uses strong encryption for this purpose. DES and now RC4 do not meet this requirement.
Subscribe to 4sysops newsletter!
With the November 2022 update, Microsoft automatically switched to AES unless accounts were specifically assigned a different algorithm. Therefore, it is important to check AD users to see if they are set solely to DES or if they have been explicitly configured for RC4.
Hi Wolfgang, this topic is quite complicated to be understood. I think I miss some background regarding operations that involve bits (such as the “-band 0x4”) you used in the PS script. Maybe you could provide some good readings about this.
But apart from this, I wanted to ask you a thing: If before applying the November update to clients and DCs, I set that msDS-SupportedEncryptionTypes to 28 (11100 bitmask), so that I tell DCs and client to allow TGTs with both RC4 and AES encryption types, would I temporarily be able to continue using legacy OSes such as Windows 2003, so that I can connect from 2003 to 2012 and vice-versa? Or the November update prevents me from explicitly set RC4 encryption type at all?
Thank you very much.
Francesco
Hi Wolfgang,
Thank you for a very useful article and script. I am using it to find and enforce AES on the user accounts. I am think if it isn’t defined after the update it defaults to AES but in case there is a problem defining it might be better.