"Get-NTFSAccess -Path c:\" shows different results than Windows Explorer

[xenadmin]

I'm trying to alter the default permissions on a Windows RDSH server for multi-user environments. To automate that task I took a look at your project. For some strange reason the results from the command line are different to what I see in the properties of the c:\ drive.

Does someone know what this might be about?

(I know the text is in German, but it should be clear, that I'm missing "Authenticated User" ond the command line for example)

Get-NTFSAccess -Path c:\

    Path: C:\ (Inheritance enabled)

Account                             Access Rights                                        Applies to                Type                                                 IsInherited                                         InheritedFrom
-------                             -------------                                        ----------                ----                                                 -----------                                         -------------
Jeder                               Traverse, ReadAttributes, ReadPermissions, Synchr... ThisFolderOnly            Allow                                                False
NT-AUTORITÄT\EINGESCHRÄNKTER ZUG... Traverse, ReadAttributes, ReadPermissions, Synchr... ThisFolderOnly            Allow                                                False
NT-AUTORITÄT\SYSTEM                 FullControl                                          ThisFolderOnly            Allow                                                False
VORDEFINIERT\Administratoren        FullControl                                          ThisFolderOnly            Allow                                                False

[raandree]

Thanks, I can repro this (unfortunately). I will have a look into it...

[MightyMrMuesli]

I have two machines with variations of this bug with NTFSSecurity 4.2.6 under Windows Server 2016 1607 German. The buggy output only occurs on the top level of the drive:

Get-NTFSAccess -Path 'D:'

    Path: D:\ (Inheritance enabled)

Account                             Access Rights  Applies to                Type           IsInherited   InheritedFrom
-------                             -------------  ----------                ----           -----------   -------------
Jeder                               Traverse, R... ThisFolderOnly            Allow          False
NT-AUTORITÄT\EINGESCHRÄNKTER ZUG... Traverse, R... ThisFolderOnly            Allow          False
NT-AUTORITÄT\SYSTEM                 FullControl    ThisFolderOnly            Allow          False
VORDEFINIERT\Administratoren        FullControl    ThisFolderOnly            Allow          False

Get-Acl -Path 'D:'

    Verzeichnis:

Path Owner               Access
---- -----               ------
D:\  NT-AUTORITÄT\SYSTEM Jeder Allow  FullControl

Get-NTFSAccess -Path 'D:\Test'

    Path: D:\Test (Inheritance enabled)

Account                             Access Rights  Applies to                Type           IsInherited   InheritedFrom
-------                             -------------  ----------                ----           -----------   -------------
Jeder                               FullControl    ThisFolderSubfoldersAn... Allow          True          D:

On the second machine I don't even have access on the drive with commandlets from NTFSSecurity:

Get-NTFSAccess -Path 'D:'

Get-NTFSAccess : (5) Zugriff verweigert: [D:]
In Zeile:1 Zeichen:1
+ Get-NTFSAccess -Path 'D:'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (D::String) [Get-NTFSAccess], UnauthorizedAccessException
    + FullyQualifiedErrorId : ReadSecurityError,NTFSSecurity.GetAccess

Get-Acl -Path 'D:'

    Verzeichnis:

Path Owner               Access
---- -----               ------
D:\  NT-AUTORITÄT\SYSTEM Jeder Allow  FullControl

Subpaths return the correct ACEs.

Strangely the Get-Volume cmdlet also doesn't show the drive anymore when the NTFSSecurity module is imported. This can only be fixed by system reboot, simply logging out or restarting the PS session doesn't suffice. Other cmdlets like Get-ACL, Set-Location, etc. all keep working.

[SirWobbyTheFirst]

I've been looking into this issue myself. The output of Windows Explorer and ICACLS both match the ACL on the actual volume which is initialised to the following on volume creation:

But when you call Get-NTFSAccess you get an alternate value because NTFSSecurity is reading the ACL directly from the NT object itself and thus if you do any kind of *-NTFSAccess cmdlet against D:\ or C:\ you are working against the NT object which is initialised to the following during bootup:

@raandree - If you fire up a VM and assign an extra hard disk to it, format it as NTFS, Windows Explorer will show the first image as the ACL for the volume's ACL which is correct and then if you do ICACLS D:\ you will also get the same output as what Windows Explorer returns, but then if you run Get-NTFSAccess -Path "D:" will return the output of the second image.

Now if you install the WinObj application from Sysinternals and go to \GLOBAL??\D: and right-click the object and click Properties and go to the Security tab, you'll see the same ACL output as what Get-NTFSAccess returns.

@xenadmin - If you use the Administrative Shares on the RDSH server, you can still use Get-NTFSAccess and the other cmdlets to work with the permissions and it should provide a workaround whilst the module is updated. So it could be something like Get-NTFSAccess -Path "\rdshsrv01.domain.local\D$" and that will dump the same result as Windows Explorer and ICACLS will.

I hope this all helps.

[montereyharris]

Could be why I can't set ntfs audit permissions at the top level?