Active Directory Lightweight Directory Services (AD LDS) Overview

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 (http://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 Identity Integration Server (MIIS) or Microsoft Identity Integration Feature Pack (IIFP)—which is a free, lightweight version of MIIS, 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 MIIS, 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 (http://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 (http://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 (http://go.microsoft.com/fwlink/?LinkId=94828).