SecurityIdentifier.Translate(typeof(NTaccount)) bugged?
Asked Answered
H

0

7

When doing a conversion from a SID to an NTAccount, I use the following 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();
}

Yes I realize you can get an NTAccount from from the folder_sec.GetAccessRules method but I have discovered that the same subroutine for SecurityIdentifier.Translate is being used and the same bug happens. At the end of the day, ACLs are just SID arrays.

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 translate 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 NTAccounts from other domains that don't happen to share the same name as another object in your domain return fine.

Say you have a directory on a machine that is in domain_frank and this is the ACL:

  • domain_frank\IT Team
  • domain_bob\IT Team
  • domain_frank\Dave
  • domain_bob\Ted

if you run it though the code above output would look like:

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

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.

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.

Is this a known bug and is there a satisfactory solution for this?

Hypochlorite answered 6/2, 2013 at 13:27 Comment(1)
Just to be clear. Which attribute is same for both the AD objects?Emergency

© 2022 - 2024 — McMap. All rights reserved.