Binding to Active Directory: AD Connections De-mystified, Part 5

Note: This series covers Active Directory connection strings, often referred to as bind paths, with the goal of simplifying the process of creating an AD bind path. A significant amount of the information for this series comes from the wonderful AD programming book, The .NET Developer’s Guide to Directory Services Programming, by Ryan Dunn and Joe Kaplan. The LDAP ADsPath article on MSDN also provides good insight into creating valid bind paths for Active Directory.

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>