Active Directory Lightweight Directory Services

Of the five different Active Directory technologies available in Windows Server 2008, the one that most resembles Active Directory Domain Services (AD DS) is Active Directory Lightweight Directory Services (AD LDS). That’s because AD LDS is really nothing more than a subset of AD DS functionality. Both use the same core code, and both provide a very similar feature set.

Use the buttons below to navigate through the lesson

AD LDS, formerly called Active Directory Application Mode (ADAM), is a technology that is designed to support directory enabled applications, on an application-by-application basis, and without having to modify the database schema of your network operating system (NOS) directory running on AD DS.
AD LDS is a boon to administrators who want to use directory enabled applications without integrating them in their NOS directory.

Active Directory Domain Services can also support the use of directory-enabled applications. One very good example is Microsoft Exchange Server 2007. All user information in Exchange Server is provided by the directory. When you install Exchange Server into your network, it begins by extending the AD DS schema, practically doubling its size.

Schema modifications are not to be taken lightly because, when you add an object or an attribute to the AD DS schema, it will be added forever; it cannot be removed. You can deactivate or rename and reuse these objects, but who wants defunct objects in their NOS directory? Adding to the schema for an application such as Exchange Server is appropriate because it provides a core networking service: e-mail.

However, when it comes to other applications, especially applications that are provided by third-party software manufacturers, carefully consider whether you should integrate them into your AD DS directory. You don’t want to find yourself in a situation in which you integrated a product to your directory and then, several years later when the third-party manufacturer is out of business, have to figure out what to do with the extensions this product added to your AD DS structure, increasing replication timings and adding unused content in the directory.

This is why AD LDS is such a boon. Because it can support multiple AD LDS instances on a single server (unlike AD DS, which can support only one instance of a directory on any given server), AD LDS can meet the requirements of any directory enabled application and even provide instances on an application by application basis.

In addition, you do not need Enterprise Administrator or Schema Administrator credentials to work with AD LDS, as you would with AD DS.
No, AD LDS runs on member or standalone servers and requires only local administration access rights to manage it. Because of this, it can also be used in a perimeter network to provide application or Web authentication services.
AD LDS is one of the four Active Directory technologies that enable you to extend your organization’s authority beyond the firewall and into the Internet cloud.

Understanding AD LDS

Like AD DS, AD LDS instances are based on the Lightweight Directory Access Protocol (LDAP) and provide hierarchical database services.

Unlike relational databases, LDAP directories are optimized for specific purposes and should be used whenever you need to rely on fast lookups of information that will support given applications.

The major differences between an LDAP directory and a relational database such as Microsoft SQL Server are shown on the next slide. This comparison should help you to understand when to choose an LDAP directory in support of an application over a relational database.

LDAP Directories Relational Databases
Fast read and searches. Fast writes.
Hierarchical database design often based on the Domain Name System (DNS) or the X.500 naming system. Structured data design relying on tables containing rows and columns. Tables can be linked together.
Relies on a standard schema structure, a schema that is extensible. Does not rely on schemas.
Decentralized (distributed) and relies on replication to maintain data consistency. Centrally located data repositories.
Security is applied at the object level. Security is applied at the row or column level.
Because the database is distributed, data consistency is not absolute at least not until replication passes are complete. Because data input is transactional, data consistency is absolute and guaranteed at all times.
Records are not locked and can be modified by two parties at once. Conflicts are managed through update sequence numbers (USNs). Records are locked and can be modified by only one party at a time.

Unlike AD DS, AD LDS can have multiple instances on the same server, do not alter the schema, can be run on client operating systems such as Vista and can be installed and uninstalled without the need for rebooting.

Now that you have a better understanding of AD LDS and its feature set, you can begin to identify scenarios in which you would need to work with this technology. Consider these scenarios when you decide whether to rely on AD LDS or AD DS.

When your applications need to rely on an LDAP directory, consider using AD LDS instead of AD DS.
AD LDS can often be hosted on the same server as the application, providing high-speed and local access to directory data. This would reduce replication traffic because all required data is local.

In addition, you can bundle the AD LDS instance with the application when you deploy it. For example, if you have a human resources application that must rely on custom policies to ensure that users can access only specific content when their user object contains a set of particular attributes, you can store these attributes and policies within AD LDS.

Rely on AD LDS to provide data associated with user accounts in AD DS but requiring extensions to the AD DS schema to support it.

