A substring search against the aNR attribute is interpreted by the Domain Controller as a SUBSTR search against a set of attributes, known as the "ANR attribute set". The intent is that the attributes in the ANR attribute set are those attributes that are commonly used to identify an object, such as the displayName and name attributes, thereby permitting a client to query for an object when the client possesses some identifying material related to the object but does not know the attribute of the object that contains that identifying material. The ANR attribute set consists of those attributes whose searchFlags attribute contains the FANR flag
Our take on the ANR is that it is a convenience implementation of an Ambiguous Naming Resolution Algorithm implemented by Microsoft Active Directory.
Ambiguous Name Resolution (ANR) is an efficient search algorithm associated with Lightweight Directory Access Protocol (LDAP) clients that allows for objects to be bound without complex search filters.
Ambiguous Name Resolution is useful when you are locating objects and attributes that may or may not be known by the client. A common use for ANR, for example, is in a situation in which a building name is known by the requesting client, but not the associated number. In this case, the physicalDeliveryOfficeName attribute may have a value of "Building 40" and a client might search for "Building."
Ambiguous Name Resolution returns a match in this instance. It also returns other matches containing the word "Building." [1]
LDAP clients can use Ambiguous Name Resolution to make searching and querying easier. Rather than presenting complex filters, a search can be presented for partial matches. If a space is embedded in the search string, as in the case above, the search is divided at the space and an "or" search is also performed on the attributes. If there is more than one space, the search divides only at the first space.
The search results are returned to the client with matches for John Doe:
Note that the Name attribute above is the Relative Distinguished Name of the LDAP Entry. For user objects by default, this is the CommonName, the value of the cn attribute. As an example, suppose you want to find information on someone named "Smith". You can use the filter:
(anr=Smith)Will return objects where the string "smith" appears at the start of any of the naming attributes listed above. As always, the search is Case-insensitive. The Microsoft Active Directory Domain Controller will convert the filter to the following (in Windows Server 2000):
(|(displayName=Smith*)(givenName=Smith*)(legacyExchangeDN=Smith*)(physicalDeliveryOfficeName=Smith*)(proxyAddresses=Smith*)(Name=Smith*)(sAMAccountName=Smith*)(sn=Smith*))
AFAIK, All attributes that have the 0x00000004 bit set on the searchFlags attribute which is contained in the attributeSchema objectClass are included in the ANR query evaluations. However, we have not been able to verify this and would appreciate anyone with further knowledge to advise.
In addition to being a mold for objects the Schema also controls three very important options for each and every attribute:
To have Ambiguous Name Resolution search an additional attribute use the following steps:
Each name form is tried in turn.
If the name field of the Bind Request 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 Bind Request maps to more than one object, the Bind Request fails with the error invalidCredentials / LDAP_NO_SUCH_ATTRIBUTE. If the name field of the Bind Request maps to no object, the next object name form is tried.
If all forms have been tried, the Bind Request fails with the error invalidCredentials / LDAP_NO_SUCH_ATTRIBUTE.
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.
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.
As an example:
{ca2e693f-6280-4589-9376-b3707345d3ad}
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.
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). The canonical name of the object in which the rightmost forward slash (/) is replaced with a newline character (\n).
- based on 2008-09-10
- based on 2016-12-09
- based on information obtained 2018-09-22-
- based on information obtained 2018-10-03-