Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

13.6. Using ADLDS

From the ActiveDirectoryMembershipProvider's perspective, using ADLDS as a backing store is pretty much the same as using Active Directory as the backing store. ADLDS's schema supports the user class, and just as with Active Directory, you can extend the schema in ADLDS if you choose to enable self-service password resets. In terms of directory structure, you can use the same general approaches for both AD and ADLDS: using a single container for storing users, or separate user containers for different applications. The behavior around user creation/deletion as opposed to other operations works the same way in ADLDS as well (that is, creation and deletion always occur in the container pointed at by the connection string, whereas searches and operations that bind to a user start at the root of the specified container and then wend their way down through the container hierarchy looking for a match). If you are wondering, ADLDS encompasses the same functionality of the ADAM that was available for Windows Server 2003 and Windows XP.

The differences you will encounter when using ADLDS as a directory store with the provider are:

• You can choose to run ADLDS on a machine that is not joined to a domain. This will probably not be common for folks that run a lot of Windows Server machines, but it would be familiar to UNIX shops that just need to talk to an LDAP server and do not need the security mechanisms supported by an AD domain infrastructure.

• ADLDS can be installed ...