5.1.1.1.1 Simple Authentication

  • Article

The support of simple bind in Active Directory is consistent with [RFC2251] section 4.2 and [RFC2829]. Active Directory does not require, but supports, the use of an SSL/TLS-encrypted or otherwise protected connection when performing a simple bind. Also, while section 6.2 of [RFC2829] specifies that an object possessing a userPassword attribute is a prerequisite to being able to perform a simple bind using that object's credentials, Active Directory does not use the userPassword attribute to store the user's password in most cases, and possession of such an attribute is not a prerequisite to performing a simple bind against an object. The password attributes used in Active Directory are discussed in more detail in "LDAP Password Modify Operations" in section 3.1.1.3.1.5. The simple bind uses the password policy settings described in the Group Policy: Security Protocol [MS-GPSB] section 2.2.1.2 and is applied using the policy described in [MS-GPSB] section 3.2.5.2.

When performing a simple bind, Active Directory accepts several forms of name in the name field of the BindRequest. Each name form is tried in turn. If the name field of the BindRequest maps to a single object using the attempted name form, the password on that object is checked, and the authentication succeeds or fails (with the error invalidCredentials / <unrestricted>) depending on the result. If the name field of the BindRequest maps to more than one object, the BindRequest fails with the error invalidCredentials / ERROR_INVALID_PARAMETER. If the name field of the BindRequest maps to no object, the next object name form is tried; if all forms have been tried, the BindRequest fails with the error invalidCredentials / ERROR_INVALID_PARAMETER.

For AD DS, the name forms are tried in the order they are listed below. For AD LDS, the name forms are tried in the order below, except that forms marked "Only for AD DS" are not tried, and the User Principal Name (UPN) mapping (the second form below) is tried last.

The name forms are:

  1. The DN of the object.

  2. The user principal name (UPN) of the object. The UPN of an object is either:

    • A value of the userPrincipalName attribute of the object, or

    • Only for AD DS: The value of the sAMAccountName attribute of the object, followed by a "@" sign, followed by either:

      • The DNS name of a domain in the same forest as the object, or

      • A value in the uPNSuffixes attribute of the Partitions container in the config NC replica.

        When a name matches both the userPrincipalName attribute of one object and the UPN generated from the sAMAccountName of another object, the simple bind processing attempts to authenticate as the first object (that is, priority is given to the value of the userPrincipalName attribute) rather than failing the bind due to duplicate objects.

  3. Only for AD DS: The NetBIOS domain name, followed by a backslash ("\"), followed by the value of the sAMAccountName attribute of the object.

  4. The canonical name of the object.

  5. The value of the objectGUID attribute of the object, expressed in dashed-string form ([RFC4122] section 3) and surrounded by curly braces (for example, "{ca2e693f-6280-4589-9376-b3707345d3ad}").

  6. The value of the displayName attribute of the object.

  7. Only for AD DS: A value of the servicePrincipalName attribute of the object.

  8. Only for AD DS: A value V that, when the MapSPN(V, M) algorithm of [MS-DRSR] section 4.1.4.2.19 is applied to it, corresponds to a value of the servicePrincipalName attribute of the object. M is the value of the sPNMappings attribute of the nTDSService object.

  9. The value of the objectSid attribute of the object, in SDDL SID string form ([MS-DTYP] section 2.4.2.1).

  10. Only for AD DS: A value from the sIDHistory attribute of the object, in SDDL SID string form ([MS-DTYP] section 2.4.2.1).

  11. The canonical name of the object in which the rightmost forward slash (/) is replaced with a newline character (\n).