There are a few things to know here:
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 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. |
Title: Message
- RE: [ActiveDir] LDAPS part 2 joseph.e.kaplan
- RE: [ActiveDir] LDAPS part 2 joseph.e.kaplan
- RE: [ActiveDir] LDAPS part 2 joe
- RE: [ActiveDir] LDAPS part 2 Douglas M. Long
- RE: [ActiveDir] LDAPS part 2 Mulnick, Al