Load-Balance AD LDS with Microsoft NLB in 6 Steps

Active Directory Lightweight Directory Services (AD LDS) has made it easy for organizations to implement application-specific directories without incurring additional risk to their corporate AD forest. As AD LDS has grown in popularity, the demand to scale its implementations and ensure higher levels of availability has also grown. LDS is based on the same code as AD, so it has the same replication engine and performance characteristics, but the same high-availability rules don’t apply to LDS.

In AD, load balancing automatically occurs in the back end, thanks to the separate processes for discovering and connecting to domain controllers (DCs). But LDS is simply an LDAP directory and therefore has no inherent ability to load-balance itself, despite its rich replication capabilities. So, instead of letting your LDS implementation be a failure waiting to happen, you can use Microsoft's Network Load Balancing (NLB) service to give your directory service some much needed load balancing. In this article, I’m going to lay out six steps that you can take to start load-balancing your LDS servers in no time. But first, you need to be aware of the basics of NLB.

Network Load Balancing 101
Windows Server's built-in NLB offers a basic clustering service for TCP/IP-based network services—without the burden of shared resources. NLB doesn't ensure data consistency across hosts in the cluster. If there's dynamic data, that data must be kept in sync by other means. Therefore, NLB is typically used by static content providers, such as a web server farm that connects to a back-end database. You can use NLB with dynamic-content providers, but NLB leaves it up to the server to ensure that the data is in sync across hosts. This type of setup lends itself well to LDS because LDS accomplishes this data synchronization with its native replication capabilities.

With NLB, you define a “virtual” name and IP address. The address is shared by each host in the NLB cluster. Load balancing is based on ports. So, you can have multiple services load-balanced with different options on the same hosts. You can also set the weight and priority on hosts in the cluster to ensure that better-performing hardware is used more frequently. When a client connects to a set of LDS servers that is clustered with NLB, it uses the virtual name or IP address. The NLB service, which runs on every node of the cluster, will determine which server in the farm responds. Figure 1 illustrates the NLB principles at a high level.

Step 1: Plan Your NLB Configuration
Before you start installing NLB, you need to make a few decisions about how NLB will run in your LDS server farm. Making these decisions early will help ensure that you run into fewer problems when you begin deploying NLB. If you already have LDS running and you just want to add additional load-balanced servers, the planning will reduce the risk of taking the LDS service offline while you’re installing NLB.

First, you’ll want to determine the configuration of the cluster network. You’ll need to obtain an IP address for the cluster; each cluster host will be listening on this address. Also, you’ll need to decide on a cluster host name that the clients will use to access the directory service. Although it might sound trivial, deciding on a host name is an essential step, particularly if you plan to use SSL. When you obtain a server certificate for your LDS hosts, the certificate will need to contain the shared cluster host name instead of the individual server host name. If you don’t do this, you'll have a name mismatch in your certificate, so you’ll need to decide on the cluster host name before you can request your server authentication certificate.

Second, you’ll need to decide on the cluster operation mode. You have two choices: unicast or multicast. When you use NLB, each host in the cluster will accept traffic that’s destined for the cluster's IP address and the host name that you decided on earlier. It does this because NLB assigns a unique MAC address for the cluster. Each host in the cluster listens for traffic destined to this MAC address. Using a filtering algorithm built into NLB, the host will either process the packet or drop it. Because every host in the cluster is using the same filtering algorithm, the packet is processed by only one host. When you choose a cluster operation mode, you're deciding on how each host listens for packets destined to the cluster MAC address. If you use unicast mode, the system replaces the MAC address of the network card on the host with the cluster's MAC address. Therefore, each LDS host in the cluster will have the same MAC address. The host will still service clients, but the LDS hosts won't be able to communicate with one another unless you have a second network card. Without this second network card, LDS replication won't work. However, when you use multicast mode, the network card retains its original MAC address and an additional multicast MAC address is added. In this configuration, hosts in the cluster can communicate with one another without the need for an additional network card. In most cases, the safest choice is to use multicast mode, but you need to ensure that the switch can map a unicast IP address to a multicast MAC address.

Third, you need to determine how many network cards you’ll use in each host. You have a couple considerations coinciding with this decision: If you've chosen to operate in unicast mode, you'll need an additional network card to ensure that the LDS hosts can communicate with each other; also, an additional network card can add performance enhancements. One card would be dedicated to the cluster host, and the other card would be used for other networking traffic, such as backups and replication.

Fourth, you’ll need to think about client affinity. Before your clients can query your LDS directory, they must first bind to it to establish a connection and present credentials. With multiple load-balanced LDS servers, there's a chance that when your client uses that cluster host name, they could bind to one server and then a subsequent LDS query could connect to an entirely different server in the cluster. The problem is that the client would be authenticated to only the server that it bound with and not the server that it queried. When client affinity is enabled, you have assurance that the client will use the same host in the cluster all the time. There are three affinity options available: None, Single, and Network.

Choosing None doesn’t necessarily mean that every network operation will go to a different server in the cluster. The way affinity is calculated when None is selected is based on the IP address of the client and the source port that the client uses. So, when you use a tool such as LDP (ldp.exe) to test affinity, the source port that it uses doesn’t change until you disconnect from the directory and reconnect. The same LDS host is used within the LDAP session, but this isn’t the case with every LDAP client. When you use Single affinity, the algorithm will use only the IP address of the client to determine which LDS host to connect to. This ensures that the same client will always use the same server as long as it has the same IP address. When you use Network affinity, the system uses neither the client IP address nor the source port. Instead, every client coming from the same subnet will use the same LDS host. You can use this method to establish a form of geographic load balancing in your cluster.

