During a recent engagement, I was integrating a web portal with the client’s Active Directory service to permit end users to access the portal using their Active Directory credentials. The web portal was coded to treat AD as plain LDAP directory server, meaning that the portal didn’t support any of the native AD authentication methods (NTLM, Kerberos etc.) Additionally, the portal made assumptions that user account objects were all stored in a single LDAP container object,
As any experienced consultant knows, assumptions almost never hold when you arrive onsite. In my case, the client’s AD infrastructure scattered user accounts throughout various OUs within the domain. In general, segregating user accounts by placing them in different OUs is a good security practice since it helps split user accounts across different administrative domains.
In order to create a view of the user accounts that satisfied the web portal’s assumptions, I investigated using Microsoft’s Lightweight Directory Services (AD LDS). Basically, AD LDS is a lightweight LDAP server that ships with a set of utilities that permit it to synchronize with a full blown Active Directory instance. Furthermore, an AD LDS instance can be created with a completely different DN structure, yet be synchronized with objects that reside in another DN structure in an Active Directory instance.
In addition, AD LDS can authenticate users against their domain credentials that are stored in the target Active Directory instance. This is made possible by using the userProxy class to store user accounts in AD LDS. The userProxy object basically permits AD LDS to act as a proxy to the backend AD instance. Thus, when a simple LDAP bind is performed against the AD LDS instance, it authenticates to the backend AD instance using native AD authentication methods.
Using AD LDS as a proxy for user account information stored in Active Directory has several important advantages:
- Any applications which require attributes that are not included in AD can be added to the AD LDS schema without impacting the Active Directory schema.
- Custom views of AD data can be created to place AD objects in different locations within the directory structure if needed by applications.
- Active Directory data can be exposed to applications without exposing the AD server directly to applications.
- If the backend AD servers aren’t configured to support LDAPS (!!), an AD LDS instance can be setup to provide LDAPS connections to applications.
Sychronizing AD LDS with Active Directory is fairly well documented; the biggest hurdles I had to overcome was identifying the correct set of attributes to include in my AD LDS userProxy objects. The following sites proved invaluable in getting my installation functional:
- http://technet.microsoft.com/en-us/library/cc794836%28v=ws.10%29
- http://support.microsoft.com/kb/923835
- http://blogs.msdn.com/b/jeff/archive/2007/04/01/synchronize-active-directory-to-adam-with-adamsync-step-by-step.aspx
- http://www.avantgardetechnologies.com.au/2011/06/ldap-error-occured-ldapaddsw-object.html
In summary, consider using AD LDS as a solution to re-use AD credentials for applications.
