Introducing AD LDS
For organizations that require flexible support for directory-enabled applications, Microsoft has developed Active Directory Lightweight Directory Services (AD LDS). AD LDS is a Lightweight Directory Access Protocol (LDAP) directory service.
AD LDS provides data storage and retrieval 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.
What's new in AD LDS
The following features are new to AD LDS in Windows Server 2008 R2:
- The AD LDS server role
- Integration with AD DS
Microsoft directory technologies
With AD LDS, Microsoft provides a choice of directory services. Both AD LDS and AD DS build on the same core Microsoft directory service technologies, but they address different needs in an organization.
AD DS provides directory services for both the Windows 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.
AD LDS provides directory services specifically for directory-enabled applications. AD LDS does not require or rely on AD DS domains or forests. However, in environments where AD DS exists, AD LDS can use AD DS for the authentication of Windows security principals.
AD LDS and AD DS can run concurrently in the same network. In addition, AD LDS can support both domain users and workgroup users simultaneously, as shown in the following illustration.
A directory-enabled application uses a directory, rather than (or in addition to) a database, flat file, or other data storage structure, to hold its data. Many off-the-shelf applications, as well as many custom applications, use a directory-enabled design. Examples of the types of applications that often use a directory-enabled design include customer relationship management (CRM) applications, human resource (HR) applications, and global address book applications.
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, while relational databases are optimized for transaction processing. In general, consider implementing a directory service if your application reads data more frequently than it writes data. Consider implementing a relational database if your application writes or modifies data more frequently than it reads data.
In addition, directory services also provide such benefits as distributed architecture (multimaster design, replication, and geographical scalability); storage of identity data that is common to applications and platforms throughout an enterprise; flexible data schema; and fine-grained access policies.