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.
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.
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.
Danger
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.
References
For more information try reading the following articles: