Wednesday, March 18

ADAM Pass Through Authentication to AD

A few years ago, I wrote a post that referenced ADAM passthrough authentication to Active Directory without providing much info. Since then, people searching on that topic have found themselves on my blog (probably hoping for more information). So, I thought I'd cover it in more detail.

Disclaimer:
I haven't actually done this in a few years, so my information may be out of date, but I'm sure someone will speak up if I'm wrong. ...they always do ;) I will assume you know what ADAM is, why you'd use it, where to get it, and how to install & configure it.

Why:
A few quick scenarios where pass through authentication is useful:

  1. You want to put a portion of your Active Directory users into the DMZ for authentication by publicly-facing applications, but you don't want to expose an AD DC in the DMZ. In this scenario, the app can leverage a DMZ'ed ADAM for authentication. ADAM will still need to make a request to a DC, so AD is partially exposed, but in a more controlled way.
  2. You want to leverage AD credentials for application authentication, but the app wants to store information about users that is not currently in AD and you don't want to extend the schema. You could stand up an ADAM instance, extend its schema however you want, enable passthrough authentication, and point the app to ADAM instead of AD.
  3. You have an app that is used by people that have an AD account AND people that don't. And your app only accepts a single authentication store.

Here's what you need to know about using ADAM for pass through authentication to AD:

  • The ADAM installation process gives you the ability to import the schema for UserProxy objects from a file called ms-userproxy.ldf – you'll need to import that object to enable the passthrough functionality. You can do it after the install if you need to.
  • For an account to perform a passthrough authentication (aka a bind redirection) from ADAM, the account must be configured as a UserProxy object. A standard user account can not authenticate through to Active Directory.
  • The UserProxy object has an attribute called ObjectSid, which is critical to this functionality. For passthrough authentication to work, the account's ObjectSid must be populated with the SID of the associated Active Directory user account (this will actually work with any security principal object).
  • When a UserProxy account attempts to bind to the ADAM instance, ADAM recognizes the account as a proxy and forwards the authentication request to Active Directory.
  • Passthrough authentication only works for accounts that live in the forest to which the ADAM server is joined (or to a trusted domain or forest). So, that's how ADAM knows where to send the request.
  • Passthrough authentication only works with simple binds. So, the password is being passed to ADAM in clear text. You'll want to be aware of that and use SSL as appropriate.

That's pretty much all you need to know to get passthrough authentication working. As I recall, it's that simple.

Comments/Corrections:
PLEASE leave a comment if you're here because you want to do this for a reason I haven't mentioned above or if you have additional information. Am I wrong? Did I leave anything out?

More Information:
Microsoft refers to this as Bind Redirection for ADAM Proxy Objects. So, that's the terminology you'll want to use to find more information.

2 comments:

Anonymous said...

Thanks.
But how populate my adam with Ad?

More information here to ADAM
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.windows.server.active_directory&mid=0418ad98-cb6d-488d-a56e-c6ec3e13d948

Matt Flynn said...

I assume you meant more information on the question and not on the answer? Anyway, my first thought would be to look at Microsoft IIFP (Identity Integration Feature Pack) which enables sync between AD and ADAM. But, AD and ADAM both have simple command line tools that can also be scripted to quickly accomplish the same thing - export from AD, modify import to ADAM on a scheduled basis. IIFP gives you more control to manipulate the data on its way into ADAM - change the display name or populate local main line phone numbers instead of the desk phones stored in AD (as examples). Good luck!