LDAP Authentication and AD Forests

* WARNING * This post is TECHNICAL!

Ok, so the subject of this is about a specific item that I have been trying to figure out for work. We have two AD Domains right now that are in the process of being merged into a forest domain. The Forest Domain is a “.local” type and has the other two domains trusted. The intent is to move all objects from the original two domains into the new “.local” domain. Until then there are ongoing authentication pains that I am trying to solve. For this particular instance I am going to focus on Linux based web applications hosted on Apache.

Getting basic LDAP Authentication to a single domain is not really an issue and there are a number of examples all over the place for this. The trick comes when you have a web application that you want users from either domain to be able to use based on their AD Credentials. My objective is NOT to have to move the users from their original domain into the new “.local” domain. So how do you get users from two trusted domains to appear in the “.local” domain? Well through some trial and error I discovered that Domain Local groups can have members from the trusted domains. This was confusing as you would think that the Global or Universal Groups should fill that role but based on the stuff stored in the group I see that it references objects in the CN=ForeignSecurityPrincipals OU. I suppose that since this was the only reference to members in the group definition and that ForeignSecurityPrincipals is a local object reference store that it would be local.

At any rate, after creating the group and checking out the contents I see that the member list was referencing the group members based on their object definitions in ForeignSecurityPrincipals. The value of the members property is like this:

member=CN\=S-1-5-21-123300112-456280006-79907194-12099\,CN\=ForeignSecurityPrincipals\,DC\=Company\,DC\=Local

So that basically blew that idea out of the water. Since the LDAPSEARCH queries typically use the windows username (sAMAccountName) as the identifier. Since that doesn’t exist in the “.local” domain that basically killed that idea. UNLESS I can figure out how to derive the sAMAccountName from the ForeignSecurityPrincipals SID value.

I just had to jot this down to summarize my findings to date so far. I still need to do a bit of digging in this.