Ambiguous Name Resolution (ANR)#

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.

There are two modes of using Ambiguous Name Resolution:#

Standard Ambiguous Name Resolution#

The user enters a partial string that is matched both exactly and partially against specific attributes in the directory (according to the lists provided earlier for the different versions of Exchange). The results can be either exact or a list of possible matches.

Specific Match Ambiguous Name Resolution#

When the client needs the string he is searching for to be exactly matched he or she can submit the string preceded by the equal sign ('=Jason').

Sample Ambiguous Name Resolution Search Using the Address Book#

Assume that there are three users named John Doe, John Does, and John Buck, and a search for "John Doe" is performed. The following actions result:
  • The client presents an "anr=John Doe" request to Active Directory (Address Book generates an ANR search). ANR must be enabled on the LDAP server. Active Directory supports ANR by default. ANR is a filter rewrite on the server.
  • Active Directory notices the "anr" and the embedded space.
  • Active Directory checks the schema to determine which objects have ANR and SEARCH index bits set.
  • Active Directory performs an "or" search for "John Doe*" against the default attributes listed above.
  • Active Directory then searches for: Given-Name=John* AND Surname=Doe*
  • Active Directory then searches for: Given-Name=Doe* AND Surname=John*

The search results are returned to the client with matches for John Doe:

  • Compared to: John Doe
    • Search Results: Match
    • Results Explanation: "John Doe*" matches displayName from step 4
  • Compared to: John Does
    • Search Results: Match
    • Results Explanation: "John*" AND "Doe*" matches Given-Name=John* AND Surname=Smith* from step 5
  • Compared to: John Buck
    • Search Results: No match
    • Results Explanation: "John Doe*" does not match the displayName
    • "John*" AND "Doe*" does not match the Given-Name and Surname of John Buck
    • "John*" AND "Doe*" does not match the Surname and Given-Name of John Buck

Attributes are Used for Ambiguous Name Resolution#

You can determine the items which are being used for the Ambiguous Name Resolution function by performing some LDAP searches. First you must determine the where the schema configuration is located. This can be done by performing a LDAP query from the baseDN= like:
(cn=schema)

The value returned should then be used as the root for the search. The filter below:

(&(objectCategory=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=4))
Returns (on our AD 2003 instance)
CN=Display-Name, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com
CN=Given-Name, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com
CN=Legacy-Exchange-DN, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com
CN=ms-DS-Additional-Sam-Account-Name, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com
CN=Physical-Delivery-Office-Name, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com
CN=Proxy-Addresses, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com
CN=RDN, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com
CN=SAM-Account-Name, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com
CN=Surname, CN=Schema,CN=Configuration,DC=mad,DC=willeke,DC=com

NOTE: AD returns the "AD name" for the schema entries not the LDAP name. So cn=Display-Name will show as displayName in a LDAP search outside the schema configuration.

By default, the following attributes are set for ANR which varies by version as shown below.

Windows 2000 Server#

  • Display-Name
  • Given-Name
  • Legacy-Exchange-DN
  • Physical-Delivery-Office-Name
  • Proxy-Addresses
  • RDN
  • SAM-Account-Name
  • Surname

Windows Server 2003#

  • Display-Name
  • Given-Name
  • Legacy-Exchange-DN
  • ms-DS-Additional-Sam-Account-Name
  • Physical-Delivery-Office-Name
  • Proxy-Addresses
  • RDN
  • SAM-Account-Name
  • Surname

Active Directory Application Mode (ADAM)#

  • Display-Name
  • Physical-Delivery-Office-Name
  • Proxy-Addresses
  • RDN

Windows Server 2003 R2#

  • Display-Name
  • Given-Name
  • Legacy-Exchange-DN
  • ms-DS-Additional-Sam-Account-Name
  • Physical-Delivery-Office-Name
  • Proxy-Addresses
  • RDN
  • SAM-Account-Name
  • Surname

Windows Server 2008#

  • Display-Name
  • Given-Name
  • Legacy-Exchange-DN
  • ms-DS-Additional-Sam-Account-Name
  • ms-DS-Phonetic-Company-Name
  • ms-DS-Phonetic-Department
  • ms-DS-Phonetic-Display-Name
  • ms-DS-Phonetic-First-Name
  • ms-DS-Phonetic-Last-Name
  • Physical-Delivery-Office-Name
  • Proxy-Addresses
  • RDN
  • SAM-Account-Name
  • Surname

Adding additional attributes to be used by Ambiguous Name Resolution#

ANR is a feature specific to the directory service AD. To add additional attributes to be used by ANR the Active Directory has to be changed.

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:

  • Indexing – If checked the attribute will be indexed
  • Ambiguous Name Resolution – If checked the attribute will be used by ANR
  • Replication of the attribute to a Global Catalog – If checked the attribute will be replicated to all Global Catalogs in the forest.

To have Ambiguous Name Resolution search an additional attribute use the following steps:

  • Log on to the Domain Controller that serves as the Schema Master of the forest.
  • Either install the full suite of administration tools (ADMINPAK.MSI) or register the Schmmgmt.dll file.
  • Open Start>Run>MMC
  • Open the 'Console' menu and choose 'Add/Remove Snap-in'.
  • Click 'Add' and choose the 'Active Directory Schema'.
  • Click 'Add'.
  • Click 'Close'.
  • Expand the 'Active Directory Schema'.
  • Choose the 'Attributes' branch.
  • Open the properties for the attribute that you want ANR to use.
  • Check the following boxes
    • Index this attribute in the Active Directory
    • Replicate this attribute to the Global Catalog
    • Ambiguous Name Resolution (ANR)
  • Click on 'OK'.
  • Close the management tools.

Microsoft Active Directory and Bind Request #

When performing a simple bind, Microsoft Active Directory accepts several forms of name in the name field of the Bind Request.

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.

The name forms are:#

The DN of the object.

User Principal Name (UPN)#

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.

NetBIOS domain name#

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

ObjectGUID[2]#

The value of the ObjectGUID attribute of the object, expressed in dashed-string form (RFC 4122 section 3) and surrounded by curly braces may be used to perform a Bind Request.

As an example:

{ca2e693f-6280-4589-9376-b3707345d3ad}
Even though this is NOT mentioned in Ambiguous Name Resolution documents.

displayName#

The value of the displayName attribute of the object.

servicePrincipalName#

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

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.

objectSID#

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

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).

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-23) was last changed on 10-Dec-2016 10:38 by jim