Powershell Set-Acl: an exception of type system.security.principal.identitynotmappedexception was thrown

calendar Nov 4, 2022 · 3 min read · Powershell

I have this short little PowerShell function that I use all over the place. It simply adds an ACL entry to an object, usually a network folder:

 1function AddNTFSPermissions($path, $object, $permission) {
 2  $FileSystemRights = [System.Security.AccessControl.FileSystemRights]$permission
 3  $InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]'ContainerInherit, ObjectInherit'
 4  $PropagationFlag = [System.Security.AccessControl.PropagationFlags]'None'
 5  $AccessControlType = [System.Security.AccessControl.AccessControlType]::Allow
 6  $Account = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList ($object)
 7  $FileSystemAccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList ($Account, $FileSystemRights, $InheritanceFlag, $PropagationFlag, $AccessControlType)
 8  $DirectorySecurity = Get-Acl $path
 9  $DirectorySecurity.AddAccessRule($FileSystemAccessRule)
10  Set-Acl $path -AclObject $DirectorySecurity
11}

I didn't write this function .. it came from the depths of the internet early on as I was learning PowerShell and using it for all my bits of automation.

And it's generally been working fine, until someone today noticed that some permissions weren't getting set.

We'd recently changed the account that this automation ran as to not be a Domain Administrator, instead opting for very specific permissions to specific locations. How very secure.

This automation runs under a gMSA - an account managed by the directory. In most other places where we use gMSA's, we don't see system.security.principal.identitynotmappedexception exceptions, however saying that, this particular script's job is to manage permissions on a whole directory of directories...

But why the failures?

And why only on this paricular folder, when other folders in the same directory tree weren't failing?

Running this script as my account, everything executed correctly. So it seemed that there's some permission that the service account was lacking. Not really certain where to go to find the specific permission (and not really wanting to grant more rights to this service account than necessary), it was time to dig into the specific folders.

Turns out that Set-Acl also tries to translate the owner field of an object. In my case, the owner property for the specific object was from a user no longer in the directory:

Unresolvable SID

Change the owner property to an account that does resolve, and success.

I updated my AddNTFSPermissions to log the error when it fails:

 1function AddNTFSPermissions($path, $object, $permission) {
 2    $OldErrorAction = $ErrorActionPreference
 3    $ErrorActionPreference = "Stop"
 4    try {
 5        $FileSystemRights = [System.Security.AccessControl.FileSystemRights]$permission
 6        $InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]'ContainerInherit, ObjectInherit'
 7        $PropagationFlag = [System.Security.AccessControl.PropagationFlags]'None'
 8        $AccessControlType = [System.Security.AccessControl.AccessControlType]::Allow
 9        $Account = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList ($object)
10        $FileSystemAccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList ($Account, $FileSystemRights, $InheritanceFlag, $PropagationFlag, $AccessControlType)
11        $DirectorySecurity = Get-Acl $path
12        $DirectorySecurity.AddAccessRule($FileSystemAccessRule)
13        Set-Acl $path -AclObject $DirectorySecurity
14    } catch {
15        $logger.Error("An exception was surfaced adding NTFS permissions. You need to correct the folder owner permissions for $($path)")
16        $logger.debug($Account)
17    } finally {
18        $ErrorActionPreference = $OldErrorAction
19    }
20}

Note: $logger is an nLog object that I've used elsewhere in the script (this gist gives a really rough idea of how to wire that up).

Next step is to automate the fix (which is on the todo list). A few resources for that solution: