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 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 “0x80005000 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