Active Directory Lightweight Directory Services Overview

Applies To: Windows Server 2008, Windows Server 2012

By using the Windows Server® 2008 Active Directory® Lightweight Directory Services (AD LDS) role, formerly known as Active Directory Application Mode (ADAM), you can provide directory services for directory-enabled applications without incurring the overhead of domains and forests and the requirements of a single schema throughout a forest.

In the following sections, learn more about the AD LDS server role, the features in it, and the software and hardware considerations for installing it.

What is the AD LDS server role?

AD LDS is a Lightweight Directory Access Protocol (LDAP) directory service that provides flexible support for directory-enabled applications, without the dependencies that are required for Active Directory Domain Services (AD DS). AD LDS provides much of the same functionality as AD DS, but it does not require the deployment of domains or domain controllers. You can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance.

AD DS provides directory services for both the Microsoft® Windows Server server operating system and for directory-enabled applications. For the server operating system, AD DS stores critical information about the network infrastructure, users and groups, network services, and so on. In this role, AD DS must adhere to a single schema throughout an entire forest.

The AD LDS server role, on the other hand, provides directory services specifically for directory-enabled applications. AD LDS does not require or rely on Active Directory domains or forests. However, in environments where AD DS exists, AD LDS can use AD DS for the authentication of Windows security principals.

When should I use the AD LDS server role?

The following sections describe common AD LDS enterprise directory solutions.

Providing an enterprise directory store

AD LDS is a full-fledged LDAP directory solution for enterprises. All directory-enabled enterprise applications can use AD LDS as their directory store.

AD LDS can store “private” directory data, which is relevant only to the application, in a local directory service—possibly on the same server as the application—without requiring any additional configuration to the server operating system directory. This data, which is relevant only to the application and which does not have to be widely replicated, is stored solely in the AD LDS directory that is associated with the application. This solution reduces replication traffic on the network between domain controllers that serve the server operating system directory. However, if necessary you can configure this data to be replicated between multiple AD LDS instances.

Enterprise applications must often store personalization data that is associated with authenticated users in AD DS. Storing this personalization data in AD DS would require AD DS schema changes. In this scenario, an application can use AD LDS to store application-specific data, such as policy and management information, while it uses the user principals in AD DS for authentication and for controlling access to objects in AD LDS. Such a solution makes it unnecessary for each AD LDS directory to have its own user database. Therefore, this solution prevents a proliferation of user IDs and passwords for end users every time a new directory-enabled application is introduced to the network.

Providing an extranet authentication store

Consider the example of a Web portal application that manages extranet access to corporate business applications and services identities that are external to the corporate AD DS. Another example might be a hosting scenario in which a provider offers domain and storage services to its customers by maintaining and updating customer-dedicated Web or data servers, with no customers having access to these servers.

These servers and portal applications that are deployed in an extranet have custom identity needs. They require an authentication store to save authorization information for the identities that they service. AD LDS is a good candidate for this authentication store because it can host user objects that are not Windows security principals but that can be authenticated with LDAP simple binds. In other words, Web clients can be serviced by portal applications that can run on any platform while they use AD LDS as a simple LDAP authentication store.

If a portal application that you deploy in an extranet must service internal AD DS-authenticated identities that are currently located outside the corporate firewall, you can still deploy AD LDS as the authentication store with the corporate account credentials of these identities provisioned on the extranet instances of AD LDS, as shown in the following illustration.

