-
-
Notifications
You must be signed in to change notification settings - Fork 58
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.
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
Effective Access results differ from the Explorer GUI #45
Comments
Thanks @mwtrigg. I have just tried to repo it and created a share on a Windows File Server. The Windows Explorer shows the effective access like this: In my case, the cmdlet returns the effective access like expected. PS C:\> Get-NTFSEffectiveAccess \\dscpull01\test\Test1\ -Account contoso\User1 | fl *
AccountType : user
Name :
FullName : \\dscpull01\test\Test1\
InheritanceEnabled : False
InheritedFrom :
AccessControlType : Allow
AccessRights : ReadAndExecute, Synchronize
Account : contoso\User1
InheritanceFlags : None
IsInherited : False
PropagationFlags : None Am I doing something wrong reproducing your issue? |
@mwtrigg, I do not see the error in the Windows Explorer dialog. It the Windows Explorer really showing the right result? |
The error in Windows explorer is because I was running effective permissions on a remote file share as I had stated above. That is the standard message when doing so; the warning is only really relevant if remote local groups are in use in the SACL The Effective permissions reported in the GUI are correct, my user account has no access to that share. Can you reproduce the results if the user in question has no access to the share? |
I have removed all permissions expect for SYSTEM
Get-NTFSEffectiveAccess shows me that User1 has only the synchronize right.
|
When querying effective permissions using the Get-NTFSEffectiveAccess function the results displayed for a particular account differ from those displayed when running the graphical tool in Windows Explorer.
This occurs when checking permissions over a UNC path (have not checked locally), through a DFS namespace, directly to a Windows CIFS share, and to a CIFS share hosted on a NetApp CIFS server.
Running NTFSSecurity 4.2.4
The text was updated successfully, but these errors were encountered: