Recently I was looking to help an application built on ColdFusion’s CFLDAP module, which relied upon LDAP for “authentication”, and could only be used with simple binds as a mechanism for presenting a username/password.
I am working ain a multi-forest, and multi-domain environment, to which I try to minimize the number user accounts needed by applications to access resources across the domain/forest boundary. LDAP using a SASL bind has the ability to use protocols which can walk the trust model, but unfortunately many applications never implement the SASL ability and rely on SIMPLE binds to “integrate” into Active Directory which do not have this ability.
I know that I can logon with a user’s UPN value via a simple bind to/from any domain in the same forest, but what about cross forest? Unfortunately in testing this, it does not appear to be possible and I am assuming due to how the simple bind finds the user principle in the directory to authenticate as.
If I am user1@DomainA.ForestA.com and I try to authenticate to DomainB.ForestB.com via a simple bind, it does not work. I thought that maybe adding crossRef objects to each forest pointing to each other might offer this ability, but this is also not the case. There are Kerberos Name Routing records you can set on a Forest trust, which I thought might enable this scenario, but these do nothing for simple binds as well.
So to sum it up, from what I can tell here are the scenarios that work and don’t work and I an assumption as too why when using the UPN. In the scenario a 2-way Forest trust exists between 2 forests
|user1@DomainA.ForestA.com||DomainA.ForestA.com||Success||Local Domain User|
|user1@DomainA.ForestA.com||DomainB.ForestA.com||Success||I am going to assume there is a search done on the Global Catalog to resolve the user|
|user1@DomainA.ForestA.com||Domain1.Forest1.com||Failure||The Simple bind cannot resolve the user across the forest boundary.|
|user2@Domain1.Forest1.com||DomainA.ForestA.com||Failure||The same as above, but in reverse.|
Unfortunately this is yet another example of how reliance on Simple LDAP binds for integration in complex directory environments break down, yet many applications still rely on them for enterprise integration. This leads to potential workaround infrastructure solutions such as aggregated directories and virtual directories to avoid needing multiple redundant accounts. Thanks for the insight to those on DirectoryProgramming.net forums for setting my expectations correctly that this was not going to be a valid solution to the problem.
If there are other things I overlooked which might make this a reality, please go ahead and drop me a line in the comments.
There appears to be a scenario where you might have a success based on the displayName, as per this conversation.