Add-NTFSAccess 1307 Error

[deftleft]

Recently started getting 1307 error Add-NTFSAccess : (1307) This security ID may not be assigned as the owner of this object: When trying to add BUILTIN\Administrators group permissions on a NetApp Folder.

The folder is owned by BUILTIN\Administrators and my AD user account is a member of the group.

I was able to use ICACLS to grant BUILTIN\Administrators permissions to the folder.

[raandree]

Do you work on a nun en-us workstation? Meaning, does the BUILTIN\Administrators group has a different name on the machine the code runs on?

[deftleft]

I work on en-us only software versions supporting the US Army. We have a mixture of Windows 10 1607 and 1709 versions in our organization. The NetApp operating system is Clustered Data ONTAP 9.3P6.

[raandree]

What NTFSSecurty does internally is to convert the username into an object of type[Security2.IdentityReference2] that stores the username plus the SID. Does the following command work when hitting the error?

PS C:\> [Security2.IdentityReference2]'BUILTIN\Administrators'

Sid          AccountName            LastError
---          -----------            ---------
S-1-5-32-544 BUILTIN\Administrators

Security2.IdentityReference2 is a non-standard class coming with NTFSSecurity. Internally it uses the .net standard class System.Security.Principal.NTAccount and System.Security.Principal.SecurityIdentifier.

PS C:\> $p = [System.Security.Principal.NTAccount]'BUILTIN\Administrators'
PS C:\> $p.Translate([System.Security.Principal.SecurityIdentifier])

BinaryLength AccountDomainSid Value
------------ ---------------- -----
          16                  S-1-5-32-544

Do you observe the error only when working on a NetApp volume or can you repro the issue also on a local drive?

[deftleft]

The commands you sent both work without any errors and produce the same SID values. I cannot reproduce the error on a local drive. The error only happens when the path is "\netappfiler\sharename\folder"

icacls works using the same path "\netappfiler\sharename\folder" without any errors.

On Thu, Aug 16, 2018 at 4:10 AM Raimund Andrée [MSFT] < [email protected]> wrote:

What NTFSSecurty does internally is to convert the username into an object of type[Security2.IdentityReference2] that stores the username plus the SID. Does the following command work when hitting the error?

PS C:> [Security2.IdentityReference2]'BUILTIN\Administrators'

Sid AccountName LastError

---

S-1-5-32-544 BUILTIN\Administrators

Security2.IdentityReference2 is a non-standard class coming with NTFSSecurity. Internally it uses the .net standard class System.Security.Principal.NTAccount and System.Security.Principal.SecurityIdentifier.

PS C:> $p = [System.Security.Principal.NTAccount]'BUILTIN\Administrators' PS C:> $p.Translate([System.Security.Principal.SecurityIdentifier])

BinaryLength AccountDomainSid Value

---

      16                  S-1-5-32-544

Do you observe the error only when working on a NetApp volume or can you repro the issue also on a local drive?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raandree/NTFSSecurity/issues/34#issuecomment-413509110, or mute the thread https://github.com/notifications/unsubscribe-auth/AoEjPezR2X8W4aXkAWrUcu_YWBb10R3sks5uRVMKgaJpZM4VuSr5 .

[raandree]

I am unable to repro this, I do not have access to a NetApp filer. I can add additional debug logging to the cmdlets to help tackle this. Would you mind investing a little bit more time?

[deftleft]

Yes I am willing to help if you send my a build that includes logging.

On Fri, Aug 17, 2018 at 12:19 PM Raimund Andrée [MSFT] < [email protected]> wrote:

I am unable to repro this, I do not have access to a NetApp filer. I can add additional debug logging to the cmdlets to help tackle this. Would you mind investing a little bit more time?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raandree/NTFSSecurity/issues/34#issuecomment-413964396, or mute the thread https://github.com/notifications/unsubscribe-auth/AoEjPU3aiqjWr_Jtqwtv9n-4gDZ-3H7Aks5uRxdfgaJpZM4VuSr5 .

[dt1ll0ts0n]

Hello! I'm also getting a 1307 error when I try to add NTFS permissions. I use UNC paths (anything that starts with \\ ). I run windows 10 1709, en-us only.

I'm willing to help investigate, too, as this has been such a useful tool.

[FrisbeeGolfer]

