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.

Overview of Part 3

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 this post, we dive even deeper into the bind path as we look closely at the server name syntax and serverless binding.

Server Names vs. Serverless Binding in Active Directory Bind Paths

When creating an AD bind path, you can specify an optional server name as part of your bind path or you can use a technique called serverless binding to select any available domain controller in the local site. In general, you should use serverless binding but there are scenarios where you need to specify a server name and we examine those scenarios before moving on to serverless binding.

Server Names

You can use a number of formats for an AD bind path, including DNS-style names, NetBIOS names and IP addresses. In addition to these names, you can specify a connection port if necessary.

DNS-style names allow you to connect using any of the following formats.

• Fully-qualified domain name (FQDN) of a domain controller or global catalog server
• FQDN of a domain or forest
• Unqualified name (short form without full DNS name) of a domain or forest

You can also use the NetBIOS name of a domain, domain controller or global catalog server to connect, depending on your network configuration. Finally, the IP address allows you to bind to a specific server as well.

Server Port Numbers

If you use the default LDAP and GC providers on ports 389 and 3268 (or 636 and 3269 for SSL) then you do not need to specify a port number with either provider. If you need to connect to a non-standard port, then you can add the port number to the server name after a colon as in the following example.

LDAP://mydomain.local:12345

Most times you do not need to specify a port number, though.

Serverless Binding in Active Directory

Active Directory supports a technique called serverless binding that allows you to connect to any available domain controller in the local AD site. This best practices technique allows you to provide better fault tolerance by connecting to a range of servers while reducing the load on a particular server.

To use a serverless bind, simply do not specify a server in your bind path. Yep, it’s that easy! You can still put in the provider and object name but leave the server portion blank as in the following example.

LDAP://CN=Users,DC=mydomain,DC=local

Under the covers, a serverless bind uses the domain of the current security context running the application and then uses the Windows Locator service and DNS to look up available domain controllers in the site. As long as you are running the application under a domain account, the serverless bind technique works well. You can incur a COM exception of 0x8007203A, though, if you run under a local machine account since machine accounts are not members of a domain.

Server Name Best Practices

So when it’s all said and done, you should use one of the following techniques for the most fault tolerant, robust and scalable applications that connect to AD.

1. Use serverless binding if running under a domain account and connecting to AD in the same site as the domain account.
2. Specify a DNS name for the domain or forest—but not a specific domain controller or global catalog server—if connecting to a different domain or forest or if the application runs under a local machine account.

Overview of Part 2

In Part 1 of this series, we examined the basics of Active Directory bind paths. We look more deeply into the components of a bind path in this post, including how to set the provider, server and object name for a bind path.

Bind Path Review

As we discussed in Part 1, bind paths use the ADsPath syntax to connect to objects in Active Directory. AD binds paths can include up to three parts.

1. Provider: Specifies the ADSI provider to use to connect to a directory
2. Server: AD server to use for a connection
3. Object name: Directory object to reference

A bind path looks much like a URI instance.

<provider>://<server>/<object name>

Setting a Provider for a Bind Path

The bind path provider specifies the ADSI provider used to service an Active Directory bind request. When connecting to AD through ADSI, you have several options for providers but most often will use the LDAP provider. You can also use the Global Catalog provider, GC, to connect to a global catalog server and bind to objects across an entire forest. Both the LDAP and GC providers instruct ADSI to use the LDAP protocol to connect to AD using ports 369 and 3268, respectively, and you do not have to set these ports in your bind path.

You can bind to a number of other providers through ADSI. Additional providers include WinNT (to communicate with Windows NT 4.0 domain controllers), NDS (to communicate with Novell Directory Services servers), NWCOMPAT (to access Novell NetWare servers) and ADs (to enumerate all of the ADSI providers installed on a client).

Make sure you specify the provider with the proper upper- and lower-casing because ADSI providers are case sensitive. In the case of the LDAP and GC providers, each must be specified with capital letters. We see many instances where someone puts together a well-formed, valid bind path only to find it does not work because the provider casing is not correct. Many times you receive a COM error of “0×80005000 Unknown error” when binding with a provider that has incorrect casing.

Specifying Servers and Host Names

As part of a bind path, you can specify an optional server to tell ADSI exactly which server to use for a bind request to Active Directory. Many times, bind paths do not require a server and we will discuss the concept of serverless binding in a later post in the series.

If you do want to connect to a specific server, perhaps a server in a different domain or forest, you can specify the server name and optional port number in the following form.

LDAP://myservername:4500

You have a ton of options when setting the server name in the bind path, including using DNS-style names, NetBIOS names and IP addresses. In general, it is best practice to use serverless binding without a server name or to use the fully-qualified domain name (FQDN) to bind. You can specify server names for domains, specific domain controllers, forests and specific global catalog servers. We recommend that you specify domains and forests in the server portion of your bind string as this approach uses DNS to locate domain controllers and global catalog servers and provides much better fault tolerance than binding to an individual server.

Binding to the Object of Your Desire

Finally, you can specify an optional object to which to bind when you create a bind path. ADSI supports a number of options in how you specify an object, including using distinguished names, GUIDs and SIDs. We focus on the distinguished name syntax for this article and will look more deeply into other options in later posts in the series.

The distinguished name, or DN, for an object specifies the unambiguous path to the object in the directory. DNs act like a type of primary key and provide a great way to get a hook to anything in AD, including individual objects like user accounts and groups as well as containers like OUs. LDAP uses DNs extensively and you can refer to this great article from IBM for in-depth information about DNs and DN syntax.

I’m including a few examples below to show different object bind paths using different DNs. The first example binds to a user account called Jiminy Christmas that resides in the Some Users organizational unit (OU) in Active Directory. Note how the DNS namespace is added to the DN using the DC (domain component) of DC=mydomain,DC=local.

The second example is similar to the first but binds to the Some Users OU itself instead of an individual user account in that OU.

Finally, the last example specifies a server for another forest with a Global Catalog (GC) provider and binds to the Test Object in that forest.

LDAP://CN=Jiminy Christmas,OU=Some Users,DC=mydomain,DC=local
LDAP://mydomain.local/OU=Some Users,DC=mydomain,DC=local
GC://someotherforest.local/CN=Test Object,CN=Users,DC=someotherforest,DC=local