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 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.