Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's say I have two active directories: AD-1 and AD-2 and I want to obtain the following behaviour:

When someone tries to do a LDAP search on the AD-2 for authentication to check AD-2 database first and if the user is not found to delegate it to AD-1.

This has to be transparent for the client trying to verify the credentials.

Reasoning: I have some web application that are using LDAP autentication and checking the AD-2 server. AD-1 would be the main corporate one, one that I cannot control, but the AD-2 is under my control.

I need to be able to add users to AD-2, users that are not in AD-1. Still any user frm AD-1 cand be considered as valid for AD-2.

AD-2 contains users from outside the company.

Note: I have minimal experience configuring AD.

share|improve this question
Please tell us what you're trying to achieve by this, and why? – Dan Mar 14 '12 at 10:49
AD doesn't work like that. As @Dan says: tell us what the actual problem that you are trying to solve is. There's probably a much better way to handle it. – MDMarra Mar 14 '12 at 12:10
No. Stop that. You're hurting the servers. – Tom O'Connor Mar 14 '12 at 12:11
Your application would have to support searching multiple LDAP directories, and your user would have to supply which directory they're logging into as, or else there'd be no way to know that jsmith existing on both directories is the one trying to log in to the application; it would end up hitting the first one and the second one would never work. – Bart Silverstrim Mar 14 '12 at 12:36
up vote 1 down vote accepted

This is at least not something already present in Active Directory. Quite to the contrary - when doing authentication against Kerberos or LDAP, you have to explicitly specify the distinguished name of your logon user - which would include the domain name of the same. Any kind of "fallback" would be ineffectual in this case since the explicitly specified domain name "ad1" would not match "ad2" and the authentication would fail when queried against ad2 servers in any case.

The only way to achieve the kind of "directory union" you want is to use an overlay / abstraction above the employed directories to do two searches - one for each directory. If you can modify your web applications, you probably would implement an API to do so, otherwise you would need to implement some kind of proxy service for authentication with this functionality.

The common approach to this kind of problem is called "identity management", although the intended direction - unification of all user-related data and single-sign-on for all applications - is quite the opposite of what you are trying to achieve.

share|improve this answer

This is something that you would have to handle at the application level. If your app makes authentication calls to the ADs, you simply code your app to use both as an authentication source and prefix the username with the proper domain name at each iteration.

There is no native AD functionality for this.

share|improve this answer

We accomplished a similar solution by creating AD2 as a child domain of AD1 (ex: This allows us to add users from the parent domain to groups in the child domain and thereby allow accounts from both to authenticate to the application.

Keep in mind that this was done with full cooperation of the IT staff. If fact, they developed the solution for application use.

A second possible solution is to add a crossRef object to your customer AD that would redirect or refer the authorization request to a secondary LDAP based on the name. This would require you to pass along more than a login name to find the object.. More here on custom crossRef objects in AD.

share|improve this answer

A one way trust could possibly be used to reach this end. I'm not sure but it should be possible to use a trust in conjunction with a read only domain controller from your internal domain. Failing that there are third party apps like Atlassians Crowd that provide single sign on against multiple directories.

EDIT - as pointed out the trust only works with fully qualified names. I found this worked well for my internal users as it was easy enough to request they include their domain names.

I have successfully used Crowd to merge multiple directories into a single interface. Not sure the specifics on your web app but this product (or one like it) may be a possibility.

share|improve this answer
That wouldn't work. When you log in from an AD1 workstation as user, you're actually logging in as ad1\user. To log in to a domain that's part of a trust, you would have to specify ad2\user when logging on. – MDMarra Mar 14 '12 at 12:10
I get that.. What I don't get is why that wouldn't be acceptable here. If folks are using a fully qualified name when logging in - that is a common enough setup - that is already addressed. – Tim Brigham Mar 14 '12 at 13:27
Except that he's asking for a way that someone can just type user and then have his AD automatically try and authenticate user against ad2 and if it fails fall back to ad1 – MDMarra Mar 14 '12 at 13:28
That's interesting, the last answer, with negative votes contains the best info, crowd was already on my radar, because in my case I have to administer several Jira and Confluence instances. Still I think that Crowd should work for any web apps. – sorin Mar 28 '12 at 8:39
Yeah with a little work most webapps can be used with Crowd. My in house devs wish they had looked into crowd before they wrote their own single sign on app. – Tim Brigham Mar 28 '12 at 11:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.