An interesting thread on LDAP and authentication came up again today on activedir.org.  In the conversation, I had suggested that it would be a good feature if AD and ADAM had a setting somewhere that could be enabled that would prevent LDAP simple bind from working if the network channel was not secured (via SSL).  The problem with simple bind (for those not in the know) is that the user's credentials are passed over the network in plaintext, which is potentially a huge security risk (depending on the network).  It is actually even worse (by just a little) that HTTP basic authentication, as the credentials aren't even base64 encoded.

Eric Fleischman then pointed out that ADAM actually already has such a switch.  Tomek blogged about it here, so I'll let him cover the details on how to enable this.

I went on to suggest that AD should also have this feature (off by default for backwards compat most likely).  The problem is that without this feature, the AD admin really has no way to prevent apps that use simple bind for auth from sending plaintext credentials on the network, even if SSL has been configured.  You can't just turn off port 389 access to AD without breaking other stuff as you might be able to do in other directories.  Many of the NOS features of AD rely on port 389.

I also suggested adding an ability to audit simple bind attempts over non-SSL channels, including the IP address, so that admins have a way to track down rogue apps.

In many IT organizations these days, we must specify policies about how we are going to treat sensitive data (like passwords!) on the network and can get ourselves into hot water with our auditors if we are found to not be in compliance with our own policies.  At least with this auditing support in place, violations of the policy can be capture and violators may be traceable.

Also note that with most ADSI (and System.DirectoryServices programming in .NET), simple binds are not used.  Windows secure binds (using GSS-SPNEGO, which amounts to Kerberos or NTLM at the heart of it) are used by default.  You can get a simple bind, but you must do more work.  As such, most ADSI script code is not likely to have this problem.  You do have to be careful though.  We go into this in a great deal more detail in ch. 3 of the book.  Simple binds are very common with cross platform apps, and especially those that use non-MS LDAP libraries, as they often do not have the code they need to implement GSS-SPNEGO at all.  Some of them just use simple bind because it is the lowest common denominator protocol that all LDAP directories must support.

Anyway, it will be interesting to see if any of these suggestions come to fruition.  In the mean time, use SSL with your directories (ADAM too!) when doing simple bind.  Getting certs can be painful, but usually not as painful as getting hacked or failing an audit.  Unless your networks are totally secure between the endpoints and there is no threat of snooping, you need a secure channel.