You can also deploy AD LDS as an extranet authentication store along with Active Directory Federation Services (AD FS). This configuration enables Web single-sign-on (SSO) technologies to authenticate users to multiple Web applications with a single user account. For more information, see Active Directory Federation Services Overview (https://go.microsoft.com/fwlink/?LinkId=95311).

Consolidating identity systems

You may have a scenario in which a data model restriction, such as a single LDAP partition view or a single organizational unit (OU) view, is imposed on an enterprise directory-enabled application that must access data that is associated with AD DS-authenticated users, applications, or network resources that are located in multiple forests, domains, or OUs in the enterprise. Identity information for this directory-enabled application must be consolidated from multiple Active Directory forests, domains, and OUs or from multiple identity systems and other directories, such as human resource databases, SAP databases, telephone directories, and so on.

AD LDS offers a consolidating directory solution because you can deploy it along with a metadirectory. Metadirectories, such as Microsoft Forefront Identity Manager (FIM), can provide directory-enabled applications with a unified view of all known identity information about enterprise users, applications, and network resources by performing identity integration, directory synchronization, account provisioning and deprovisioning, and password synchronization between AD DS and AD LDS, as shown in the following illustration.

Providing a development environment for AD DS and AD LDS

Because AD LDS uses the same programming model and provides virtually the same administration experience as AD DS, it can be a good fit for developers who are staging and testing various Active Directory-integrated applications. For example, if an application under development requires a different schema from the current server operating system AD DS, the application developer can use AD LDS to provide the application with a tailored schema that works for business needs, data requirements, and workflow processes, without altering the configuration of the corporate Active Directory deployment. Developers can work with an AD LDS instance without the need for a complicated setup and later move the application to AD DS. Developers may want a directory that they can easily program to without requirements for extensive setup or hardware support during the development process. This can be achieved through AD LDS as it can easily be installed and uninstalled on any Windows Server 2008 computer. This allows rapid restoration to a clean state during the application prototyping and development process.

Providing a configuration store for distributed applications in Windows Server

You may have a distributed application that requires a configuration store with multimaster update and replication capabilities to service its multiple components, for example, a firewall application that accesses network and application ports data, a junk mail filtering application that accesses e-mail address lists, or a workflow application that accesses enterprise and policy data. You can deploy AD LDS as a lightweight configuration store for such applications, as shown in the following illustration.

In this scenario, an AD LDS instance that serves as the application's configuration store is bundled with a distributed application. This way, application designers do not have to be concerned about the availability of a directory service before the installation of the application. Instead, they can include AD LDS as a part of their application’s installation process to ensure that the application has access to a directory service immediately upon installation. The application then configures and manages AD LDS entirely on its own or partially, depending on the application’s exposure to the AD LDS management, and it uses AD LDS to address its various data requirements.

Migrating legacy directory-enabled applications

Your organization may use an already established directory with X.500-style naming (O=<organization>,C=<country>) to serve various legacy applications, but it may also want to migrate its enterprise directory to AD DS. In this scenario, you can use AD LDS as an interim solution. You can deploy AD LDS to serve and provide support for the legacy applications that rely on X.500-style naming, while you can use AD DS in the enterprise to provide a shared security infrastructure. You can use a metadirectory, such as FIM, to automatically synchronize the data in AD DS and AD LDS for a seamless migration experience. The following illustration describes this AD LDS deployment.

Features in the AD LDS server role

You can use the AD LDS server role to create multiple AD LDS instances on a single computer. Each instance runs as a separate service in its own execution context. The AD LDS server role includes the following features to make it easy to create, configure, and manage AD LDS instances:

• A wizard that guides you through the process of creating an AD LDS instance

• Command-line tools for performing unattended installation and removal of AD LDS instances

• Microsoft Management Console (MMC) snap-ins for configuring and managing AD LDS instances, including the schema for each instance

• AD LDS-specific command-line tools for managing, populating, and synchronizing AD LDS instances

In addition to these tools, you can also use many Active Directory tools to administer AD LDS instances.

The Windows Server 2008 operating system includes the additional AD LDS features in the following table.

Feature	Description
Install from Media (IFM) Generation	With this feature, you can use a one-step Ntdsutil.exe or Dsdbutil.exe process to create installation media for subsequent AD LDS installations.
Audit AD LDS changes	With this feature, you can set up AD LDS auditing with a new audit subcategory to log old and new values when changes are made to objects and their attributes. Note  This feature also applies to AD DS. For more information, see AD DS: Auditing (https://go.microsoft.com/fwlink/?LinkId=94846).
Data Mounting Tool	With this feature, you can view directory data that is stored online in snapshots that are taken at different points in time to better decide which data to restore, without having to restart the server. Note This feature also applies to AD DS. For more information, see AD DS: Data Mounting Tool (https://go.microsoft.com/fwlink/?LinkId=94847).
Support for Active Directory Sites and Services	With this feature, you can use the Active Directory Sites and Services snap-in to manage replication among AD LDS instances. To use this tool, you must import the classes in MS-ADLDS-DisplaySpecifiers.LDF to extend the schema of a configuration set that you want to manage. To connect to an AD LDS instance that hosts your configuration set, specify the computer name and the port number of a server that hosts this AD LDS instance.
Dynamic list of LDAP Data Interchange Format (LDIF) files during instance setup	With this feature, you can make custom LDIF files available during AD LDS instance setup—in addition to the default LDIF files that are provided with AD LDS—by adding the files to the %systemroot%\ADAM directory.
Recursive linked-attribute queries:	With this feature, you can create a single LDAP query that can follow nested attribute links. This can be very useful in determining group membership and ancestry. For more information, see article 914828 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=94828).

In the Windows Server 2008 R2 operating system, AD LDS includes the following new features (also available for AD DS in Windows Server 2008 R2) that help improve its manageability and supportability:

• Active Directory Recycle Bin: Enhances your ability to preserve and recover accidentally deleted Active Directory objects. For more information, see What's New in AD DS: Active Directory Recycle Bin (https://go.microsoft.com/fwlink/?LinkId=141392).

• Active Directory PowerShell: Provides command-line scripting for administrative, configuration, and diagnostic tasks, with a consistent vocabulary and syntax. For more information, see What's New in AD DS: Active Directory PowerShell (https://technet.microsoft.com/en-us/library/dd378783.aspx).

• Active Directory Web Services: Provides a Web service interface to Active Directory domains, AD LDS instances, and Active Directory Database Mounting Tool instances. For more information, see What's New in AD DS: Active Directory Web Services (https://technet.microsoft.com/en-us/library/dd391908.aspx).

Hardware and software considerations

Use performance counters, testing in the lab, data from existing hardware in a production environment, and pilot roll-outs to determine the capacity needs for your server.

Installing AD LDS

To install AD LDS on Windows Server 2012

1. Open Server Manager Dashboard, click Add roles and features.

2. On the Before you begin page, select Role-based or Feature-based installation and then select the option Select a server from the server pool.

3. Select the server name, and follow the rest of the instructions on the AD LDS installation wizard.

To install AD LDS on Windows 8

1. In Windows 8, AD LDS is listed within Windows Features. To install AD LDS, open control panel, click Programs, click Turn Windows features on or off, select Active Directory Light Weight Directory Services

2. Follow the rest of the instructions on the installation wizard.

To install AD LDS on Windows Server 2008 and Windows Server 2008 R2

1. After you finish installing the operating system, a list of initial configuration tasks appears.

   To install AD LDS, in the list of tasks, click Add roles, and then click Active Directory Lightweight Directory Server.

2. After you add the AD LDS server role to your server, you can create an AD LDS instance. To create an AD LDS instance, click Start, point to Administrative Tools, and then click Active Directory Lightweight Directory Services Setup Wizard.

Managing an AD LDS instance

You can manage AD LDS instances by using the ADSI Edit MMC snap-in. To manage an AD LDS instance, click Start, point to Administrative Tools, and then click ADSI Edit.

For more information

To learn more about AD LDS, click the AD LDS Help link in Server Manager.