ADAM (Active Directory Application Mode), now called AD LDS (Lightweight Directory Services) is a standalone LDAP server from Microsoft. AD LDS has been around for awhile, but it’s never gotten the notice that it deserves. Personally, I’ve always been intrigued by LDS, but I’ve never taken the time to give it a closer look. Over the last year, I’ve been hearing interesting tidbits from other universities about how they have used LDS to solve some hard problems, so I’ve become more intrigued about it.

Then a few months ago, I was fortunate enough to be able to attend a presentation given by Dmitry Gavrilov from Microsoft. Dmitry is the core developer of LDS, and has been on the core developer team since project inception in 2002. This was a great opportunity for me to fill in the blanks in my awareness of LDS functionality, and possibly to find out whether it might be useful for the UW.

LDS has a flexible, barebones schema. This is because the intention was provide a LDAP directory product that didn’t come with AD’s network OS overhead. LDS doesn’t require AD, but when used with AD, can provide some very interesting and useful functionality that AD by itself can’t provide.

LDS does not have a user objectclass (i.e. no objects with objectclass=user), instead: there are two kinds of directory objects that can bind:

  • objects with objectclass=msDS-BindableObject, for an ADAM-based “user” principal
  • “User Proxy” objects, i.e. any object with objectclass=msDS-BindProxy

“User Proxy” objects are *very* interesting, and are the source of functionality that AD itself can’t provide. Let’s look closer at User Proxy objects.

At creation time, User Proxy objects are associated with an existing Windows user account, either an account local to the LDS server or a Windows domain account trusted by the LDS server, with the SID of that Windows user account stamped on the User Proxy object. User Proxy objects have *no* password set on them. To login with a User Proxy object, you do a simple LDAP bind, sending the LDS server the password associated with the Windows user account represented by the SID stamped on the User Proxy object. LDS takes the simple LDAP bind request, does a LsaLookupSids() call to find the Windows authority for the associated SID on the User Proxy object, and then finally LDS proxies an authentication attempt to that other Windows authority by performing Windows impersonation via a LogonUser() call with the password value provided in the simple LDAP bind. Assuming successful authentication, the user then has a logon token issued by LDS.

*None* of the user attributes associated with the Windows user account are proxied into this logon token. Instead, only attributes associated with the User Proxy object are associated. This is an important detail, because it means you don’t get any of the underlying Windows user account’s info, but you also gain control at the LDS server level of what’s in the logon token.

Any given LDS server can only have a single User Proxy object associated with the same SID, however, you can have as many independent LDS servers as you’d like all with User Proxy objects which point at the same SIDs.
For some scenarios, this could be one solution to the problem most universities face of needing to delegate some AD user attribute administration across many departmental IT groups, but not having the ability to delegate to all those departmental IT groups. You no longer need to collect information to determine which user goes with which group, or to solve the multiple departmental affiliation problems. You simply have departmental IT groups which need to control some user attributes for specific applications run their own LDS server, and use it to set the user attributes they need, while still leveraging the centrally provided authentication.

Note that for this to work, you have to be able to control which LDAP server the client/application is using. So this isn’t a solution for tightly integrated Windows user attributes like home directory, roaming profile, etc.
However, it’s my understanding that some universities use this functionality for non-Windows OS support like Mac OS or Unix clients. They point those clients at the LDS LDAP server, and get central authentication along with departmental control of the necessary user attributes expected by those platforms.

It’s worth pointing out that the functionality provided by LDS’s User Proxy feature is similar to the functionality provided by Virtual Directories that I blogged about recently. You could gain some of the same control and integration by using a Virtual Directory product, based on product specifics. The primary differences are that LDS is a Microsoft product and its free. Of course, there are more detailed differences under the hood.

Two other tools included in LDS are worth noting:

  • ADSchemaAnalyzer is very useful, allowing you to compare the schema of two LDAP directories.
  • ADAMSync provides a simple out-of-the-box DirSync solution to copy AD data into LDS. It doesn’t handle complex data transformations like ILM/FIM do, nor does it sync schema.

All in all, LDS is a worthwhile tool to have in your toolbox, and I’ll now be on the lookout for scenarios where it’d be a good fit.