I'm having this same issue with all builds from version 4.0 up. I had to go back to a manual install of 3.2.3 to resolve the issue. We have a very standard enterprise all-Microsoft environment for our file shares. Servers are 2012 R2 running DFS namespaces and DFS replication. The service account used for these operations has full control access to all shares, both SMB and NTFS. It is not an admin on the file server and is not an admin on the task server from which it runs, as neither of those are necessary for these operations.

As others have said, I also greatly appreciate your development efforts on this wonderful module and I would be willing to help troubleshoot if you would like me to try a build with enhanced logging or other changes. I'll have to stick with a manual install of 3.2.3 for now and hope it doesn't break at some point. Thanks!

[raandree]

@Sup3rlativ3, I have received your commend to that issue by email but do not see it here. @FrisbeeGolfer, sorry for catching up quite late with this.

NTFSSecurity just uses the standard .net methods to do the name translation (SID<>SamAccountName). If this happens again, can you please try the following in PowerShell to verify that?

If the error occurs again, you should see something similar to this:

PS C:\> Add-NTFSAccess -Path D:\ -Account raandree1\DoesNotExist -AccessRights FullControl                                                                   Add-NTFSAccess : Cannot bind parameter 'Account'. Cannot convert value "raandree1\DoesNotExist" to type "Security2.IdentityReference2". Error: "Some or all
identity references could not be translated."
At line:1 char:35
+ Add-NTFSAccess -Path D:\ -Account raandree1\DoesNotExist -AccessRight ...
+                                   ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Add-NTFSAccess], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,NTFSSecurity.AddAccess

You should see the same error when calling the name translation method directly:

PS C:\> [Security2.IdentityReference2]'raandree1\DoesNotExist'                                                                                               Cannot convert value "raandree1\DoesNotExist" to type "Security2.IdentityReference2". Error: "Some or all identity references could not be translated."
At line:1 char:1
+ [Security2.IdentityReference2]'raandree1\DoesNotExist'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvalidCastConstructorException

If the account exists, it returns an object containing the SID and the account name:

PS C:\> [Security2.IdentityReference2]'raandree1\randr'                                                                                                      
Sid                                            AccountName     LastError
---                                            -----------     ---------
S-1-5-21-4243879168-3157639941-1836938273-1001 raandree1\randr

Thanks for any help troubleshooting this!

[Sup3rlativ3]

@raandree I withdrew the comment as I found I had made a mistake and that was the cause of the error. I didn't want to muddy the waters with an incorrect report.

[Bi00]

I have the same problem. Also NetApp filer. But with DFS pointing to filer. Setting rights for any account by an user who has full control

[Marc408]

Trying to use Add-Ntfsaccess yields the same error for me. Also NetApp with DFS in front. The module has worked for me in the past, feels bad having to fall back to icacls

[jcardel]

Trying to use Add-Ntfsaccess yields the same error for me. Also NetApp with DFS in front. The module has worked for me in the past, feels bad having to fall back to icacls

Have you tried making a share on the filer, with root access, and using that to set security? I have had similar issues with an emc filer back a few years ago, and making a share on top level with "run as root", and a group added there with my admin group in.. I can "Set-NTFSOwner", and "Set-Acl -InputObject" without problems, before those 2 things was not possible, over dfs, or the standard share the dfs was pointing too, which is the same thing.

[Marc408]

It works when the running account is the owner of the file, but taking ownership is a bit of an annoyance in most of my cases

[jcardel]

It works when the running account is the owner of the file, but taking ownership is a bit of an annoyance in most of my cases

        Set-NTFSOwner -Path "\\<unc>\datar$\Users\au$auid" -Account "UNI\$accountname"
        Add-NTFSAccess -Path "\\<unc>\datar$\Users\au$auid" -Account "UNI\$accountname" -AccessRights Modify -InheritanceFlags ObjectInherit,ContainerInherit
        Add-NTFSAccess -Path "\\<unc>\datar$\Users\au$auid" -Account "Owner Rights" -AccessRights Modify

This snip from my "user folder creation script" always works, but the share i am accessing this through is an extra one (with the added "r") with only this purpose and "root access". I would recommend you using something a like this (Owner Rights), then users can never mess with the security or anything else really, which is a desired configuration.

[Kluk]

I had the same issue but I was able to fix it, or more by-passing it.

Here is a part of my code. Add-NTFSAccess was generating this error 1307. I wrote the script but I'm not the one actually using it. I don't have enough permissions on servers. So it was difficult to reproduce. I only use literal paths as we need to handle long paths.

