5/5/2011

Active Directory Lightweight Directory S

Active Directory
Lightweight Directory Services Role
Updated: January 21, 2008
The Active Directory Lightweight Directory Services (AD LDS) server
role is a Lightweight Directory Access Protocol (LDAP) directory
service. It provides data storage and retrieval for directory-enabled
applications, without the dependencies that are required for Active
Directory Domain Services (AD DS).
AD LDS in the Windows Server 2008 operating system encompasses
the functionality that was provided by Active Directory Application
Mode (ADAM), which is available for Windows XP Professional and
the Windows Server 2003 operating systems.

What does AD LDS do?

AD LDS gives organizations flexible support for directory-enabled
applications. A directory-enabled application uses a directoryrather
than a database, flat file, or other data storage structureto hold its
data. Directory services (such as AD LDS) and relational databases
both provide data storage and retrieval, but they differ in their
optimization. Directory services are optimized for read processing,
whereas relational databases are optimized for transaction processing.
Many off-the-shelf applications and many custom applications use a
directory-enabled design. Examples include:
Customer relationship management (CRM) applications
Human Resources (HR) applications
Global address book applications
AD LDS provides much of the same functionality as AD DS (and, in
fact, is built on the same code base), but it does not require the
deployment of domains or domain controllers.
microsoft.com//cc755080(WS.10,prin

1/4

5/5/2011

Active Directory Lightweight Directory S

You can run multiple instances of AD LDS concurrently on a single

computer, with an independently managed schema for each AD LDS
instance or configuration set (if the instance is part of a configuration
set). Member servers, domain controllers, and stand-alone servers can
be configured to run the AD LDS server role.
AD LDS is similar to AD DS in that it provides the following:
Multimaster replication
Support for the Active Directory Service Interfaces (ADSI)
application programming interface (API)
Application directory partitions
LDAP over Secure Sockets Layer (SSL)
AD LDS differs from AD DS primarily in that it does not store Windows
security principals. While AD LDS can use Windows security principals
(such as domain users) in access control lists (ACLs) that control
access to objects in AD LDS, Windows cannot authenticate users stored
in AD LDS or use AD LDS users in its ACLs. In addition, AD LDS does
not support domains and forests, Group Policy, or global catalogs.

Who will be interested in AD LDS?

Organizations that have the following requirements will find AD LDS
particularly useful:
Application-specific directories that use customized schemas or
that depend on decentralized directory management
AD LDS directories are separate from the domain infrastructure of
AD DS. As a result, they can support applications that depend on
schema extensions that are not desirable in the AD DS directory
such as schema extensions that are useful to a single application.
In addition, the local server administrator can administer the
AD LDS directories; domain administrators do not need to
provide administrative support.
Directory-enabled application development and prototyping
environments that are separate from the enterprise's domain
structure
Application developers who are creating directory-enabled
microsoft.com//cc755080(WS.10,prin

2/4

5/5/2011

Active Directory Lightweight Directory S

applications can install the AD LDS role on any server, even on

stand-alone servers. As a result, developers can control and
modify the directory in their development environment without
interfering with the organization's AD DS infrastructure. These
applications can be deployed subsequently with either AD LDS or
AD DS as the application's directory service, as appropriate.
Network administrators can use AD LDS as a prototype or pilot
environment for applications that will eventually be deployed
with AD DS as its directory store, as long as the application does
not depend on features specific to AD DS.
Management of external client computers' access to network
resources
Enterprises that need to authenticate extranet client computers,
such as Web client computers or transient client computers, can
use AD LDS as the directory store for authentication. This helps
enterprises avoid having to maintain external client information
in the enterprise's domain directory.
Enabling of earlier LDAP client computers in a heterogeneous
environment to authenticate against AD DS
When organizations merge, there is often a need to integrate
LDAP client computers running different server operating systems
into a single network infrastructure. In such cases, rather than
immediately upgrading client computers running earlier LDAP
applications or modifying the AD DS schema to work with the
earlier clients, network administrators can install the AD LDS
server role on one or more servers. The AD LDS server role acts
as an interim directory store using the earlier schema until the
client computers can be upgraded to use AD DS natively for LDAP
access and authentication.

Are there any special considerations?

Since AD LDS is designed to be a directory service for applications, it
is expected that the applications will create, manage, and remove
directory objects. As a general-purpose directory service, AD LDS is
not supported by such domain-oriented tools as:
Active Directory Domains and Trusts
microsoft.com//cc755080(WS.10,prin

3/4

5/5/2011

Active Directory Lightweight Directory S

Active Directory Users and Computers

However, administrators can manage AD LDS directories by using
directory tools such as the following:
ADSI Edit (for viewing, modifying, creating, and deleting any
object in AD LDS)
Ldp.exe (for general LDAP administration)
Other schema management utilities

Do I need to change any existing code?

Applications that were designed to work with ADAM do not require
changes in order to function with AD LDS.

Community Content
2011 Microsoft. All rights reserved.

microsoft.com//cc755080(WS.10,prin

4/4