Spring Ldap Impact of Microsoft Security Advisory ADV190023 (LDAP channel binding and LDAP signing)

Question

We are using Spring Security Ldap Library (v4.0.4) to fetch a list of users from our client's Active Directory (ldap://domain:389) and to authenticate them to sign in to our web application.

Microsoft recently published an advisory to enable LDAP channel binding and LDAP signing: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

"LDAP channel binding and LDAP signing provide ways to increase the security for communications between LDAP clients and Active Directory domain controllers. A set of unsafe default configurations for LDAP channel binding and LDAP signing exist on Active Directory Domain Controllers that let LDAP clients communicate with them without enforcing LDAP channel binding and LDAP signing. This can open Active directory domain controllers to elevation of privilege vulnerabilities."

We were asked if enabling LDAP channel binding and LDAP signing on their servers would affect our processes. I couldn't find information regarding these in the documentation: https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#ldap

Are these supported by Spring Security Ldap Library (v4.0.4)? If so, is there any configuration we should change to make sure things are not affacted?

Answer 1

Here is the official answer I got from the project's Github page, for people who might find it useful:

https://github.com/spring-projects/spring-security/issues/8037

No, Spring Security's AD support only does simple binds with the user's username and password - the only security enhancement available is to use TLS. If an application needs channel binding, I'd imagine it would be via Java's GSS-API.

Since 4.0.x is no longer a supported branch, any added support would very likely go into modern versions of Spring Security.

Of course, if you find any issues along the way, or would like to suggest a feature, then don't hesitate to open another issue and maybe link it back to this one.