joe wrote:
Standard Windows Active Directory AuthN/AuthZ isn't LDAP. It is Kerberos (and NTLM). It uses the LDAP Directory in the backend for its database to store credentials and group mapping as well as any other relevant data for the users and other objects as LDAP/DAP Directories were intended to be used.
While LDAP protocol can be used for authentication, Kerberos is the expected to be the safer authentication mechanism as no passwords are transferred in the requests as they are with LDAP authentication. When you log on with Windows to Active Directory, a Kerberos authentication occurs and the ticket is then passed with any/all LDAP requests after that to access data in AD, or on other servers.
That's quite a mischaracterization, as "LDAP authentication" isn't just any one particular mechanism. E.g., you can authenticate to LDAP using Kerberos tickets as well, using SASL/GSSAPI.
And while Kerberos is only an authentication mechanism, it is not the only authentication mechanism that exists. E.g., you can achieve analogous functionality using X.509 certificates.
That being said, some applications (generally *NIX apps) will authenticate to Active Directory with LDAP. If this is done, the Domain Controllers should have PKI certs on them and LDAPS or TLS should be used to secure the LDAP traffic otherwise the passwords are going across the network in clear text.Better is to use Kerberos which is possible via the open source kerb packages as well as there are several third party vendors now producing products to do it properly (and easily) including Dell (via Vintela/Quest product), Centrify, and BeyondTrust.
Again, a clear misunderstanding of the underlying technologies. Kerberos as used in LDAP also provides for securing of traffic, you don't need TLS if you have GSSAPI. And vice versa, TLS can be used both for the actual authentication step (using X.509 certs, as noted above) as well as for securing the traffic.