Windows Server 2008 : Keeping a Distributed Environment in Sync

When Microsoft originally developed Active Directory in Windows 2000 Server, it was designed to be the only directory an organization would ever need. The idea was that all services would be centralized within an organization’s Active Directory environment, and applications would use it as their own directory.

As information technology developed, the exact opposite effect happened; a proliferation of directories within organizations occurred. Not only were multiple directories created within applications, but many organizations deployed multiple Active Directory forests for security reasons.

As Active Directory matured, Microsoft saw a need to tie these directories together into a single, federated metadirectory. In addition, they also saw an opportunity to supply applications with their own directories that were based on the AD model.

This article covers these technologies, covering how multiple AD DS forests can be unified into a single federated forest, and how that structure can be synchronized with other foreign directory platforms. Microsoft’s Forefront Identity Manager, which provides for these capabilities, is covered in detail. In addition, Active Directory Lightweight Directory Services (AD LDS) and Active Directory Federation Services (AD FS) is explained.

Active Directory Lightweight Directory Services

A feature of the Active Directory technologies in Windows Server 2008 R2 is the Active Directory Lightweight Directory Services (AD LDS). AD LDS, previously known as Active Directory in Application Mode (ADAM), is a directory technology that is very similar to the full Active Directory Domain Services (AD DS), but has the capability to run separate instances of itself as unique services. AD LDS allows specialized applications to utilize AD LDS as their own directory service, negating the need for a new form of directory service for every critical application within an organization.

AD LDS uses the same replication engine as AD DS, follows the same X.500 structure, and is close enough to real AD DS functionality to allow it to be installed as a test bed for developers who design AD DS applications. Despite the similarities, however, AD LDS runs as a separate service from the operating system, with its own schema and structure.

The real value to an AD LDS implementation comes from its capability to utilize the security structure of the production domain(s), while maintaining its own directory structure.

Understanding the Need for AD LDS

AD LDS functionality was developed in direct response to one of the main limitations in using Microsoft’s AD DS: the fact that the directory was so intrinsically tied to the NOS that applications that did not require the extra NOS-related functionality of AD DS were restricted in their particular directory needs. AD LDS allows each application to have its own separate AD DS directory forest and allows for personalized modification of the directory, such as schema extensions, tailored replication (or lack of replication) needs, and other key directory needs.

One of the major advantages to AD LDS also lies in the fact that multiple instances of AD LDS can run on a single machine, each with its own unique name, port number, and separate binaries. In addition, AD LDS can run on any version of Windows Server 2008 R2 or even on Windows 7 or Vista Professional for development purposes. Each instance of AD LDS can utilize a separate, tailored schema.

AD LDS is virtually indistinguishable from a normal NOS instance of AD DS and consequently can be administered using the standard tools used for AD, such as ADSIEdit, LDP.exe, and the Microsoft Management Console (MMC) tools. In addition, user accounts can be created, unique replication topologies can be created, and all normal AD DS functionality can be performed on a tailored copy of an AD LDS forest.

In short, AD LDS provides applications with the advantages of the AD DS environment, but without the NOS limitations that previously forced the implementation of multiple, cost-ineffective directories. Developers now can exploit the full functionality of Windows Server 2008 R2 AD DS without limitation, while at the same time assuming the numerous advantages of integration into a common security structure.

Outlining the Features of AD LDS

The following key points about AD LDS should be understood before installing it into an organization:

• Unlike AD DS, AD LDS does not support global catalogs, Group Policy, domains, forests, or domain trusts.

• AD LDS does not need to be installed on domain controllers. In fact, it’s completely independent of the operating system, and more than one AD LDS entity can exist on each server.

• Management of AD LDS cannot be performed using the familiar AD DS tools such as Active Directory Users and Computers. Tools such as ADSIEdit or LDP.exe or a custom front end need to be used instead.

Installing AD LDS

Multiple AD LDS instances can be installed on the same server, or a single AD LDS instance can be replicated to multiple servers for redundancy. If installing the first AD LDS instance, follow these steps:

1.	From the server, open the Server Manager application (Start, All Programs, Administrative Tools, Server Manager).
2.	Navigate to the Roles node, and then click the link for Add Roles.
3.	On the Before You Begin page, review the notes provided, and click Next to continue.
4.	From the list of server roles, shown in Figure 1, choose Active Directory Lightweight Directory Services by checking the box next to it. Click Next to continue. Figure 1. Installing the AD LDS role on a server.
5.	On the Introduction to Active Directory Lightweight Directory Services page, review the information provided, and click Next to continue.
6.	Note the additional informational messages about needing to run the setup wizard and click the Install button.
7.	Click Close when the Add Roles Wizard is complete.
8.	Launch the Active Directory Lightweight Directory Services Setup Wizard from the Administrative Tools menu.
9.	Click Next at the Welcome screen.
10.	From the dialog box shown in Figure 2, choose whether to create a new unique instance or a replica of an existing instance. In this example, we are creating a new instance from scratch. Click Next to continue. Figure 2. Installing AD LDS.
11.	Type a name for the instance. This name should reflect what the AD LDS instance will be used for. Click Next to continue.
12.	Enter the LDAP and LDAP port that will be used for this instance. If the default LDAP port of 389 or LDAP port of 636 is already in use (for example, if the server is already running AD DS or if another instance of AD LDS is running), choose a unique port. In this example, we choose port 50000 for LDAP and 50001 for LDAPS. Click Next to continue.
13.	On the Application Directory Partition page, shown in Figure 3, choose whether to create an application directory partition. If the application you will be installing creates its own partition, leave it as No. If it does not, and you need to create a partition manually to store objects in, enter it in distinguished name format (that is, CN=PartitionName,DC=domain,DC=com). Click Next to continue. Figure 3. Configuring the application directory partition for AD LDS.
14.	Select where to store the data and data recovery files for AD LDS on the File Locations page, and click Next.
15.	On the Service Account Selection page, select whether to use the network service account (the default) as the service account for this instance of AD LDS. Click Next to continue.
16.	The subsequent page allows for a specific user or group to be defined as administrators for the AD LDS instance. A group account is recommended. After choosing This Account and adding the group, click Next to continue.
17.	The Importing LDIF Files page, shown in Figure 4, allows for custom LDIF files to be imported. These LDIF files were created for specific scenarios that required AD LDS, such as when users will be created in AD LDS. In this example, we import the MS-User.LDF file, so we can create user class objects in the AD LDS instance. Check the boxes required and click Next to continue. Figure 4. Importing LDIF files into the AD LDS instance.
18.	On the summary page, review the selections and click Next to start the creation of the AD LDS instance.
19.	Click Finish when the wizard is complete.

After being created, the AD LDS instance can be administered using ADSIEdit, a low-level directory tool available in the Administrative Tools menu. From ADSIEdit, choose Action, Connect To, and enter a name for the connection (in this example, ADLDS1). Then enter the naming context for the connection point that was created for the instance during the wizard (in our example, CN=adlds1,DC=companyabc,DC=com) and the local server name and custom port created for the computer (in this example, dc2:50000), as shown in Figure 5.

Figure 5. Connecting to the AD LDS instance.

Although it is a much cruder tool to use than the full AD Users and Computers tool, ADSIEdit is very powerful, and full administration of the naming context for the AD LDS instance can be performed. In addition, some custom applications might have their own front end for AD LDS, allowing for eased administration of the instance.