jspωiki
Ambiguous Name Resolution

Ambiguous Name Resolution (ANR)#

Ambiguous Name Resolution (aNR) is a search algorithm in Microsoft Active Directory that permits a client to search multiple Naming Attributes on objects via a single clause in a search filter.

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.

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#

AttributeTypes are Used for Ambiguous Name Resolution are contained in the ANR attribute set

Ambiguous Name Resolution and SearchRequest#

Ambiguous Name Resolution is an efficient search algorithm in Microsoft Active Directory that allows you to specify complex LDAP SearchFilters involving multiple naming-related attributes in a single clause. Ambiguous Name Resolution can be used to locate objects in Microsoft Active Directory when you know something about the object, but not necessarily which naming-attribute has the information.

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

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: