LDAP Authentication (AD)

Authentication

Authentication is a mechanism that verifies the identity of a user (and not just a user, but also a computer or service). It should confirm that we are the person we claim to be. Usually, it involves knowing a username and password, but in a better case, a certificate or biometrics is used. Single-factor authentication is when we only need to know something, i.e., we enter a password. Two-factor (or multi-factor) authentication involves using a chip card (certificate) and a PIN, so we need to have something and know something.

LDAP Security Model

In LDAP v3 (RFC 2251), it is specified that SASL mechanism can be used for security services. SASL stands for Simple Authentication and Security Layer and was originally defined in RFC 2222 and later in RFC 4422. In the LDAP tree, in the root entry rootDSE, the supported SASL security methods of the directory are listed in the supportedSASLMechanisms attribute.

SASL

SASL is a method for adding authentication support to connection-based protocols. SASL separates the authentication mechanism from application protocols, so theoretically, an application that supports SASL can use any authentication mechanism. SASL negotiates which mechanism is best to use (and which can be used). Individual mechanisms are named with a string of up to 20 characters and use uppercase letters, numbers, and hyphens with underscores. SASL is often used in combination with TLS (Transport Layer Security).

Note: Individual mechanisms are defined in various RFCs.

SASL mechanisms supported by Active Directory:

• PLAIN - authentication with a simple password in plain text
• ANONYMOUS - unauthenticated access, no authentication information is sent
• NTLM - NT LAN Manager, used on standalone systems or for backward compatibility. It uses an encrypted password along with the domain and username. It is a Microsoft protocol, partially backward compatible with LANMAN and appeared with the SMB protocol. Today, NTLMv2 is used, and Kerberos is preferred, but NTLM is still used in some cases.
• DIGEST-MD5 - this mechanism allows authentication using a password, but only the hash of the password is sent over the network. It is similar to CRAM-MD5 but also ensures the integrity and confidentiality of the connection.
• GSSAPI - Generic Security Services Application Program Interface, RFC 2078, provides the ability to authenticate using a Kerberos v5 session, and also provides mechanisms for ensuring the integrity and confidentiality of the connection. It is not an authentication method but a mechanism that selects the most suitable method and passes the authentication information to this method (service). It provides general security services that can be supported by a number of subordinate mechanisms and services. It supports the use of SSO (single sign-on), so credentials are not filled in.

Note: Anonymous access, i.e., without entering a password, is disabled by default in AD.

Other SASL mechanisms include OTP (one-time password), SKEY, EXTERNAL, CRAM-MD5, SRP, GSS-SPNEGO, SECURID.

Active Directory also uses several proprietary authentication mechanisms:

• SSPI - Security Support Provider Interface - for backward compatibility, it is not recommended to use today, it was similar to GSS-API.
• DPA - Distributed Password Authentication - used in Microsoft Commercial Internet System, encrypted password.

Note: The LDAP security model does not include an access control mechanism, but AD uses ACL (access control lists) on directory objects.

Kerberos V5 (Kerberos Network Authentication Service (V5)) is described in RFC 1510. It is the most commonly used method for Active Directory. It defines an authentication process that provides methods for verifying identity, for example, for a workstation or user. For authentication, clients use Kerberos tickets, which represent network credentials for the client. The client obtains a ticket from the KDC (Kerberos Key Distribution Center) and presents this ticket when establishing a network connection. Kerberos represents the client's identity using the domain name, username, and password.

LDAP bind

To work with directory data, we must first authenticate (verify against the directory). This verification is done using the LDAP bind operation. If we only want to authenticate the client against the directory (e.g., Active Directory) for the purposes of another application (and not for accessing the directory), the bind operation is commonly used, and after its use, we immediately disconnect (unbind). Another option is to use a RADIUS (Remote Authentication Dial In User Service) server.

Note: I remind you that if only the username and an empty password are entered, AD assumes it is anonymous access and returns that the verification was successful.

For bind authentication operations, we have two main options:

• Simple bind - uses simple authentication, for authentication, the user's DN name and password in plain text are used.
• SASL bind - SASL can use a number of types of SASL mechanisms and the corresponding credentials, such as the Kerberos protocol or client certificate using TLS.

If we use Simple bind, the password can be intercepted, so it should always be used in conjunction with an encrypted channel using SSL or TLS.

References

• Directory Server Standards and Specifications - text of some RFCs
• Logon and Authentication Technologies - authentication methods in Windows