Web Active Directory Blog

Overview of Part 5

In Part 1 of this series, we examined the basics of Active Directory bind paths. In Part 2, we looked more deeply into the components of a bind path. In Part 3, we took apart the server name syntax and checked out serverless binding. In Part 4, we examined using distinguished names to connect to objects in Active Directory. In this final post of the series, we look at binding to Active Directory objects using GUIDs and SIDs.

Using GUIDs in Object Names

You can specify object names in Active Directory using a special GUID syntax in the following form. One very nice feature of binding using GUIDs is that the GUID stays the same for an object even when the object is renamed or moved across domains.

<GUID=guidvalue>

You must keep the angle brackets and GUID keyword to tell AD that you are binding using the GUID object name syntax. This refers to the objectGUID attribute for an object. The key here is to use correct form of the GUID since there are a couple of forms of GUIDs available based on legacy x86 details. If the GUID contains dashes, use the COM string format. Otherwise, use the binary octet string format.

An example of a GUID bind path follows.

LDAP://<GUID=ec2b2b8f-dcd5-41c3-aa9e-2e9d26e46a10>

You can also use GUIDs to access well-known objects in AD like the Users and Computers containers. Use the following form to define a well-known GUID bind path.

<WKGUID=Guid,Domain Partition DN>

In this format, the Guid is the GUID identifier (GUID_USERS_CONTAINER_W or GUID_COMPUTERS_CONTAINER_W, for example) and the Domain Partition DN is the DN of the root domain, for example DC=mydomain,DC=local. You may choose well-known GUIDs from the list below to access different well-known containers in Active Directory.

• GUID_USERS_CONTAINER_W: Users container
• GUID_COMPUTERS_CONTAINER_W: Computers container
• GUID_SYSTEMS_CONTAINER_W: Systems container
• GUID_DOMAIN_CONTROLLERS_CONTAINER_W: Domain Controllers container
• GUID_INFRASTRUCTURE_CONTAINER_W: Infrastructure container
• GUID_DELETED_OBJECTS_CONTAINER_W:  Deleted Objects container
• GUID_LOST_AND_fOUND_CONTAINER_W:  Lost and Foundcontainer

Check out the example of a well-known GUID bind path that connects to the Users container in the mydomain.local domain.

LDAP://<WKGUID=GUID_USERS_CONTAINER_W,DC=mydomain,DC=com>

Using SIDs in Object Names

Finally, AD allows you to bind to an object name by an object’s SID. Not all objects in AD have SIDs so make sure you only try to bind by SID to objects that are security principals, including user accounts, groups and computers. Also be aware that SIDs can change as objects move across domains but you can always look up previous SIDs after changes using the sidHistory attribute.

Use the following syntax to bind to an object by its SID.

<SID=sidvalue>

Here, the sidvalue can support either a hexadecimal octet string or the Security Descriptor Description Language (SDDL) format that looks like S-1-5-xxxx. Be careful to use the SDDL format with Windows Server 2003 AD and later since Windows 2000 only supports the octet string syntax. Also remember that since SIDs can change from domain to domain, you cannot use a global catalog (GC) bind to a global catalog server or you will get an error.

The follow example shows a SID bind using the SDDL format.

LDAP://<SID=S-1-5-21-1720926295-173614409-390823645-1127>

Overview of Part 4

In Part 1 of this series, we examined the basics of Active Directory bind paths. In Part 2, we looked more deeply into the components of a bind path. In Part 3, we took apart the server name syntax and checked out serverless binding. In this article, we examine using distinguished names to connect to objects in Active Directory.

What is a Distinguished Name?

Active Directory uses a distinguished names (DN) as a path to uniquely identify an object in the directory. You can use a DN to hook to OU containers, user accounts, groups, schema objects and anything else stored in AD. Since AD is an LDAP directory, it stores objects in a hierarchical tree like a filesystem and you can use DNs as a sort of path syntax to hook into an object.

DN Path Syntax

DNs use a syntax similar to a filesystem path as each piece of the DN is more specific to where the object resides in the directory. Look at the following example of a DN.

CN=Test User,OU=UserContainer,DC=mydomain,DC=local

In this example, we have four components of the path, each separated by a comma. You read the DN from left to right where the leftmost component is the most specific node in the directory tree and specifies the object identified by the DN. In this case, that object is a user account with the common name (CN) of Test User.

Working to the right, we see that the Test User account is in an organizational unit (OU) called UserContainer. This container is a child of the root of the namespace, mydomain.local.

Finally, the namespace root of mydomain.local is specified by the last two components, DC=mydomain,DC=local. Technically, both the domain component (DC) values here are actually part of the same component as the combination of the two specifies the root of the namespace. In general, just remember that when you use the DNS name of a domain or forest in a DN, you need to add a “DC=” for each part of the DNS name when creating the DN.

Special DN Characters

DNs are very powerful for addressing objects in AD but sometimes you have to be careful if a directory has containers or objects that contain special characters. The following characters are reserved in AD and cannot be included in a DN unless they are escaped with the \ character.

<,;+\/">

You also must escape the # character if it is the first character in a DN. When using any special reserved characters in a DN, you must escape them using the \ character. Note that spaces in a name do not need to be escaped.