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.

What is a Directory? ...LDAP, AD and ADAM

Note: This is not content for LDAP professionals. This is
content for the LDAP-confused. Proceed with caution.

Overview

An LDAP directory is simply a type of database that is hierarchical in structure. LDAP is the protocol used to interact with that database. So, when you hear someone refer to putting data into LDAP, what they really mean is using the LDAP protocol to put data into a directory (a hierarchical database that communicates via LDAP).

Relational Databases

The databases used most frequently across today's IT landscape (Oracle, SQL Server, MySQL, etc.) are relational in structure. That is, data is stored in tables and data is connected to other data by way of relationships between tables. For example:

In this sample database, we see that Joe Johnson is a Clerk that reports to John Smith. Joe's job title is not in the same table as his name, but we know what it is because of the relationship between the tables. This is a relational data structure and it's the structure that's commonly used when we use the term database.

LDAP Directory Structure

An LDAP directory is hierarchical in structure. Joe's data would look like this in a directory:A directory uses the concept of an object to represent Joe's data. The directory schema defines the type of objects that will be allowed in this directory and what attributes are associated to those objects. Above we see that an object exists for Joe Johnson with attributes for employee number, first name, last name, job title and manager.

Directory Servers

There are a number of directory servers available on the market, including but not limited to:

• Sun Directory Server
• Novell eDirectory
• Oracle Internet Directory
• IBM Tivoli Directory Server
• OpenLDAP
• Fedora Directory Server

Note: I purposely left Microsoft off this list because I'll
cover AD and ADAM in the next section.

Each of the directory servers listed above (and most others) support a common protocol for storing, accessing, modifying and managing data. This protocol is LDAP. By standardizing on a common protocol, application developers can write their applications to store data in any LDAP compliant directory server. Organizations can choose to implement whichever directory server they prefer and feel fairly confident that an LDAP-ready application will be able to consume or interact with their data.

Vendor-neutrality is theoretically achievable with relational database servers as well. I say theoretically because the big database vendors provide add-ons to the standard SQL language that are convenient for developers but sometimes challenging for portability. The main reasons the industry moved away from relational and toward directories for some uses are as follows:

• Query Speed: LDAP directories typically provide faster query response times
• Ease of Management: LDAP's hierarchical structure makes it easy to assign rights and privileges to subsets of users as well as to enable delegated administration over portions of the directory tree.
• There are probably others, but I believe these are the two big ones - please let me know if I'm missing anything here.

Microsoft Active Directory

With the release of Windows 2000 and the migration from Windows NT as their business networking platform, Microsoft introduced Active Directory (AD). AD is an LDAP directory at its core but it doesn't necessarily play by all the same rules. Because AD is used to manage a network environment - authentication, access rights, user management, etc., AD needed to be much more than just a database.

Note: AD is a predominant part of most IT organizations today. As I travelled to various organizations as an IdM consultant, I almost never encountered an organization that didn't have a mature AD environment containing some of the most up-to-date employee data in the entire organization. Based on my experience, AD has become the de-facto enterprise directory for most organizations.

As the identity management market grew throughout 2000 and 2001, organizations realized the need to leverage LDAP directories more and more. Because AD was already widely deployed and held good data, many organizations wanted to leverage AD -- or at least AD data -- for their identity infrastructure. AD administrators however recognized the need to protect their AD infrastructure and most decided against using AD for anything outside of its core network management role. This is why Microsoft introduced ADAM.

Microsoft ADAM

ADAM (Active Directory Application Mode) is based on the same core LDAP technology on which AD is based. But ADAM installs without all the overhead of the OS and network management capabilities that AD provides. ADAM is a stand-alone LDAP directory store similar to those provided in the list above. ADAM does not require AD to run -- it's not an extension of a given AD environment. But, it can be used to augment the functionality of AD. For example, some organizations use ADAM to store employee information for white pages or other applications that they prefer not to query AD directly. Other organizations use ADAM to store non-employee data while relying on AD for employee information. One interesting use of ADAM is as an authentication proxy. You can send an authorization request to ADAM and have it pass the request to AD - thereby leveraging AD credentials while disallowing applications to connect directly to AD.

Conclusion

A directory is just a type of database. LDAP is a way to communicate with a directory. ADAM is a stand-alone directory and not a feature of AD. There are lots of LDAP directory varieties to choose from.

Let me know if I should include additional info here. My main point was to tackle the simple points made in the conclusion. I run into confusion on those topics quite often.

Internal users, AD password synch and Virtual Directory

At MaXware, we have a product that hooks into Active Directory to capture password changes. Once the change is captured, we can synch passwords downstream to connected data stores (directory, SQL DB, etc.). Like other implementations of this type of solution, ours requires having a component installed on each AD DC to identify and pick up the password changes. Although it's not generally preferable to install software on Domain Controllers, it serves a specific purpose in this case and AD administrators have been known to give-in to their business counterparts to make it happen.

The underlying need is probably obvious - multiple apps each have associated passwords. And more passwords means more to remember, less likelihood of utilizing strong passwords and higher likelihood of non-secure password practices (written notes, etc.).

As we all know, another way to solve the problem is to implement Single Sign On or Reduced Sign On solutions that enable applications to leverage a common authentication mechanism (or at least a common auth store). These solutions are complicated to implement and costly. And you usually need to find a way to synch with AD anyway since corporate users typically change their passwords using Ctrl-Alt-Delete.

ADAM directories serve as one possible solution for some of this pain. You can implement an ADAM directory to serve as the application identity store or even as a central authentication store and pass authentication request credentials through to Active Directory. This means a single password stored in Active Directory that can serve the network environment as well as the apps that leverage ADAM as the Auth Store. If you centralize the store, you don't really NEED to centralize the authentication mechanism, which might be nice in some cases. In environments with a large amount of custom-developed applications, a centralized mechanism would probably provide significant value even if there's already a common authentication store.

Wouldn't it be nice, though, if you could do the same thing without needing to implement ADAM directories and without storing the AD password in two locations? What if a Virtual Directory could pass authentication requests to Active Directory the way that ADAM does? You could potentially use the Virtual Directory to expose only specific attributes to given applications, reduce the overhead of an additional directory infrastructure, eliminate the need to store the AD password in multiple locations (and the need to install agents on AD DCs) and still achieve authentication to multiple systems using a single set of credentials.

[UPDATED Mar. 8, 2006] - Shorty after posting this, I was informed that MaXware Virtual Directory (along with its competition) does, in fact, support passthrough authentication to AD. I guess I thought ADAM was doing more than a simple bind, which is not the case -- I think I learned that years ago and forgot it again. So, I removed the question on technical feasibility. I guess the question becomes why aren't more people talking about this? It seems like it would be an incredibly useful application of our product.

[UPDATED Mar. 18 2009] - I posted more information about ADAM passthrough authentication.