by 

In the Windows Server 2003 timeframe, Microsoft introduced Active Directory Application Mode, charmingly referred to as ADAM. These days, ADAM has grown up and changed his name to ADLDS (or AD LDS, if you prefer): Active Directory Lightweight Directory Services, which is distinct from the AD directory service that we’re usually referring to when we just say “Active Directory.” In this short chapter, we’ll explore what AD LDS is all about, when you should (and shouldn’t) use it, and how to perform basic troubleshooting and auditing with it.

What Is AD LDS?

Generally speaking, AD LDS is the same as regular AD in every way, except AD LDS doesn’t perform authentication for your entire network. AD LDS is positioned as a “mode” of AD that provides directory service specifically for applications. Microsoft created AD LDS in part to address the reticence people have around extending the schema of their regular directory. Schema extensions are, after all, permanent, and nobody likes to make that kind of permanent extension to the main directory. What if you stop using the application after a few years? Its extensions hang around forever. So AD LDS gives applications a separate directory in which to store their “stuff.”

AD LDS uses the exact same programming APIs as AD DS (Active Directory Domain Services, or the “normal” AD), so programmers don’t have to take any special steps. AD LDS can operate entirely independently or it can operate with replication. Because it isn’t part of your main domain, AD LDS also gives you a way of more easily and safely delegating control over applications’ directory use. Someone can be in charge of an AD LDS install and have zero control over the main directory.

AD LDS does not, however, have any of the infrastructure components of AD DS. It isn’t a directory service for the Windows operating system (OS), so clients can’t authenticate to it. AD LDS can use your normal domain for authentication, which I’ll discuss in a second. Thus, AD LDS can be a part of your domain in much the same way that any application could be. AD LDS doesn’t have Flexible Single Master Operations (FSMO) roles or many of the other infrastructure elements we associate with the full AD DS. In addition, Microsoft Exchange can’t utilize AD LDS because AD LDS doesn’t support the Message Application Programming Interface (MAPI) or support authentication.

AD LDS can be run on a wider array of operating systems—the original ADAM, for example, ran fine on Windows XP. You can even run multiple instances of AD LDS on a single machine. An AD LDS instance isn’t called a “domain controller” because the instance doesn’t provide true domain controller functionality; instead, it is referred to as a “data store” or simply “AD LDS instance.”

Click here to download this chapter or book.

Tags: Active Directory