How LDAP Authentication works with Active Directory and the UWWI

This document provides background on what LDAP authentication is, what specific LDAP authentication methods and mechanisms Active Directory and UWWI supports, and finally gives some guidance on which method and mechanism you should use.

LDAP Authentication

LDAP authentication is a loaded term which simply means to issue the LDAP BIND operation. Since the LDAP BIND operation is very flexible, this means there are a variety of forms this authentication might take. These forms include extremes such as:

cleartext passwords over the wire
no identifying name specified
choosing not to authenticate
authentication with a certificate
authentication using some custom method

as well as more traditional forms where a name (username) and password are used, and the password is encrypted on the wire or a private/public key algorithm used to protect the password.

Active Directory supports all the LDAP standard authentication mechanisms, as well as a few more, but many of these more extreme forms are not supported by UWWI, usually because they violate computing standards.

The LDAP standard introduces the various forms of authentication by first categorizing them as authentication methods, with various authentication mechanisms underlying each method. This document follows that organizational precedent.

Authentication Methods

There are two primary authentication methods that must be supported by RFC standard:

Simple Authentication Method
SASL Authentication Method

Other authentication methods *may* be supported, but are not part of the LDAP standard and so are likely to be less widely used by LDAP applications.

Each method has many authentication mechanisms, and the RFC standards specify that a number of these mechanisms must be supported.

Active Directory may accept a number of additional methods, but because of lack of good Microsoft documentation, these additional methods can't be covered here at all. However, this lack of documentation also means that applications won't know how to use them either, so Active Directory might as well not provide these undocumented methods at all.

Simple Authentication Method

The simple authentication method provides three authentication mechanisms:

Anonymous Authentication Mechanism of Simple Bind
A simple LDAP bind operation with a name and password value of zero length. UWWI allows this, but you can't do anything meaningful.
Unauthenticated Authentication Mechanism of Simple Bind
A simple LDAP bind operation with a non-zero length name that corresponds to a valid user entry and a password value of zero length. UWWI allows this, but you can't do anything meaningful.
Name/Password Authentication Mechanism of Simple Bind
A simple LDAP bind operation with a name that corresponds to a valid user entry and the password value corresponding to that user entry. The password is sent in cleartext over the wire.

This is possible with UWWI, however, using this mechanism without first initiating session level encryption is prohibited by UWWI because it fails to meet UW computing standards. Currently there is no way to turn off this functionality, but should a way to turn this mechanism (w/o session-level encryption) become available, it will be turned off.

You can initiate session level encryption via a StartTLS operation or by using IPsec. We *strongly* recommend that a network sniffer first be used with any application that must use this authentication mechanism to verify that it is using session-level encryption and not exposing UW NetID passwords.

Fast Bind for Authentication Only

In addition to authentication methods and mechanisms, there is one noteworthy LDAP session option that may be of interest. The Concurrent bind or Fast Bind session option can be used by applications to authenticate users, assuming that only authentication is needed, and no subsequent LDAP operations requiring authorization are needed. A Fast Bind does not build a user token; it only verifies the username and password--so subsequent LDAP operations that would require the authorization information in that token are not allowed. The LDAP Fast Bind requires that the Simple Authentication Method be used, and so TLS or IPsec must be used in association with making use of this option. Sample code and more information are available on MSDN.

SASL Authentication Method

The SASL authentication method is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. The SASL standard (RFC4422) only defines one such mechanism, the EXTERNAL authentication mechanism, however the SASL standard expects many authentication mechanisms to be defined to work within its framework.

Active Directory supports four SASL authentication mechanisms:

GSSAPI Authentication Mechanism

The GSSAPI authentication mechanism (RFC2743) allows the client to pass GSSAPI tokens to the server to establish their credentials. In this case, valid GSSAPI tokens are a Kerberos TGT or NTLM token (although some Microsoft documentation erroneously claims that GSSAPI is limited to Kerberos). A confidentiality feature can be employed as part of GSSAPI to encrypt the token and authentication exchange.

A SASL GSSAPI LDAP bind operation with a name that corresponds to a valid user entry and the password value corresponding to that user entry. The password is not sent over the wire at all, instead the token representing the user is sent.

UWWI recommends this authentication mechanism. When it is known that the client can only negotiate NTLMv2, we suggest that a network sniffer be used with any application to verify that the confidentiality feature is used to protect NTLM tokens.
GSS-SPNEGO Authentication Mechanism

The GSS-SPNEGO authentication mechanism (RFC4178) is actually the GSSAPI authentication mechanism but with a client-server negotiation mechanism that provides for selection of the preferred security mechanism that both client and server support. In this case, the server will prefer Kerberos then NTLMv2 then NTLM (UWWI does not support LM). For that reason, refer to the GSSAPI authentication mechanism for further details.
EXTERNAL Authentication Mechanism

The EXTERNAL authentication mechanism allows the client to request that the server use credentials established by a means external to the mechanism to authenticate the client. The external means might be via information in IPsec or TLS or some other other means. What means are used depends on the server, and there is no negotiation of what those means are, so the client must know beforehand what the means are, and provide them.

A SASL EXTERNAL LDAP bind operation is issued with either:
- a non-zero length name that corresponds to the valid user entry desired
or
- a zero length name if the client wants the server to map the results of the external mechanism to the appropriate user entry.

Active Directory supports the SASL EXTERNAL authentication mechanism via TLS and user certificates that are mapped onto user accounts. This is considered a very strong authentication mechanism.

UWWI does not support user certificates at this time, so the SASL EXTERNAL authentication mechanism is not an option at this time.
DIGEST-MD5 Authentication Mechanism

The DIGEST-MD5 authentication mechanism (RFC2831) provides a mechanism for the HTTP Digest authentication (RFC2617) challenge/response paradigm to be used within the SASL framework. Because this mechanism relies on HTTP 1.1, it has a smaller set of uses.

This mechanism sends a MD5 checksum of the password over the wire without encryption. This is superior to sending a cleartext password with a simple bind, but is not considered strong authentication.

UWWI recommends using GSSAPI with Kerberos instead of DIGEST-MD5 authentication.

Which Method and Mechanism Should I Use?

UWWI supports AND recommends only two authentication methods/mechanisms:

Simple Authentication Method, using the Name/Password Authentication Mechanism of Simple Bind, having first initiated session-level encryption
SASL Authentication Method, using the GSSAPI Authentication Mechanism, employing Kerberos, NTLMv2, or NTLM

Which method/mechanism you choose, will likely be dependent on which method and mechanism is supported by your operating system and application. Since passwords are sensitive data, you should choose the strongest method and mechanism available. The strongest possible method and mechanism is SASL using Kerberos and employing session-level encryption.

From strongest to least, the possible combinations are:

SASL, using GSSAPI, employing Kerberos and session-level encryption
SASL, using GSSAPI, employing NTLMv2 and session-level encryption
SASL, using GSSAPI, employing Kerberos
SASL, using GSSAPI, employing NTLMv2
SASL, using GSSAPI, employing NTLM and session-level encryption
Simple Authentication, using name/password and employing session-level encryption.
SASL, using GSSAPI, employing NTLM

As noted above, Simple Authentication, using name/password without session-level encryption is prohibited by UWWI.

For configuration details, see 'How to Configure LDAP so your Application Works with UWWI'