title: SecurityIdentifier.Translate(typeof(NTaccount)) bugged?
body: <p>When doing a conversion from a SID to an NTAccount, I use the following code:</p>
  
  <pre><code>DirectorySecurity folder_sec = Directory.GetAccessControl("c:\\test", AccessControlSections.All);
  AuthorizationRuleCollection rules = folder_sec.GetAccessRules(true, true, typeof(SecurityIdentifier));
  
  foreach (FileSystemAccessRule rule in rules)
  {
      SecurityIdentifier sid = new SecurityIdentifier(rule.IdentityReference.Value);
      IdentityReference name = sid.Translate(typeof(NTAccount));
  
      string output = name + " | " + sid.tostring();
  }
  </code></pre>
  
  <p>Yes I realize you can get an <code>NTAccount</code> from from the <code>folder_sec.GetAccessRules</code> method but I have discovered that the same subroutine for <code>SecurityIdentifier.Translate</code> is being used and the same bug happens.  At the end of the day, ACLs are just SID arrays.</p>
  
  <p>The bug is, when you have two active directory objects (Group, User, etc) with the exact same name but are in two separate domains (trusted, not sub), the <code>translate</code> method returns the wrong NTAccount.  It ends up returning the NTAccount with the same name in the domain the machine that is executing the code is on.  Getting <code>NTAccount</code>s from other domains that don't happen to share the same name as another object in your domain return fine.</p>
  
  <p>Say you have a directory on a machine that is in domain_frank and this is the ACL:</p>
  
  <ul>
  <li>domain_frank\IT Team</li>
  <li>domain_bob\IT Team</li>
  <li>domain_frank\Dave</li>
  <li>domain_bob\Ted</li>
  </ul>
  
  <p>if you run it though the code above <code>output</code> would look like:</p>
  
  <pre><code>domain_frank\IT Team | S-1-5-21-4000000000-4000000000-2000000000-28480
  domain_frank\IT Team | S-1-5-21-1000000000-8000000000-3000000000-81912
  domain_frank\Dave | S-1-5-21-4000000000-4000000000-2000000000-86875
  domain_bob\Ted |  S-1-5-21-1000000000-8000000000-3000000000-96521
  </code></pre>
  
  <p>Assuming an object named Dave isn't in domain_bob and an object named Ted isn't in domain_frank.  But if you look at the SIDs, you can clearly see that the domain section is completely different so you know the correct object is in the ACL at least in SID.  Something to do with the look up is breaking.</p>
  
  <p>The result for me is I had to write my own algorithm to look at the SID and do an active directory look up on the domain the SID belongs to.  Very very slow, and a total pain.</p>
  
  <p>Is this a known bug and is there a satisfactory solution for this?</p>