How to Use the UW Windows Infrastructure
for 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

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 RFC standard specifies 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.

UWWI allows this, but because UWWI has chosen to not store passwords in reversible encryption (i.e. the LM password hash does not exist), it does not work correctly. This is probably a good thing since using this mechanism without initiating any session-level encryption first is in violation of UW Computing standards. 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 great interest in AD environments unlike UWWI where passwords are stored in reversible encryption. 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.

To be clear, the fast bind option will not work with UWWI.

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 (UWWI does not support NTLM nor 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. 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.

A SASL EXTERNAL LDAP bind operation 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 external means to the appropriate user entry.

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.