Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add-NTFSAccess 1307 Error #34

Open
deftleft opened this issue Aug 3, 2018 · 23 comments
Open

Add-NTFSAccess 1307 Error #34

deftleft opened this issue Aug 3, 2018 · 23 comments
Assignees
@raandree
Labels
Bug Clearly a bug that need to be fixed

Comments

@deftleft
Copy link

deftleft commented Aug 3, 2018

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 raandree self-assigned this Aug 7, 2018
@raandree
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

deftleft commented Aug 16, 2018 via email

@raandree
Copy link
Owner

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
Copy link
Author

deftleft commented Aug 18, 2018 via email

@dt1ll0ts0n
Copy link

dt1ll0ts0n commented Sep 5, 2018 •
edited
Loading

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
Copy link

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
Copy link
Owner

@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!

@raandree raandree added Bug Clearly a bug that need to be fixed Help Wanted We need help from the community to get the fixed or added labels Jul 25, 2019
@Sup3rlativ3
Copy link

@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
Copy link

Bi00 commented Oct 2, 2019 •
edited
Loading

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
Copy link

Marc408 commented Jan 29, 2020

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
Copy link

jcardel commented Jan 30, 2020

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
Copy link

Marc408 commented Jan 30, 2020

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
Copy link

jcardel commented Jan 30, 2020

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
Copy link

Kluk commented Aug 3, 2020

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
Copy link

Kluk commented Aug 3, 2020

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
Copy link

agonzalezm commented Oct 26, 2020 •
edited
Loading

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
Copy link

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

@tberta
Copy link

tberta commented May 25, 2023 •
edited
Loading

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:
Process monitor - icacls

Only DACL is set:
Process monitor icacls Details

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

Several Security Informations are tentively written : Owner, Group, DACL and DACL Protected.
Process monitor Add-NTFSAccess Details

@raandree
Copy link
Owner

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.

@raandree raandree removed the Help Wanted We need help from the community to get the fixed or added label Nov 28, 2023
@jcardel
Copy link

jcardel commented Nov 29, 2023 via email

@sarge232
Copy link

Hello!

Any news on that topic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@raandree raandree

Labels
Bug Clearly a bug that need to be fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests