LDAP user authentication across trusted domains

My application defines authorized users via LDAP (usually Active Directory):

1. The customer defines an LDAP server (TreeA) and a group (GroupA). Any users in GroupA can use the application.
2. At login time, a user sends their username and password -- if a bind to the LDAP TreeA with their credentials works, AND their user account is in a GroupA, they are good to go

I've come upon a situation where two Active Directories trust each other, and the specified GroupA in TreeA contains users from TreeB. So step #2 fails because I'm 开发者_运维技巧trying to authenticate UserB (from TreeB) against TreeA.

The application has access to TreeA, so I suppose it could look in GroupA and see UserB there. But how would it know that it needs to send bind requests to TreeB to authenticate the username and password?

Is there a better way to approach this?

Should such bind requests to TreeA automagically get forwarded to TreeB since there is a trust relationship??

---

It can be that you have just configuration problem on the LDAP server (TreeA). You wrote that there are trust between TreeA and TreeB, so that you can add UserB (from TreeB) as the member of the GroupA in TreeA. If you can do this, than you have successfully establish trust in the correct direction between TreeA and TreeB. You should understand, that trust mean only that Active Directory B verify the user password only, but UserB per default will have no access to any resources from the Active Directory A. The UserB can has no permission to make LDAP bind to the server A. In the case the problem will solved by granting the UserB the remote login permission on the server A and the read access to GroupA and probably read permission to the OU where GroupA exist. You can try Insight for Active Directory to monitor AD access to localize the permission problems.

Other possible reason of your problem could be the usage of API which you use to LDAP access. In you question you don't wrote any information about the API. Do you use Win32 API like ldap_bind_s or use DirectoryEntry in .NET? In both cases it could be important that you either use explicitly domain name together with the account name (for UserB) during the binding or use null for both name and the password to user current user credential.

The usage of fixed account from TreeA for all accesses to TreeA (also for tests about UserB) could also solve the problem, but it could be possible only is some kind of application usage.

In any way more information in your question could narrow the problem and the ways to solve the problem.

---

Maybe you should use ldap replication such that the objects are always present in both servers?

---

The application has access to TreeA, so I suppose it could look in GroupA and see UserB there. But how would it know that it needs to send bind requests to TreeB to authenticate the username and password?

The member attribute in GroupA will give the full distinguished name (dn) of each member, which might look something like:

member: CN=User1,OU=People,DC=TreeA,DC=foobar,DC=com
member: CN=User2,OU=People,DC=TreeB,DC=foobar,DC=com

So, when 'User2' attempts to authenticate, you could match the CN and know that you should be authenticating against 'TreeB' instead of 'TreeA'. (Presumably you'd have some kind of table mapping the DN to the AD server hostname.) Or, you just brute-force it and try 'TreeB' if you get a 'no such user' from 'TreeA'.

You would need to make a decision how to handle the case of duplicate user names in the two trees - does one take priority over the other?

Another approach would be to require users to specify which tree they're authenticating against, for example by logging in with a login name like 'user1@treea.foobar.com'.

---

Let's say you have Domain A and Domain B that trusted each other, and if you want to authenticate User B from Domain B against Domain A on a Domain A's server so what you have to do are:

1. Impersonate User B on Domain A by using Win32 APIs.

2. Authenticate User B against Domain A using DirectoryEntry, then you can access Domain A's AD for other user information such as assigned groups.

I have implemented it in an ASP.NET application that uses Windows authentication.

Hope it helps,