Event 14 Kerberos Key Distribution Center after CVE-2022-37966¶
After updates to Microsoft Windows Server released in November 2022 you might be unable to configure Kerberos authentication on your proxy server as described in the article Step 5. Configure Kerberos authentication on Squid.
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
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.
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 (see https://learn.microsoft.com/en-us/windows/release-health/windows-message-center#2952).
But if you generated your Kerberos keytab as explained in the article Generate KeyTab file and enable Kerberos auth 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 absense 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 https://twitter.com/stevesyfuhs/status/1591127617071353856).
Fixes and Workarounds¶
Microsoft seems to have prepared the out-of-band update package to fix this error as explained in https://learn.microsoft.com/en-us/windows/release-health/windows-message-center#2961.
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.
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.
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.
Please note the keytab MUST be generated with
-crypto AES256-SHA1 encryption type as explained in the article Generate KeyTab file and enable Kerberos auth. 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.
For more information try reading the following articles: