RE: [ActiveDir] LDAPS part 2

[joseph.e.kaplan]

Title: Message

There are a few things to know here: LDAP data will be passed in plain text on the network unless the channel is encrypted LDAP supports a concept called a SASL bind that allows your authentication to not pass plain text credentials, even if the channel isn’t encrypted.  SASL mechanisms are extensions, so different directories support different ones The lowest common denominator bind mechanism, simple bind, uses plain text credentials AD supports two methods for channel encryption, SSL and Kerberos   So, you can have plain-text or secure credentials with your binds depending on whether the client uses simple bind or an AD-supported SASL bind.  You can also have channel encryption using SSL or Kerberos, depending on what the client requested.  Kerberos encryption also requires that you use the SNEGO SASL bind mechanism which uses Kerberos for authentication.  A fine detail on the Kerberos thing is that NTLM also supports channel encryption for XP clients and higher, so a Kerberos bind isn’t strictly required in all cases.   So, the bottom line on encryption is that there are two methods, but one is MS proprietary.  It depends on the client to actually use them.  If the client doesn’t then all the data will be passed on the network in plain text.   LDAP Bind/authentication is somewhat orthogonal to channel encryption in that there are bind mechanisms that don’t use plain text credentials, regardless of the channel encryption being used.  Thus, you can have plain credentials on an encrypted channel using SSL with the net result of encrypted credentials, and you can have non-plain-text credentials on an unencrypted channel using a SASL bind mechanism.  Unfortunately, you can also have plain credentials on an unencrypted channel.  That is bad, but it happens all the time (see Joe Richards rants #116, 233, etc. J).  Personally, I think ADSI makes it to easy to do this the wrong way.   The main case for SSL is if you have third party software integrating with AD that don’t use the MS LDAP APIs and don’t support the MS SASL bind mechanisms or the Kerberos-based channel encryption feature.  I see this a lot with products that try to be cross platform such as the stuff we use from RSA here.  SSL is standards-based and is supported by a lot of different LDAP stacks, so it is the easiest way to get channel encryption.  Since a lot of non-MS LDAP stacks don’t support the MS SASL bind mechanism and use simple bind/plain text, you really really want to have SSL when using these products to protect credentials on the network, regardless of whether you were worried about the rest of the traffic.   The other really good reason to have SSL on your DCs is to get predictable behavior from the ADSI SetPassword and ChangePassword methods.  LDAP password changes require an encrypted channel to the DC and both of these methods try SSL first to do this.  They also try other stuff, but they are generally harder to get working and can be very difficult to diagnose when they don’t work.  For this reason, I always recommend that people set up SSL on their DCs if they will be using these features.   HTH,   Joe K.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas M. Long Sent: Tuesday, March 22, 2005 10:15 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] LDAPS part 2   I am feeling lost right now.   Without LDAP over SSL enabled, does AD pass LDAP traffic around in plain text? If so, exactly what information would that be (that is being passed in clear text)?   I have been wondering if I should implement a CA and LDAP over SSL, but I guess I don’t know all the implications.   If anyone knows of a good document, that should suffice. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.