JNDI LDAP with Active Directory with Signing
If you have used JNDI to connect to a Microsoft Active Directory LDAP Server you might see the Warning Event 2886 of source ActiveDirectory_DomainService (every 24 hours) telling you, that you should turn on LDAP Signing. This is also strongly recommended by Microsoft in their latest Security Advisory. They also will turn this on by default in the March 2020 (was January) Windows Server update.
I am not sure if this will actually happen, since a lot of legacy LDAP clients might need to be fixed first. I specifically had a look at Java with the LDAP Naming provider. (Update: as predicted Microsoft has postponed this for now).
If you use a simple bind or a default DIGEST-MD5 with no TLS (LDAPs) and no integrity or confidentiality protection you get the following exception for those Domain Controllers with the additional integrity=2 setting:
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C09023C, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4563
AD supports simple Binds, Kerberos (GSSAPI) and DIGEST-MD5 (SASL). The later two option can be configured to work with Request Signing:
- you must use the fully qualified hostname the LDAP Server think it has in the URL (you might need to make a /etc/hosts entry if your domains are not completely resolved by DNS.
- you Must enable DIGEST-MD5 as the Security mechanism
- the Account/principal you want to use for logins on the ActiveDirectory domain must have the reversible password encryption turned on and you must set the password after this change. If the user only has a password hash the LDAP directory will not be able to check the password and reject it (unfortunately with the same error as when the password is wrong):
javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C090569, comment: AcceptSecurityContext error, data 52e, v4563
If you use TLS (ldaps) instead, then you don't need to worry about signing. In fact in this case even simple binds will work. (And just for completeness, if you use SASL then you can't request auth-int or auth-conf in the TLS case with Microsoft Directory Service).