AD Group Membership with User From Domain Outside of Forest

Question

Here's one to twist your brain around -
I have kerberos authentication using Active Directory working between a client's web browser and my web-app hosted in JBoss. I also have limited authorization working by checking group memberships using LDAP. This currently only works if all users are in the same domain. The ever-helpful adler_steven has detailed in another thread (http://forum.java.sun.com/thread.jspa?threadID=603815&tstart=15) how to do a group membership check for all Users/Groups in a single forest using the Global Context.
I need to go beyond the domain and even beyond the forest and try to authorize a user from a trusted domain by checking if the user is a member of a group in my domain. Authentication works fine using kerberos. It's the authorization by group check I am having trouble with. I believe there are two ways to approach this:
Approach #1
Access the MS-specific PAC in the kerberos token from the client to get the group SIDs. The structure of the PAC is nicely defined in this article: http://appliedcrypto.com/spnego/pac/ms_kerberos_pac.html. However, I have no idea how to access the decrypted token. I pass the encrypted token that I receive from the browser to myGssContext.acceptSecContext(...) to complete the authentication.
Question: Does anyone know how to get the decrypted kerberos ticket from there, specifically the authorization-data field?
Approach #2
Try to walk through the Active Directory structures in both domains using LDAP. In the domain group that I am checking, I can see a member attribute that references a foreignSecurityPrincipal object. The CN of this object happens to be the objectSID of the user I am looking for in the remote domain. Unfortunately, I have to check the remote domain server directly to verify that. The foreignSecurityPrincipal object itself does not contain any hint about what user it refers to aside from the SID (no originalDomainName attribute or something similar). It is feasible that I could walk the chain of references back to the remote domain AD server. That would require that my configuration include a list of remote domain servers to check (since I could have users from multiple trusted domains) and that my JBoss server have access to those servers.
Question: Does anyone know of some other LDAP-related way of finding information about a user from a remote, trusted domain without having to hit the server for that domain directly?
adTHANKSvance
Eric

Answer 1

You should be able to work back from the foreignSecurityPrincipal object :-) He says with a wry smile..
This post prompts me to think whether one day someone will draw the entity relationship diagram for AD. Oh well, I've been procrastinating for years, a few more won't hurt !
If it was a user from within the same forest, you should just be able to perform a search against a GC using the objectSID as the search filter. I've forgotten, but I don't think they will be represented as foreign security principals.
Have a look at the post titled JNDI, Active Directory and SID's (Security Identifiers) available at
http://forum.java.sun.com/thread.jspa?threadID=585031&tstart=150 that describes how to search for an object based on their SID.
Now if it is a user from another forest, with which you have a trust relationship, then we begin the navigation excercise.
You'll need obtain the user's SID (either from the cn or from the objectSID attributes) from the foreignSecurityPrincipal object. For example CN=S-1-5-21-3771862615-1804478405-1612909269-2143,CN=ForeignSecurityPrincipals,DC=antipodes,DC=com
objectSID=S-S-1-5-21-3771862615-1804478405-1612909269-2143Then obtain the domain RID, eg.S-1-5-21-3771862615-1804478405-1612909269Next you will have to recurse each of the crossRef objects in the Partitions container, in the configuration naming context (which you will find listed in the RootDSE). The crossref objects that represent trusted domains or forests will have values for their trustParent attributes. A sample query would be something like//specify the LDAP search filter
String searchFilter = "(&(objectClass=crossRef)(trustParent=*))";
//Specify the Base for the search
String searchBase = "CN=Partitions,CN=Configuration,DC=antipodes,DC=com";For each crossRef object, you can then use the dnsRoot attribute to determine the dns domain name of the forest/domain (if you want to later use dns to search for the dns name,ip address of the domain controllers in the trusted domains/forests), and then use the nCName attribute to determine the distinguished name of the trusted forest/domain.dnsRoot = contoso.com
ncName = dc=contoso,dc=comPerform another bind to the ncName for the trusted domain/forest and retrieve the objectSID attribute, which will be the domain's RID. You may want to cache this information as a lookup table to match domain RID's with domain distingusihed names and dns names.String ldapURL = "ldap://contoso.com:389";
Attributes attrs = ctx.getAttributes("dc=contoso,dc=com");
System.out.println("Domain SID: " + attrs.get("objectSID").get());Once you find out which domain matches the RID for the foreignSecurityPrincipal, you can then perform a search for the "real user" .And then finally you should have the user object that represents the foreign security principal !
Just one thing to note. Assume that CONTOSO and ANTIPODES are two separate forests. If you bind as CONTOSO\cdarwin against the CONTOSO domain, the tokenGroups attribute (which represents teh process token) will contain all of the group memberships of Charles Darwin in the CONTOSO domain/forest. It will not contain his memberships if any, of groups in the ANTIPODES forest. If Charles Darwin accesses a resource in ANTIPODES, then his process token used by the ANTIPODES resource will be updated with his group memberships of the ANTIPODES forest. Also you can have "orphaned foreignn security principal", where the original user object has been deleted !
BTW, If I was doing this purely on Windows, IIRC, you just use one API call DsCrackNames, to get the "real user", and then the appropriate ImpersonateUser calls to update the process token etc..
Good luck.