Step 2: Get LDS Up and Running
The next step in deploying your LDS farm is to get LDS working without NLB. Install and configure your network cards and get LDS installed and running properly, but don’t install the server certificates yet. You’ll want to stand up at least one replicated instance. (For a good setup and configuration guide, see the Microsoft article "AD LDS Getting Started Step-by-Step Guide" at technet.microsoft.com/en-us/library/cc770639.aspx.) Use a tool such as LDP or ADSIEdit (adsiedit.msc) from a client to make sure you can connect to each of the LDS servers independently and that the replicated data is the same on both servers.

Step 3: Install NLB on All Nodes
You’re now ready to install NLB on each of the LDS servers that hold a replica of the directory instance. There are two ways to install the NLB service in Windows Server 2008: through the GUI or from a command prompt. To install NLB using the GUI, you’ll use the Server Manager tool. You can select the Features item in the console tree, then select Add Features in the main panel. In the Add Features Wizard, select the Network Load Balancing check box and click Install, as you see in Figure 2. Remember, you'll need to install NLB on every LDS server that will participate in the cluster.



You can also use the command prompt to install NLB on your LDS hosts. To do so, you can use the command

servermanagercmd -install nlb

Step 4: Create the NLB Cluster
Now that NLB is installed on your hosts, you can use one of the hosts to create the cluster. Launch the Network Load Balancing Manager tool (which Figure 3 shows) from the Administrative Tools menu, or run the Nlbmgr command.



The NLB Manager consists of three parts. In the left panel, you'll see a list of all the NLB clusters that you're connected to. The right panel contains the details of the cluster or host that you've selected. And at the bottom of the dialog box, a log shows you the recent operations the tool has performed.

Start the New Cluster wizard by selecting New from the Cluster menu. The next few dialog boxes will take you through the process of creating the NLB cluster. You'll start off by connecting to the first LDS server that you're adding to the cluster.



The Host Parameters dialog box, which Figure 4 shows, defines some settings that are specific to the host you're installing. The Priority field lets you give each host a unique ID; the host with the lowest priority number is the one that handles all the packets that don’t have a port rule defined. (I'll discuss port rules shortly.) If you have multiple network cards, you'll want to ensure that the IP address specified in this dialog box isn't the IP address that the cluster is using. If you have a single network card, you'll see the IP addresses of that card here marked as dedicated IP addresses.



In the Cluster IP Addresses and Cluster Parameters dialog boxes (which Figure 5 shows), you'll add the IP address and host name that you decided on in Step 1. This is also where you'll choose the cluster operation mode. When you select multicast, you'll notice that the MAC address changes from a unicast MAC address to a multicast MAC. In Figure 5, the MAC address changed from 02-bf-0a-00-00-92 to 03-bf-0a-00-00-92.



Finally, you'll need to define the port rules for the clustered directory service. Port rules tell the NLB cluster which ports to listen on. By default, the wizard defines all ports as clustered, but you can hone this down to only the TCP client access ports for LDAP (as you see in Figure 6). You would need to create separate TCP port rules for each LDAP port. By default, LDS uses port 389 for unencrypted LDAP and port 636 for SSL-secured LDAP, unless there's already a directory service using those ports. In that case, you would have defined different ports to use when you installed the directory instance. Because the port rules affect only communications over the cluster MAC, leaving all ports clustered doesn't adversely affect LDS replication or server-to-server communications. But keep in mind that any ports that aren't covered in a port rule are handled by the host with the lowest priority number.

Step 5: Install the SSL Certificate
Getting SSL running in a replicated LDS instance is a little tricky when you're using NLB. There are three factors to keep in mind when installing the certificates. First, as I stated earlier, you must use the host name of the cluster in the server authentication certificate—not the host name of the server. If you plan to use the host name to connect to individual hosts, you can use a Subject Alternative Name (SAN) for the host or use a wildcard certificate. Second, the certificate must be installed in the personal certificate store of the account that the LDS service is running under. It’s important to ensure that the personal certificate store for that account on each LDS server contains only the server authentication certificate and nothing else. To add the certificate to the correct certificate store, you can use the following approach:

Finally, you need to give the LDS service account read permissions to the certificate in the store. For example, if you were using the Network Service account for LDS in Windows Server 2008, you would give the Network Service Account read permissions (Figure 7) to the folder %PROGRAMDATA%MicrosoftCryptoRSAMachineKeys.

Step 6: Add Hosts to the Cluster
After you install the NLB cluster with one host, you should be able to freely access the directory service using the cluster host name and IP address. The only thing left is to add the remainder of the LDS servers into the NLB cluster. If you're using SSL, don’t forget to import the certificate into the correct store and set the folder permissions on each host that you add to the cluster.

Strength and Resiliency
You should now have a running NLB cluster. You can use the LDAP client tools to test connectivity to your directory service, but be sure to use the cluster host name and IP address. By adding NLB clustering to your replicated LDS instance, you have strengthened your LDS implementation and have added an additional layer of resiliency to an already great directory service.