Get-Item -LiteralPath (Rename-Path $path) | Get-NTFSAccess | Where-Object { ($_.AccessRights -like '*Modify*') -and ($_.AccessControlType -eq 'Allow') } | Remove-NTFSAccess
	
Write-Host 'Adding read permission(s)...' -Foregroundcolor Yellow 
Add-NTFSAccess -Path (Rename-Path $path) -Account $entries.SID -AccessRights Read -AccessType Allow

Rename-Path function add a prefix to the path as we use extented-length path with the \\?\ prefix. For a network path, the prefix must be \\?\UNC\server\share. For a local path, it's \\?\C:\folder. So, Rename-Path does that. Since I use it, I get this error 1307 only with network paths and with a few AD accounts. I replaced the last line with this: Get-Item -LiteralPath (Rename-Path $path) | Add-NTFSAccess -Account $entries.SID -AccessRights Read -AccessType Allow And now, the error is gone and the script works well. Could someone test this?

[Kluk]

So, the problem was not what I explained in my previous comment at all. The guy who tested the script just didn't run it as admin. But it works with admin rights and he is server admin. So the issue is probably related to privileges.

[agonzalezm]

i am having same problem on windows server 2019 i cant resolve a user/group from the domain but it work with local users, any idea?

If I get the effective permissions from properties-security-advanced window it works for the domain group also.

Local users ok

PS C:\Shares\repo1\manyfolders> Get-NTFSEffectiveAccess -Path c:\shares\repo1 -Account "builtin\administrators"


    Path: c:\shares\repo1 (Inheritance disabled)


Account                             Access Rights  Applies to                Type           IsInherited   InheritedFrom
-------                             -------------  ----------                ----           -----------   -------------
BUILTIN\Administrators              FullControl    ThisFolderOnly            Allow          False


PS C:\Shares\repo1\manyfolders> [Security2.IdentityReference2]'BUILTIN\Administrators'

Sid          AccountName            LastError
---          -----------            ---------
S-1-5-32-544 BUILTIN\Administrators

domain users: ERROR

PS C:\Shares\repo1\manyfolders> Get-NTFSEffectiveAccess -Path c:\shares\repo1 -Account domain\developers
Get-NTFSEffectiveAccess : Cannot bind parameter 'Account'. Cannot convert value "developers" to type
"Security2.IdentityReference2". Error: "Some or all identity references could not be translated."
At line:1 char:56
+ ... -NTFSEffectiveAccess -Path c:\shares\repo1 -Account developers
+                                                         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Get-NTFSEffectiveAccess], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,NTFSSecurity.GetEffectiveAccess


PS C:\Shares\repo1\manyfolders> [Security2.IdentityReference2]'domain\developers'
Cannot convert value "domain\developers" to type "Security2.IdentityReference2". Error: "Some or all identity
references could not be translated."
At line:1 char:1
+ [Security2.IdentityReference2]'domain\developers'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvalidCastConstructorException

[Sup3rlativ3]

@agonzalezm are you running this elevated e.g. "as admin"?

[tberta]

I encounter the same problem when I try to change some permissions on a folder located on an SMB share on an EMC NAS. I don't have local administrator rights on the EMC NAS hosting the share. However, I have full control of the target folder with an existing "Full Control" ACL entry.

No issue with the translation to SID:

PS Z:\> $p = [System.Security.Principal.NTAccount]'Domain\John.Die'
PS Z:\> $p.Translate([System.Security.Principal.SecurityIdentifier])

BinaryLength AccountDomainSid                       Value
------------ ----------------                       -----
          28 S-1-5-21-448539723-790525478-<snip> S-1-5-21-448539723-79052...

But setting right failed on "This security ID may not be assigned as the owner of this object"

PS Z:\> Add-NTFSAccess -Path $path -Account $account -AccessRights Modify -InheritanceFlags ObjectInherit,ContainerInherit
Add-NTFSAccess : (1307) This security ID may not be assigned as the owner of this object: [z:\John.Die]
At line:1 char:1
+ Add-NTFSAccess -Path $path -Account $account -AccessRights Modify -In ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (z:\John.Die:String) [Add-NTFSAccess
   ], IOException
    + FullyQualifiedErrorId : AddAceError,NTFSSecurity.AddAccess

