다음을 통해 공유

Active Directory Lightweight Directory Services Role

  • 아티클

Applies To: Windows Server 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 directory—rather than a database, flat file, or other data storage structure—to 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.

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 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

  • 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.