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 RC4_HMAC_MD5 encryption type for Kerberos."
Please add support for modern ciphers and drop that obsolete RC4_MD5!
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?