GetAccessControl error with NTAccount

Question

    private bool HasRights(FileSystemRights fileSystemRights_, string fileName_, bool isFile_)
    {
        bool hasRights = false;

        WindowsIdentity WinIdentity = System.Security.Principal.WindowsIdentity.GetCurrent();
        WindowsPrincipal WinPrincipal = new WindowsPrincipal(WinIdentity);

        AuthorizationRuleCollection arc = null;

        if (isFile_)
        {
            FileInfo fi = new FileInfo(@fileName_);
            arc = fi.GetAccessControl().GetAccessRules(true, true, typeof(NTAccount));
        }
        else
        {
            DirectoryInfo di = new DirectoryInfo(@fileName_);
            arc = di.GetAccessControl().GetAccessRules(true, true, typeof(NTAccount));
        }

        foreach (FileSystemAccessRule rule in arc)
        {
            if (WinPrincipal.IsInRole(rule.IdentityReference.Value))
            {
                if (((int)rule.FileSystemRights & (int)fileSystemRights_) > 0)
                {
                    if (rule.AccessControlType == AccessControlType.Allow)
                        hasRights = true;
                    else if (rule.AccessControlType == AccessControlType.Deny)
                    {
                        hasRights = false;
                        break;
                    }
                }
            }
        }

        return hasRights;
    }

The above code block is causing me problems. When the WinPrincipal.IsInRole(rule.IdentityReference.Value) is executed the following exception occurs:

"The trust relationship between the primary domain and the trusted domain failed.".

I'm very new to using identities, principles and such so I don't know what's the problem. I'm assuming it's with the use of NTAccount?

Thanks

Answer 1

I could try to address your question by suggesting you use a SecurityIdentifier, but there are many other issues here that would still be show-stoppers even if this were addressed. I'm not talking about inefficiencies such as using FileInfo instead of File, but the basic logic you're trying to use to interpret the DACL.

Take a look at: http://msdn.microsoft.com/en-us/library/cc230290(PROT.10).aspx