Hello, Our security team seems a little antsy about this discovered privileged execution vulnerability (CVE-2017-8365) and wants us to patch the DCs and enable the newly-added “Extended Protection for Authentication” feature of SSPI. This will involve setting LdapEnforceChannelBinding key to “2” which requires all incoming SSPI bindings to use the “extended protection” channel-binding tokens. As you may have read, in order to do this, all clients (by clients meaning anything relaying Integrated Windows Auth) must be patched before the restrictions are enabled on the DCs via the Reg key. But, as with any major change to our domain security, I’m convinced there will be some software somewhere that won’t handle this properly. We’ve tested LDAPS Basic auth and it works fine (as expected, since it doesn’t use SSPI) and are going to test Mac workstation domain-joins next (which I hope under the hood are also doing LDAPS Basic auth.) Has anyone run into any issues after cranking this up to “2”? Any known use-cases of apps using SSPI for authN within LDAP that might get stung by this? Or are we making a mountain out of a molehill? Here’s the blog we are using as a basis of our plan: https://dirteam.com/sander/2017/07/13/security-thoughts-vulnerability-in-ntlm-credentials-forwarding-with-ldaps-could-allow-elevation-of-privilege-cve-2017-8563-important/ Thanks! Erik Coleman Identity and Access Management University of Illinois at Urbana-Champaign
Any CVE-2017-8365 Horror Stories?
- 981 Views
- Last Post 21 July 2017
My experiences with "extended protection" authentication are all in the context of web applications and not LDAP so I'm not sure I have a ton to add here. However, I'll guess that the basic principles of the types of things that caused problems with web apps would cause problems with LDAP clients as well.
There were two main problems I recall: - Incompatible browsers/user agents - SSL termination
For the first point, we used to have issues with Chrome on sites that used integrated auth with this turned on as Chrome (at the time) did not support extended protection negotiate auth. Applying this to LDAP, if you had a client using SSPI that did not support this SSPI feature and this feature was required, the auth might fail there too.
Also, SSL termination would frequently cause issues with extended protection when integrated auth was used in conjunction with SSL. So, if you had some type of load balancer for your DCs that supported SSL with SSL termination/offload, I would not be surprised if that caused problems with this setting if you have clients that are also using SSPI auth instead of simple bind.
I have no idea if that will be helpful here or not as you dig into this more.
Setting the key to 1 will break non-patched Windows systems even though the description makes it seem like it is opportunistic.
We are evaluating the impact on storage (netapp etc), UNIX and others like Java etc before enabling the key to either 1 or 2. I think this one is going to need a lot of testing..
I echo your concern. We have some legacy clients and non-Windows clients that auth to AD and we are considering setting to “1” but still don’t have good documentation
on the topic of what this actually does. But, I have to admit that I have not looked in the last few days. Is there better documentation on this than was originally posted on day 1?
Just looking at the same thing, Erik. Don't have anything to share yet, though. Thanks for the affirmation that I'm not alone. ;-)