5.1.1.2 Using SSL/TLS

Active Directory permits two means of establishing an SSL/TLS-protected connection to a DC. The first is by connecting to a DC on a protected LDAPS port (TCP ports 636 and 3269 in AD DS, and a configuration-specific port in AD LDS). The second is by connecting to a DC on a regular LDAP port (TCP ports 389 or 3268 in AD DS, and a configuration-specific port in AD LDS), and later sending an LDAP_SERVER_START_TLS_OID extended operation [RFC2830]. In both cases, the DC will request (but not require) the client's certificate as part of the SSL/TLS handshake [RFC2246]. If the client presents a valid certificate to the DC at that time, it can be used by the DC to authenticate (bind) the connection as the credentials represented by the certificate.

If the client establishes the SSL/TLS-protected connection by means of connecting on a protected LDAPS port, then the connection is considered to be immediately authenticated (bound) as the credentials represented by the client certificate. An EXTERNAL bind is not allowed, and the bind will be rejected with an error. If the client does not present a certificate during the SSL/TLS handshake, the connection is not authenticated and is treated as anonymous. In that case, the DC rejects any attempt to perform an EXTERNAL bind with the error invalidCredentials / <unrestricted>.

If the client establishes the SSL/TLS-protected connection by means of an LDAP_SERVER_START_TLS_OID operation, the authentication state of the connection remains the same after the operation as it was before the operation. The DC authenticates the connection as the credentials represented by the client's certificate only if an EXTERNAL SASL bind is subsequently performed. This is similar to the "implicit assertion" of [RFC2830] section 5.1.2.1, except that neither the authentication identity nor the authorization identity is established on the connection until the EXTERNAL bind takes place. If the client includes the authzId field in the EXTERNAL bind, in accord with the "explicit assertion" of [RFC2830] section 5.1.2.2, then as described in section 5.1.1.1.2 the authzId field contains the DN of the object that the EXTERNAL bind is authenticating the connection as; in other words, the object associated with the credentials represented by the certificate. Therefore, the implicit assertion and explicit assertion are functionally identical. If the client performs an EXTERNAL bind but does not supply a certificate during the SSL/TLS handshake, the EXTERNAL bind fails with the error invalidCredentials / <unrestricted>.

Alternatively, the client can perform any other form of LDAP bind that is permissible on an SSL/TLS-protected connection, or the client can perform no bind to continue to use any authentication and authorization identity that was previously established on the connection.