PS Z:\> get-module ntfssecurity

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     4.2.6      NTFSSecurity                        {Add-NTFSAccess, A...

The same operation with icacls.exe succeed.

When observing with Process Monitor, we see that Add-NTFSAccess try to write Owner and not only the requested DACL. See Process monitor screenshots comparing icacls.exe and Add-NTFSAccess

icacls operation succeed:

Only DACL is set:

Add-NTFSAccess captured with Process Monitor while failing to add modify rights:

Several Security Informations are tentively written : Owner, Group, DACL and DACL Protected.

[raandree]

Thanks for reporting the issue and for the patience. Finally, I have reproduced the issue together with a customer. In fact, the error is more basic than expected and happens if the user running the cmdlet is not a local administrator / does not have the backup and restore privilege. I am working on a fix.

[jcardel]

Regarding this: "I encounter the same problem when I try to change some permissions on a folder located on an SMB share on an EMC NAS. I don't have local administrator rights on the EMC NAS hosting the share. However, I have full control on the targeted folder."

I have an EMC NAS too, and have been using this module for about 10 years. The only way to set "OWNER" and permissions on the root folder, is that it is allowed in the share options, and you need local root. I have an extra share, where my admin account impersonates root, only way to set OWNER. All other permissions, I have no issue applying over SMB. Like this: [cid:1c4b9bfa-3c77-4229-ab22-4433f6f623c6] I wonder if this "fix" will address this specificly or not.

Med venlig hilsen / Best regards

|--Johan Cardel

--Storage admin

---

Fra: tberta @.> Sendt: 25. maj 2023 18:09 Til: raandree/NTFSSecurity @.> Cc: Johan Cardel @.>; Comment @.> Emne: Re: [raandree/NTFSSecurity] Add-NTFSAccess 1307 Error (#34)

I encounter the same problem when I try to change some permissions on a folder located on an SMB share on an EMC NAS. I don't have local administrator rights on the EMC NAS hosting the share. However, I have full control on the targeted folder.

No issue with the translation to SID:

PS Z:> $p = [System.Security.Principal.NTAccount]'Domain\John.Die' PS Z:> $p.Translate([System.Security.Principal.SecurityIdentifier])

BinaryLength AccountDomainSid Value

---

      28 S-1-5-21-448539723-790525478-<snip> S-1-5-21-448539723-79052...

But setting right failed on "This security ID may not be assigned as the owner of this object"

PS Z:> PS Z:> Add-NTFSAccess -Path $path -Account $account -AccessRights Modify -InheritanceFlags ObjectInherit,ContainerInherit Add-NTFSAccess : (1307) This security ID may not be assigned as the owner of this object: [z:\John.Die] At line:1 char:1

• Add-NTFSAccess -Path $path -Account $account -AccessRights Modify -In ...

•   + CategoryInfo          : WriteError: (z:\John.Die:String) [Add-NTFSAccess
   ], IOException
    + FullyQualifiedErrorId : AddAceError,NTFSSecurity.AddAccess
  
  

PS Z:> get-module ntfssecurity

ModuleType Version Name ExportedCommands

---

Script 4.2.6 NTFSSecurity {Add-NTFSAccess, A...

The same operation with icacls.exe succeed.

When observing with Process Monitor, we see that Add-NTFSAccess try to write Owner and not only the requested DACL. See Process monitor screenshots comparing icacls.exe and Add-NTFSAccess

[Process monitor - icacls]https://user-images.githubusercontent.com/29402410/240972439-979c1a90-a445-40f3-af71-1c8187733182.png

[Process monitor icacls Details]https://user-images.githubusercontent.com/29402410/240972447-560de5e1-a7d5-4712-b46f-1f3b2d428ffb.png

[Process monitor Add-NTFSAccess]https://user-images.githubusercontent.com/29402410/240972457-e09dab67-7060-4662-a26b-19b33dca7f3c.png [Process monitor Add-NTFSAccess Details]https://user-images.githubusercontent.com/29402410/240972455-6014dd19-7c4b-4d25-a0aa-803e0bb03d9e.png

— Reply to this email directly, view it on GitHubhttps://github.com/raandree/NTFSSecurity/issues/34#issuecomment-1563165287, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFICQW5IVWWNSD2B2HLM4PLXH575JANCNFSM4FNZFL4Q. You are receiving this because you commented.Message ID: @.***>

[sarge232]

Hello!

Any news on that topic?