The Light Weight Directory Services, or AD LDS, has been around in one form or another for quite a few years now. In Windows Server 2003, this service was called the Active Directory Application partition, or ADAM. Being that the service’s new name is the Lightweight Directory Service, I hate to describe the service as a lightweight version of the Active Directory, but that’s really what it is.
The basic idea behind this service is that sometimes you may need to provide an application with Active Directory data or with a way of storing application data in the Active Directory database. In many cases though, providing the application with access to a domain controller may be impossible because of connectivity issues. More often though, security concerns may prevent you from making a domain controller available to the application in question.
A Real World Example
OK, I realize that my description of the AD LDS is a bit abstract, but I want to try to clear things up by explaining one example of how AD LDS is commonly used in the real world. Microsoft makes use of AD LDS in Exchange Server 2007. In case you are not familiar with Exchange 2007, it is Microsoft’s E-mail server product.
Exchange Server 2007 is designed to be run in a distributed manner, and you can configure each individual Exchange Server to perform specific roles. One of these roles is called the Edge Transport Server role. The edge transport server sits at the network perimeter and acts as an entry point for inbound messages coming from the Internet. This server then performs a variety of message hygiene tasks to get rid of spam and viruses. Once the undesirable messages have been disposed of, any remaining messages are sent to something called the hub transport server, which then sends the messages to the mailbox server. I have drawn a diagram of the basic architecture that I am describing, for the benefit of those who may not be familiar with Exchange 2007. You can see this diagram in Figure A.
Figure A This is the basic Exchange Server 2007 architecture.
As you can imagine, the edge transport server needs to be well hardened against attacks. Not only does it routinely have to deal with viruses, it sits at the edge of the network, which means that the server is exposed to the Internet, and is therefore susceptible to attack.
Exchange and AD LDS
Now that I have talked about the basic Exchange 2007 architecture, I want to explain how an edge transport server uses AD LDS. Being that an edge transport server sits at the network perimeter, it needs to be far more secure than the other Exchange Servers in an organization. In an effort to make an edge transport server more secure, Microsoft forbids you from making an edge transport server a domain member. This is a really big deal though, because every version of Exchange Server since Exchange 2000 has been dependant on the Active Directory, and Exchange 2007 is no exception.
Microsoft gets around this issue by using AD LDS to act as a sort of mini Active Directory to the edge transport server. If the edge transport server happens to be installed on Windows Server 2003, then ADAM is used instead of AD LDS. The reason why Microsoft uses this technique is so that the edge transport server will have access to the Active Directory information that it needs, but will not contain any Active Directory information that it does not absolutely require.
I don’t want to get into all of the technical details about the ways in which Exchange Server uses AD LDS. What I will tell you though, is that the edge transport server needs access to some Active Directory information. For example, it needs to know which E-mail addresses are valid for the Exchange organization. E-mail addresses are stored in the Active Directory as attributes of user accounts. At the same time though, there are a lot of other user account attributes that the edge transport server does not need access to. Likewise, the edge transport server does not need to know about other Active Directory objects such as groups, group policy objects, and things like that.
As such, the edge transport server uses a technique called an edge synchronization to communicate with a domain controller. This allows the edge transport server to get the information that it needs, without getting anything extra. This information is then placed into a watered down Active Directory database (the AD LDS database), that no other servers use.
In this article, I have explained one real world example of how AD LDS is used. Of course AD LDS is not unique to Exchange Server. There are plenty of other uses for AD LDS. In Part 2 of this series, I will walk you through a sample AD LDS deployment.
Got a question? Post it on our Exchange Server Forums!
Tagged with AD LDS