Using AD LDS in this scenario provides the additional user data without modifying the AD DS schema. For example, if you have a centralized application that provides a photograph of each employee in your organization, and associates that photograph with the user’s AD DS account, you can store the photographs in an AD LDS instance.

By storing the photographs in AD LDS in a central location, they are associated with the user accounts in AD DS, but because they are in AD LDS, they are not replicated with all other AD DS data, reducing bandwidth requirements for replication.

Rely on an AD LDS instance to provide authentication services for a Web application such as Microsoft SharePoint Portal Server in a perimeter network or extranet.

AD LDS can query the internal AD DS structure through a firewall to obtain user account information and store it securely in the perimeter network.

This avoids having to deploy AD DS in the perimeter or having to include domain controllers from the internal network in the perimeter.

Note that you can also rely on Active Directory Federation Services (AD FS) to provide this access. AD FS is discussed in further detail later in the course.

Consolidate various identity repositories into a single directory store.

Using a metadirectory service such as Microsoft Identity Integration Server (MIIS), Microsoft Identity Lifecycle Manager (MILM), or the free Identity Integration Feature Pack (IIFP), you can obtain data from various sources and consolidate it within an AD LDS instance.

MIIS and MILM support the provisioning of data from a wide variety of sources such as AD DS forests, SQL Server databases, third-party LDAP services, and much more.

IIFP is a subset of MIIS and supports data integration between AD DS, AD LDS, and Exchange Server. Using these solutions reduces your identity management overhead by designating a single master source and provisioning all other repositories from this source.

Provide support for departmental applications. In some cases, departments might require additional identity information, information that is of no relevance to any other department within the organization. By integrating this information in an AD LDS instance, the department has access to it without affecting the directory service for the entire organization.

Provide support for distributed applications. If your application is distributed and requires access to data in several locations, you can also rely on AD LDS because AD LDS provides the same multimaster replication capabilities as AD DS.

Migrate legacy directory applications to AD LDS. If your organization is running legacy applications that rely on an LDAP directory, you can migrate the data to an AD LDS instance and standardize it on Active Directory technologies.

Provide support for local development. Because AD LDS can be installed on client workstations, you can provide your developers with portable single-instance directories they can use to develop custom applications that require access to identity data. Developing with AD LDS is much simpler and easier to manage and contain than developing with AD DS.

In addition, when evaluating directory-enabled commercial applications, you should always give preference to an application that will rely on AD LDS or its predecessor, ADAM, before selecting one that relies on AD DS schema modifications. Deploying commercial
applications with portable directories is much easier and has much less impact on your network than deploying applications that will modify your NOS directory schema forever.

Installing AD LDS

Right click Roles. Select Add Roles. Click Next. Select Active Directory Lightweight Directory Services and click Next.

Click Next. Click Install. Click Close. The new role has been installed. AD LDS creates the ADAM folder and populates it with 20 files and two subfolders. The two subfolders include localization information. Folder is created in the %systemroot%\ADAM.

For the purposes of the next lesson this process was repeated on a second member server SRV2. This will be used as a replica of the AD LDS instance.

The installation process for AD LDS is as simple on Server Core as it is on a full installation of Windows Server 2008. Use the following process:

  1. Log on with local administrative credentials to a Windows Server 2008 member or standalone server running Server Core.
  2. Begin by identifying the service name for AD LDS. Use the following command: oclist | more Using the pipe symbol (|) followed by the more command enables you to view contents one screen at a time. Press the spacebar to move from one screen to the next. Use Ctrl+C to cancel the command after you have found the name of the role. This name should appear in the first screen of information and should be DirectoryServices-ADAM-ServerCore.
  3. Proceed to the installation of the role. Use the following command: start /w ocsetup DirectoryServices-ADAM-ServerCore

Role names are case-sensitive, so ensure that you type the role name exactly as displayed; otherwise, the command will not work. Also, using the start /w command ensures that the command prompt does not return until the role installation is complete.
If you run the oclist command once again, you will see that the AD LDS role has been added to this server. You can also navigate to the %SystemRoot%\ADAM folder to view the new AD LDS files. Your server is ready to host AD LDS instances.

The installation of AD LDS on Server Core does not include the same files and folders as the installation on a full installation of Windows Server 2008. Server Core creates only one folder for localization, whereas the full installation creates two. In addition, the full installation includes an additional tool: the Active Directory Schema Analyzer, which is not installed on Server Core.