Cannot get .NET application to access AD groups across domains

Question

I have a .NET application distributed through ClickOnce. Security within the application is implemented through the WindowsPrincipal.IsInRole(GroupName) method using a set of groups as resources. This structure works well for us for users within the same domain as the groups. Unfortunately we now have users that need to use the application working on machines and using user accounts in a different domain that is trusted by our domain but is not in the same forest.

It seems that IsInRole() queries the AD ticket on the local machine for group membership. Unfortunately this ticket only contains domain-local groups for the domain of the machine and global and universal groups of other trusted domains, our groups are domain-local groups in the first domain. The catch-22 situation comes from the fact that AD does not allow foreign security principals in either global or universal groups and therefore while it can be queried by the users in the second domain they cannot be members of it (making it a little pointless!)

To explain: There are two domains: DOM1 and DOM2 with a trust setup between them, but they are not in the same forest.

DOM1\User1
DOM2\User2

are two users.

I would like to put both User1 and User2 in one group that is visible to both users and can contain them both.

The only way I can currently see around it is the following (where {} denotes the members of the groups, DL=Domain Local and GLO=GlobalGroup.)

Make two global groups one in each domain:

DOM1\GLOGroup1 : {DOM1\User1}  
DOM2\GLOGroup1 : {DOM2\User2}

and two domain-local groups containing the two global groups:

DOM1\DLGroup1 : {DOM1\GLOGroup1, DOM2\GLOGroup1}  
DOM2\DLGroup1 : {DOM1\GLOGroup1, DOM2\GLOGroup1}

But this isn't really acceptable as we actually have more than two domains and about 70 groups to administer including a hierarchy of groups and we don't have much direct control over the administration of groups in the other domains.

We haven't yet worked through any thinking on an approach using LDAP but from the little that I've read I believe it's not generally recommended for this purpose?

Answer 1

shouldnt it be a universal group to allow users from multiple trusted domains?

The user account you are checking the AD with also needs to be able to read each of the ad group ou's.

Mauro

Answer 2

The documentation states ( for the string overload):

The role can only be determined for the domain of the current principal.

But it does not state that for the SecurityIdentifier overload. So probably it will work (have not tested it). You can get the sid with wmi. Examples are not to be found.

Answer 3

you might try using LDAP instead, but you'll have to know which LDAP server to query; see this answer for sample code

Answer 4

Thanks,

I've tried that but have the problem that even if I query the group membership using LDAP it returns the SID of the Foreign Security Principal not the full LDAP-AD path of the user. If I query the group membership of the FSP it returns a blank set, and if I query the group membership of the DOM2 user it returns groups in DOM2, even if I explicitly query a DOM1 server.

Am I using LDAP incorrectly? I'm currently recursing down the group tree for the groups in which the user resides.

Thanks

Stu

Answer 5

I'm quite curious how you solved this issue..

thanks, Koen