Learn of the mysterious reason why certain Active Directory-joined appliances cannot use Kerberos AES encryption and the non-expected relationship to the operatingsystemversion attribute.
When users consume a service over Kerberos, the service ticket is encrypted with one of the three available options: DES, RC4, or AES. By far, the strongest encryption algorithm is AES.
Any Active Directory-joined device, either a Windows Server or a 3rd party appliance, will signal its supported encryption methods in a specific attribute called: msDS-SupportedEncryptionTypes.
A common value is the decimal number 28, meaning RC4, AES128, and AES256 is available when users are authenticating to the server.
When a client is to access a resource and strives to authenticate with Kerberos, the client will retrieve a service ticket from a Domain Controller. This service ticket is encrypted with the strongest encryption method support both at the client and the server (as well as the Domain Controller).
Assume the Active Directory has a number of domain-joined 3rd party appliances, e.g., the computer “TEST-APPLIANCE“.
When examining the msDS-SupportedEncryptionTypes of the TEST-APPLIANCE computer object, the value is the expected decimal 28, meaning RC4, AES128, and AES256 is available.
The computer object has the Service Principal Names (SPN) as displayed above.
With AES enabled on the account and with the knowledge of the SPN, we can now request a service ticket with the command line tool KLIST get.
Since the computer account supports AES, we would expect the acquire an AES encrypted service ticket. However, as seen in the output above, the ticket is encrypted only with RC4.
If examining the properties of the computer object, the Operating System tab displays the name of the operating system and the internal version of this appliance. Note here that the Operating System value has, in this example, been set to an example value. Typically, for non-Windows devices, values like “Linux RedHat” or “Cisco Identity Service Engine” would be example.
As will be displayed in the rest of this article, the Operating System does not matter, but the specific version does.
These properties corresponds to the attributes operatingSystem and operatingSystemVersion.
The operatingSystemVersion is typically used just for reporting and search purposes, and would not be expected to have any connection with the Kerberos encryption types that are usable for a device.
However, on the object having the operatingSystemVersion attribute with the example value of 4.86 and, while changing nothing else on the object, we will now increase the number to, e.g., 6.86.
Using the KLIST command, a new Kerberos ticket is now requested for the same ServicePrincipalName.
At start, the ticket received was encrypted with the weak RC4 method, even when AES was supported. Presently, with no other change than the increased operatingSystemVersion number, an AES encrypted service ticket for the resource is acquired.
In a typical Active Directory setup, there might be a number of non-Windows devices joined to the domain. These can use any arbitrary operating system and one would also expect the operatingSystemVersion to be an informational setting, only relevant to the system owner.
A quite unexpected, and unknown, built-in and hard-coded behavior of Active Directory is that Kerberos AES is not supported on devices where the operatingSystemVersion has a decimal value lower than 6.
If an Active Directory has a number of domain-joined devices, with the proper msDS-SupportedEncryptionTypes value of 28 (AES allowed), the usage of AES will still be prohibited if the operatingSystemVersion has a value lower than decimal 6.
The underlying reason for this behavior comes from the days of the introduction of Kerberos AES with Windows Server 2008. The two former Kerberos-enabled operating systems, Windows 2000 and Windows 2003, did not support AES.
The internal operatingSystemVersion values for Windows 2000 and 2003 was 5.0 and 5.2 The first version of Windows with AES support was Windows 2008, with internal version number of 6.
The non-expected behavior with the modern appliances is due to Active Directory making a, indeed slightly clumsy, effort to ensure AES encrypted service tickets are not presented to Windows 2000 and 2003 servers. AD will not read the value of the operatingSystem attribute, which would state something like “Windows 2003 Server”, but only read the operatingSystemVersion. If the value of this attribute is lower than 6.0, e.g. 5.11, the content of the msDS-SupportedEncryptionTypes attribute is ignored. Instead, only RC4 encryption will be available.
Microsoft states this to not be a bug, but by design. Unfortunately, this prevents the secure AES encryption for any devices, with any arbitrary operating systems having nothing to do with Windows 2000 and 2003, if the modern day operatingSystemVersion happens to be lower than decimal 6.
Note that the security downgrade issue occurs on the “incoming” side from the appliance’s perspective, i.e., when other clients are connecting to the device, the weak RC4 algorithm is enforced.
The only solution is to alter the attribute on the object itself. If the value starts with a number, AD will read from left to right up until the first dot. For AES to be allowed, the first digits, before the dot, must be 6 or higher. Note that the Attribute Editor must be used to change the value. It cannot be conducted directly on the Operating System tab GUI.
Since the operatingSystemVersion can have a reporting purpose, it might not make sense to increase, e.g., the value 5.86 to 6.86, for Kerberos AES to be available, but leave an incorrect version number visible. A potential work-around is to add a word in front of the numerical value, i.e., changing “5.68” to “Version: 5.68“. Since the attribute no longer starts with a decimal number, the secure AES encryption will be available.
To discover if any devices in the domain are vulnerable to the “RC4-downgrade” feature, use the following command lines. The LDAP filter will only display computer accounts that are enabled, that have at least one Service Principal name, that are configured to allow AES, but simultaneously having a operatingSystemVersion that prevents Kerberos AES.
dsquery * -filter "(&(objectclass=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2)(serviceprincipalname=*)(|(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=8)(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=16))(operatingsystemversion=1.*))" -limit 0 -attr operatingsystemversion operatingsystem samaccountname msds-supportedencryptiontypes serviceprincipalname
dsquery * -filter "(&(objectclass=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2)(serviceprincipalname=*)(|(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=8)(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=16))(operatingsystemversion=2.*))" -limit 0 -attr operatingsystemversion operatingsystem samaccountname msds-supportedencryptiontypes serviceprincipalname
dsquery * -filter "(&(objectclass=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2)(serviceprincipalname=*)(|(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=8)(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=16))(operatingsystemversion=3.*))" -limit 0 -attr operatingsystemversion operatingsystem samaccountname msds-supportedencryptiontypes serviceprincipalname
dsquery * -filter "(&(objectclass=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2)(serviceprincipalname=*)(|(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=8)(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=16))(operatingsystemversion=4.*))" -limit 0 -attr operatingsystemversion operatingsystem samaccountname msds-supportedencryptiontypes serviceprincipalname
dsquery * -filter "(&(objectclass=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2)(serviceprincipalname=*)(|(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=8)(msds-supportedencryptiontypes:1.2.840.113556.1.4.803:=16))(operatingsystemversion=5.*))" -limit 0 -attr operatingsystemversion operatingsystem samaccountname msds-supportedencryptiontypes serviceprincipalname
Any devices displayed can not currently use Kerberos AES. This state can be tested with the command KLIST get followed by the serviceprincipalname for the device.
Adjust, after proper investigation, the operatingSystemVersion values to enable AES encryption.