title: Cannot get .NET application to access AD groups across domains
body: <p>I have a .NET application distributed through <code>ClickOnce</code>. Security within the application is implemented through the <code>WindowsPrincipal.IsInRole(GroupName)</code> 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. </p>
  
  <p>It seems that <code>IsInRole()</code> 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!)</p>
  
  <p>To explain:
  There are two domains: DOM1 and DOM2 with a trust setup between them, but they are not in the same forest.</p>
  
  <pre><code>DOM1\User1
  DOM2\User2  
  </code></pre>
  
  <p>are two users.</p>
  
  <p>I would like to put both <code>User1</code> and <code>User2</code> in one group that is visible to both users and can contain them both.</p>
  
  <p>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.)</p>
  
  <p>Make two global groups one in each domain:  </p>
  
  <pre><code>DOM1\GLOGroup1 : {DOM1\User1}  
  DOM2\GLOGroup1 : {DOM2\User2}
  </code></pre>
  
  <p>and two domain-local groups containing the two global groups:  </p>
  
  <pre><code>DOM1\DLGroup1 : {DOM1\GLOGroup1, DOM2\GLOGroup1}  
  DOM2\DLGroup1 : {DOM1\GLOGroup1, DOM2\GLOGroup1}
  </code></pre>
  
  <p>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.</p>
  
  <p>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?</p>