Add support for Kerberos AES and drop RC4_HMAC_MD5
Per "https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sso#manual-reset-of-the-feature" the "Seamless SSO uses the RC4HMACMD5 encryption type for Kerberos."
Please add support for modern ciphers and drop that obsolete RC4_MD5!
We are currently working on this
Shaw, David commented
Any update on this?
Alex Rourke commented
On 10/7/19, Microsoft updated the troubleshooting seamless SSO article: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sso.
Before, the section on Kerberos encryption stated: "Seamless SSO uses the RC4_HMAC_MD5 encryption type for Kerberos. Disabling the use of the RC4_HMAC_MD5 encryption type in your Active Directory settings will break Seamless SSO. In your Group Policy Management Editor tool ensure that the policy value for RC4_HMAC_MD5 under Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> "Network Security: Configure encryption types allowed for Kerberos" is enabled. In addition, Seamless SSO can't use other encryption types, so ensure that they are disabled."
Now, it says this: "Seamless SSO supports the AES256_HMAC_SHA1, AES128_HMAC_SHA1 and RC4_HMAC_MD5 encryption types for Kerberos. It is recommended that the encryption type for the AzureADSSOAcc$ account is set to AES256_HMAC_SHA1, or one of the AES types vs. RC4 for added security. The encryption type is stored on the msDS-SupportedEncryptionTypes attribute of the account in your Active Directory. If the AzureADSSOAcc$ account encryption type is set to RC4_HMAC_MD5, and you want to change it to one of the AES encryption types, please make sure that you first roll over the Kerberos decryption key of the AzureADSSOAcc$ account as explained in the FAQ document under the relevant question, otherwise Seamless SSO will not happen."
So the documentation now suggests that support has been added. Will test and let you all know.
We are currently working on this
Avi Carmon commented
Thank you all for the feedback. Acknowledges and know to the product group. This is currently in the works. Unfortunately it requires some low level changes that are taking us some time so it will be a few more months until we get this done.
Thomas Windscheif commented
Can't believe it's true. In year 2019 Microsoft still use unsecure ciphers for critical identity authorization. Either Microsoft remove seamless login or upgrade to AES.
I think MSFT will not work on this. They force to use hybid WHfB instead of sSSO....
Pavel Rozenberg commented
I agree! This is totally unacceptable for many organizations that are taking security seriously.
It is also very strange that Microsoft would release a security note and documentation alerting security teams of this protocol vulnerabilities and mitigation, but then implement it in a modern solution.
Here's a link to their docs page and KB explaining RC4 vulnerability and mitigation:
Samuel Leslie commented
This is an absolute showstopper for us w.r.t. usage of this feature and we'd really like to hear from any engineers who can provide some insight as to why such an old algorithm was chosen as the sole supported cipher for Seamless SSO.
The best practice has been to disable RC4_HMAC_MD5 for well over a decade, alongside the similarly obsolete DES_CBC_CRC and DES_CBC_MD5 algorithms. The AES encryption types have been supported since Windows Server 2008 and Windows Vista, so backwards compatibility shouldn't be a significant concern here?
Granted, the Kerberos ticket transmitted by clients for Seamless SSO is as far as I'm aware only ever sent over HTTPS, which should be using modern and far stronger encryption, but enabling support for RC4_HMAC_MD5 has to effectively be done domain-wide. That obviously opens up numerous risks in now allowing such an old encryption algorithm to be used by any Kerberos clients on the given domain.
Yes, it is also not well explained why this encryption method was chosen. Based on what I've read, it has a known vulnerability since at least 2014...why would that be the choice of Encryption for this service to begin with?