Coding for Active Directory: Proxying Users into an AD-LDS Application Directory

In another IT Pro tip related to Active Directory, suppose an organization has an internal AD forest, but has a company policy that only paid personnel are to have accounts in that directory.  That's a fairly rational policy:

• If we pay you directly, then you're an employee, so you get an account
• If we pay you indirectly, then you're a contractor that we've hired, so you can also get an account
• If you pay us, whether directly as a consumer, retailer, or reseller, or indirectly as a consumer through a retailer or reseller, then you're a customer, so you probably should not have an account in our internal AD forest.

But suppose you have an application that needs to be built that will allow both employees/contractors, AND customers to access it, and you don't want to setup yet-another-provisioning process for granting and revoking access for employees and contractors?

Enter a common solution: Active Directory - Lightweight Directory Services (previously known as ADAM, AD Application Mode, a.k.a. an "application" directory).  This is a lightweight, LDAP only directory with less bells and whistles than AD has, but many Microsoft-centric applications can plumb right into it.

But to achieve a true Single Sign On for the internal AD users, the IT Admin must create either a UserProxy or a UserProxyFull object in the AD-LDS.  Both function nearly the same, but a UserProxyFull has additional schema data elements for storing additional contact data fields, which are generally handy for today's applications.

Under the hood, when an internal AD user connects to the application, an authentication request is passed to the AD-LDS, which looks up the UserID of the internal user, finds the User Proxy object, and then performs Kerberos authentication against the internal AD.  All other attributes, though, from contact data fields, to the group memberships that the UserProxy has, are separate from the internal AD forest.  In essence, nothing is automatically the same and it's yet-another-directory-to-manage.

Wouldn't it be nice if there was a way to build a service or application in C# .NET so that a configurable subsection of your organization's internal AD user community could automatically be provisioned and deprovisioned, complete with metadata updates, and maybe even rudimentary AD-LDS group memberships based on your AD data?  Why yes, yes that would be very nice.  

Wouldn't it be even nicer if the code was open source so we can take it, borrow it, and use it internally without a restrictive license?  Why yes, yes that would be very nice, too.

Wouldn't be even nicer still if this article linked straight to that source code?

Why yes, yes it sure would be nice.

Good thing we just did! 

Start synchronizing your Active Directory forest with your Lightweight Directory Services (AD-LDS) instance with this example solution in C#.