Auth-mageddon deferred (but not averted), Microsoft LDAP Changes now slated for Q3Q4 2020
Good news, sort-of - - Microsoft has deferred their March changes to LDAP, citing the Christmas change freeze that most sensible organizations implement as their reason:
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
(thanks very much to Erik van Straten for this news and link!)
Best advice? Stick to a remediation plan to migrate your LDAP clients to LDAPS, just know that you have a bit more time to implement.
That being said, what does remediation look like?
First, you'll need a trusted certificate on your Domain Controllers. While you could certainly buy one from a commercial CA, the easy way to do this is to stand up a Microsoft Certificate Authority in your Active Directory, which will issue DC Certificates automagically.
If there's any question about internal CA's, this command will tell you if you have a CA, and what server it's running on:
certutil -config - -ping
If you don't have a CA, it's a simple install if the web components aren't installed (no reboot is needed).
Next, you'll need to export the public certificate of your CA, so that your LDAP clients that aren't in AD will know to "trust" any certificates issued by that CA.
To export this from the CA, open "Certificate Authority" on the CA. Go to the CA Properties, choose the certificate / View Certificate / Details / then choose "Copy to File". If this is a subordinate CA, you'll want the Certificate Chain instead (in the next tab over, "Certificate Path"). Most clients will want either DER or Base-64 versions of the certificate. You can also export from the CLI using the command "certutil -ca.cert MyCARootCert.cer"
Then, over on the LDAP client, use the menu or config file for the application that is using LDAP, import this certificate. Be sure to import it as a Trusted CA. If you are unsure at this point, check the documentation on the product you are in to be sure.
On that same client, navigate to the menu or config file that has LDAP configured. Normally it's as simple as changing the protocol from LDAP to LDAPS, and changing the port from 389 to 636.
Test. Then test again, in particular with a different userid (that isn't an admin).
Rinse, then repeat for any other LDAP clients in your environment.
===============
Rob VandenBrink
rob@coherentsecurity.com
Comments
Anonymous
Feb 13th 2020
4 years ago
"The security of a directory server can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing (integrity verification) or to reject LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection."
Signing is integrity verification (which will be enforced in the updates). It's not the enforcement of mandatory encryption over SSL that requires a certificate, as far as I can see... Same as SMB signing, it's an anti-tamper mechanism that also requires no PKI infrastructure.
Not to say that LDAPS isn't a worthwhile improvement of course, but I don't think it's actually /necessary/ to avoid the world falling in when the patch lands.
Anonymous
Feb 13th 2020
4 years ago
The issue with SASL is that it permits a number of ways for the client to prove its identity via an unencrypted channel. This makes it subject to all kinds of attacks, which probably is why support for SASL-DIGEST-MD5 is no longer mandatory (see https://tools.ietf.org/html/rfc4513#appendix-B.2.4 ).
Hence the choice for a channel that protects both integrity and confidentiality (i.e. TLS) is preferred, which means that the client can securily prove its identity by using "simple" authentication AKA name/password.
A nice write-up by Kurt Roggen on how to migrate from LDAP to LDAPS can be found here: https://kurtroggen.wordpress.com/2018/08/03/are-you-using-ldap-over-ssl-tls/
Anonymous
Feb 14th 2020
4 years ago