search

raandree / NTFSSecurity

Managing permissions with PowerShell is only a bit easier than in VBS or the command line as there are no cmdlets for most day-to-day tasks like getting a permission report or adding permission to an item. PowerShell only offers Get-Acl and Set-Acl but everything in between getting and setting the ACL is missing. This module closes the gap.
MIT License
429 stars 59 forks source link

Add-NTFSAccess 1307 Error #34

Open deftleft opened 6 years ago

deftleft commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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] < notifications@github.com> 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 commented 6 years ago

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 commented 6 years ago

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] < notifications@github.com> 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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

tberta commented 1 year ago

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 commented 11 months ago

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 commented 11 months ago

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

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 commented 4 months ago

Hello!

Any news on that topic?