Active Directory Lightweight Directory Services : Configuring and Using AD LDS (part 1) - Working with AD LDS Tools, Creating AD LDS Instances

A data drive created for your server. Because this server will be hosting directory stores, place these stores on a drive that is separate from the operating system.

The name you will use to create the instance. Use meaningful names, such as the name of the application that will be tied to an instance, to identify instances. This name is used to identify the instance on the local computer as well as to name the files that make up the instance and the service that supports it.

The ports you intend to use to communicate with the instance. Both AD LDS and AD DS use the same ports for communication. These ports are the default LDAP (389) and LDAP over the Secure Sockets Layer (SSL), or Secure LDAP (636), ports. AD DS uses two additional ports, 3268, which uses LDAP to access the global catalog, and 3269, which uses Secure LDAP to access the global catalog. Because AD DS and AD LDS use the same ports, this is another good reason for not running both roles on the same server. However, when the wizard detects that ports 389 and 636 are already in use, it proposes 50,000 and 50,001 for each port and then uses other ports in the 50,000 range for additional instances.

The Active Directory application partition name that you intend to use for the instance. You must use a distinguished name (DN) to create the partition. For example, you could use CN=AppPartition1,DC=Contoso,DC=com. Depending on how you intend to use the instance, you might or might not need the application partition. Application partitions control the replication scope for a directory store. For example, when you integrate DNS data within the directory, AD DS creates an application partition to make DNS data available to appropriate DCs. Application partitions for AD LDS can be created in one of three ways: when you create the instance, when you install the application that will be tied to the instance, or when you create the partition manually through the LDP.exe tool. If your application will not create application partitions automatically, create them with the wizard.

A service account to run the instance. You can use the Network Service account, but if you intend to run multiple instances, it might be best to use named service accounts for each instance. If you choose not to use a managed service account and decide to set up your service accounts manually, remember to follow the service accounts guidelines and requirements as listed here. Create a domain account if you are in a domain; otherwise, use a local account (for example, in a perimeter network).

Assign the Generate Security Audits user right in the Local Security Policy of each computer that will host this instance to support account auditing.

A group that will contain the user accounts that will administer the instance. The best practice for permission assignments is always to use groups even if only one account is a member of the group. If personnel changes, you can always add or change group members without having to add or change permissions. Create a domain group if you are in a domain; otherwise, create a local group. Name the group the same as the instance. This way, it will be easy to track the group’s purpose. Add your own account to the group as well as to the service account you created earlier.

Any additional LDIF files you need for the instance. Place these files in the %SystemRoot%\ADAM folder. These files are imported during the creation of the instance. Importing LDIF files extends the schema of the instance you are creating to support additional operations. For example, to synchronize AD DS with AD LDS, you would import the MS-AdamSyncMetadata.ldf file. If your application requires custom schema modifications, create the LDIF file ahead of time and import it as you create the instance. Note that you can always import LDIF files after the instance is created. Default LDIF files are listed in Table 2.