Fixing Permissions with NTFS intra-volume moves

This post discusses methods to automatically correct permission problems associated with moving data within a single NTFS volume in NTFS5.x - Windows 2000 and 2003 (and XP). Data secured with different ACLs on a single volume that is moved will normally result in incorrect permissions, as the data is re-linked in the MFT without taking into account permission inheritance.

This problem will occur if:

1. The user context that initiated the move - either locally or through a share - has the delete permission to the root directory object being moved and the right to create in the new location
2. The target location does not already contain a folder with the same name (if the folder does exist a copy/delete is performed rather than a move).

For example:

 

\\Server\Share\Folder1   - localA:C
\\Server\Share\Folder1\A - localA:C inherited from the root
\\Server\Share\Folder2   - localB:C
\\Server\Share\Folder2\B - localB:C inherited from the root

UserAB who has access to both Folder1 and Folder2, performs a drag and drop operation in explorer, with the source of Folder2\B and a drop-target of Folder1.

After the move, the permissions on \\Server\Share\Folder1\B are still inherited with access to localB, and no access to localA.

How to fix the problem

This can be fixed by using setacl or icacls to reset permission inheritance, or by using security templates to control permissions to the filesystem.

setacl

Reset permission inheritance:
setacl -on %Directory%\*.* -ot file -actn rstchldrn -rst DACL

setacl.exe is a very powerful permissions utility for reporting and modifying ACLs.

In the example above, to reset permissions inheritance for each folder:
for /d %i in (\\server\share\*) do echo setacl -on %i\*.* -ot file -actn rstchldrn -rst DACL

icacls

Reset permission inheritance:
icacls %Directory% /reset /T /C

In the example above, to reset permissions inheritance for each folder:
for /d %i in (\\server\share\*) do echo icacls %i /reset /T /C

icacls is a 2003 SP2 utility, but also runs on XP.

Security Templates

I find that security templates are an excellent method of managing permissions, as they provide:

• A repeatable method of applying permissions, great for fixing mistakes, DR, restore
• Accountability and change control - it's easy to see who made changes to a security template, and with templates rollback and change control is much easier
• Auditing - It's very simple to provide the results of the template to auditors showing your security structure

To reapply the security template, you could run (prefix with psexec to run remotely):
secedit /configure /db c:\windows\temp\%random%.sdb /cfg c:\windows\security\templates\ExampleTemplate.inf /log c:\windows\temp\example.log

Note that for this to reset inheritance, each security template entry must use 2 in the second field, which directs secedit to overwrite existing explicit ACEs, a by-product of which is that inherited ACLs are reset on child objects. If you use a second column of 0 - to merge the results, the incorrectly set inherited ACL is not reset on the child objects.

If you had a security template managing permissions to the example above, it would look something like:

 

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1

[Profile Description]
Description=Example Template

[File Security]
;Set security for Folder1
"D:\Share\Folder1",2,"D:AR(A;OICI;FA;;;BA)(A;OICI;0x1301bf;;;S-1-5-21-129063155-272689390-804422213-3709)(A;OICI;FA;;;SY)"
"D:\Share\Folder2",2,"D:AR(A;OICI;FA;;;BA)(A;OICI;0x1301bf;;;S-1-5-21-129063155-272689390-804422213-3710)(A;OICI;FA;;;SY)"

How to identify the problem

Below is a rather inefficient and simple PowerShell script that will report directories that have inherited ACLs that don't match the parent directory. I'm sure there are better ways to do this, but secedit /analyze doesn't do it and while I started off parsing cacls /S and setacl output with a VBScript, I think the PowerShell script is at least better than that. It works only for simple permission structures, ie you’ve set permissions at the root of somewhere and expecting them to inherit all the way to the end.

I say the script is quite inefficient in that even though I'm filtering the output of get-childitem in the resulting array to return only directories, I believe it still processes all files and directories. And then for each directory I'm finding the parent and checking the ACLs - where it would be more efficient to find the parent and then process all directories directly under the parent before recursing.

Anyway, once you've found the directories, you can often use 'dir /q' to report the new owner, which in testing I've done is set at the person doing the move on the new root folder object.

Note that these permissions problems can occur with files, but the script below only checks directories (because it seemed overkill to check each file when there could be millions, plus it's quite plausible that directory ACLs don't match file ACLs).

Output based on the example above:
PS C:> . .\CheckInheritedSecurity.ps1 -p D:\Share
The ACE for 'TEST\wm' on 'D:\Share\Folder1\B' is marked as inherited but doesn't appear to have been inherited directly from the parent directory

 

$root = ""

if ($args.count -eq 2) {
  for ($i = 0; $i -le $args.count-1; $i+=2) {
    if ($args[$i].ToLower().Contains("-p")) {
      $root = $args[$i+1]
    }
  }
}

if ($root -eq "") {
  write-output "Please specify a root directory to begin the search"
  exit 2
}

$rootSubDirs = get-childitem $root  where{$_.PSIsContainer}

foreach ($tld in $rootSubDirs)
{
  $objects = $null
  $objects = get-childitem $tld.FullName -Recurse  where{$_.PSIsContainer}

  foreach ($object in $objects)
  {
    if ($object -is [System.IO.DirectoryInfo])
    {
      $FullName = $object.FullName
      $acl = get-acl -path $FullName
      $accessRules = $acl.GetAccessRules($false, $true, [System.Security.Principal.NTAccount])      # Report only inherited, as NTAccount (not SIDs)

      $parent = $object.Parent
      $parentFullName = $parent.FullName
      $parentacl = get-acl -path $parent.FullName

      $ParentAccessRules = $parentacl.GetAccessRules($true, $true, [System.Security.Principal.NTAccount])      # Report explicit and inherited, as NTAccount (not SIDs)

      #write-output ($object.fullname + ", child of " + $parent.FullName)

      foreach ($accessRule in $accessRules)
      {
        $InheritedFromParent = $false

        foreach ($parentAccessRule in $ParentAccessRules)
        {
          if ($accessRule.IdentityReference -eq $parentAccessRule.IdentityReference) { $InheritedFromParent = $true }
        }

        if (!$InheritedFromParent)
        {
          $identity = $AccessRule.IdentityReference.ToString()
          write-output ("The ACE for '$identity' on '$FullName' is marked as inherited but doesn't appear to have been inherited directly from the parent directory")
        }
   
      }
    }
  }
}

exit 0

References:

SetACL
http://setacl.sourceforge.net/

SDDL syntax in secedit security templates
http://waynes-world-it.blogspot.com/2008/03/sddl-syntax-in-secedit-security.html

Create or modify a security template for NTFS permissions
http://waynes-world-it.blogspot.com/2008/03/create-or-modify-security-template-for.html

Useful NTFS and security command-line operations
http://waynes-world-it.blogspot.com/2008/06/useful-ntfs-and-security-command-line.html

Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.