Skip to content

Event 14 Kerberos Key Distribution Center after CVE-2022-37966

Note

This article is now obsolete, currently Kerberos authentication in Web Safety should work normally without any errors.

After updates to Microsoft Windows Server released in November 2022 you might be unable to configure Kerberos authentication on your proxy server.

Errors and Symptoms

When trying to upload a generated keytab file or just by opening the Squid / Auth / Active Directory Authentication / Kerberos page the following errors will be shown: 

Cannot run command kinit -V -k -t /opt/websafety/etc/krb5.keytab\
    HTTP/proxy.diladele.lan@DILADELE.LAN, error:
Using default cache: /tmp/krb5cc_115
Using principal: HTTP/proxy.diladele.lan@DILADELE.LAN
Using keytab: /opt/websafety/etc/krb5.keytab
kinit: KDC has no support for encryption type while getting initial credentials

kerberos_error

Event Viewer on your Microsoft Active Directory domain controller will indicate System error with Event ID 14.

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 of squid 
will generate a proper key.

kerberos_error_eventvwr

Reasons for Error

According to the article by Microsoft this error started to occur after the RC4-HMAC was removed from default supported methods of Kerberos authentication in the November 2022 update.

But if you generated your Kerberos keytab as explained in the article, it should already contain only aes256-cts-hmac-sha1-96 encryption type and should not be affected by these changes from Microsoft.

In reality though, it turns out that if an account which was used to generate the keytab has any of the following checkboxes set, the logic in Microsoft TGT Kerberos implementation incorrectly starts generating errors. It seems that the absence of RC4-HMAC bit in msSupportedEncryptionTypes attribute is used as a flag to use some fallback encryption in Microsoft Windows which confuses the Kerberos client on of the proxy (see this Twitter message).

kerberos_account_settings_wrong

Fixes and Workarounds

Microsoft seems to have prepared the out-of-band update package to fix this error.

If you do not want to install such out-of-band updates on your servers and would like to wait till official regular updates appear, use the following workaround to mitigate this issue temporarily.

The idea is to set the msSupportedEncryptionTypes attribute of the squid user to a predefined value that would allow the rc4-hmac encryption only for that specific user. This should not be a problem as our keytab only supports the aes256-cts-hmac-sha1-96 so the rc4-hmac is not used at all, just present in the Active Directory.

Open ADSIedit.msc on your domain controller and set the value of msSupportedEncryptionTypes to decimal 60 as shown on the following screenshot. This value enables the rc4-hmac | aes256-cts-hmac-sha1-96 | aes128-cts-hmac-sha1-96 encryption type.

adsi_edit_attribute

Reboot both your domain controller and proxy machine to clear the possibly cached Kerberos tickets. Also logoff from the client of the proxy to clear its cache of Kerberos tickets. After that try to browse the web from the client workstation and make sure the Kerberos ticket for the proxy is still encrypted with aes256-cts-hmac-sha1-96 by running the klist command as shown below.

klist_aes

Danger

Please note the keytab MUST be generated with -crypto AES256-SHA1 encryption type. If you are still using the older version of Web Safety (less than 8.2) you might need to regenerate and re-upload the keytab after the November 2022 updates by Microsoft.

References

For more information try reading the following articles: