asked on 'Access denied' when permission applied via ICACLS; no problem when applied via GUI
Hi, I have a Windows 2012 R2 file server that's showing some odd behaviour. I need to apply an NTFS permission to a bunch of folders so I would prefer to do it via a script than via the GUI.
The permission is: Deny, Domain Users, Delete, This Folder Only.
I can apply the permission to the folder using the GUI (Advanced Security Settings) with no problems.
However, when I apply the permission using ICACLS, suddenly everybody in Domain Users gets an 'Access is denied' error when they try to open the folder!
The ICACLS command I'm using is ICACLS "<foldername>" /deny "Domain Users":(d)
The ICACLS command executes successfully, and when I check the folder permissions in the GUI afterwards, they look identical to how they look when I use the GUI to add the permission.
I even ran an NTFS permissions report on the folder when the permission is set via GUI and another when it's set via ICACLS. I compared the two permissions reports in Excel, and the reports are completely identical (apart from the cell containing with the report date and time of course).
So why on earth is it that the domain users have no problem opening the folder when it's set via GUI, but get 'Access Denied' when it's set via ICACLS?? I'm mystified. So is Dr Google. Has anyone else encountered this behaviour after using ICACLS? How can I fix the problem? I don't want to have to use the GUI - I need to add the permission to dozens of folders. It would take ages.
Any suggestions welcome. Thank you! :)
The permission is: Deny, Domain Users, Delete, This Folder Only.
I can apply the permission to the folder using the GUI (Advanced Security Settings) with no problems.
However, when I apply the permission using ICACLS, suddenly everybody in Domain Users gets an 'Access is denied' error when they try to open the folder!
The ICACLS command I'm using is ICACLS "<foldername>" /deny "Domain Users":(d)
The ICACLS command executes successfully, and when I check the folder permissions in the GUI afterwards, they look identical to how they look when I use the GUI to add the permission.
I even ran an NTFS permissions report on the folder when the permission is set via GUI and another when it's set via ICACLS. I compared the two permissions reports in Excel, and the reports are completely identical (apart from the cell containing with the report date and time of course).
So why on earth is it that the domain users have no problem opening the folder when it's set via GUI, but get 'Access Denied' when it's set via ICACLS?? I'm mystified. So is Dr Google. Has anyone else encountered this behaviour after using ICACLS? How can I fix the problem? I don't want to have to use the GUI - I need to add the permission to dozens of folders. It would take ages.
Any suggestions welcome. Thank you! :)
* NTFSSecurity
Last Comment
vistamed
ASKER
Hi Arnold,
I have UAC disabled so I am always running on elevated rights.
The /e option you mention is not included in ICACLS. I had a look at XCACLS but it doesn't work on Server 2012.
Instead I tried a program called SetACL and used it to compare the permissions for the folder in the two situations (set-by-GUI and set-by-icacls).
The permissions were completely identical when SetACL reported them in tabular or CSV (i.e. human-readable) format. But finally I found a difference when I asked SetACL to report the results in SDDL format (SDDL is 'Security Descriptor Definition Language')
Remember, the intended permission is Deny, Domain Users, Delete, This Folder Only.
Here is the permission when set via GUI:
(D;;SD;;;DU)
And here is the permission when set via ICACLS:
(D;;0x110000;;;DU)
From reading up on SDDL, I know that the icacls command has set Bit 16 and Bit 20 of the permissions list.
Bit 16 is the bit I want to set - it's the 'Delete' permission bit.
So the problem must be due to icacls setting Bit 20 as well.
Unfortunately I can't find any information on what Bit 20 does.
So why is icacls setting this mysterious Bit 20? And how do I make it stop?
(tomorrow I am going to try using SetACL to set the permission. If it succeeds then I'll use it in future and let icacls take a running jump. I'll keep you updated.
Thanks!
I have UAC disabled so I am always running on elevated rights.
The /e option you mention is not included in ICACLS. I had a look at XCACLS but it doesn't work on Server 2012.
Instead I tried a program called SetACL and used it to compare the permissions for the folder in the two situations (set-by-GUI and set-by-icacls).
The permissions were completely identical when SetACL reported them in tabular or CSV (i.e. human-readable) format. But finally I found a difference when I asked SetACL to report the results in SDDL format (SDDL is 'Security Descriptor Definition Language')
Remember, the intended permission is Deny, Domain Users, Delete, This Folder Only.
Here is the permission when set via GUI:
(D;;SD;;;DU)
And here is the permission when set via ICACLS:
(D;;0x110000;;;DU)
From reading up on SDDL, I know that the icacls command has set Bit 16 and Bit 20 of the permissions list.
Bit 16 is the bit I want to set - it's the 'Delete' permission bit.
So the problem must be due to icacls setting Bit 20 as well.
Unfortunately I can't find any information on what Bit 20 does.
So why is icacls setting this mysterious Bit 20? And how do I make it stop?
(tomorrow I am going to try using SetACL to set the permission. If it succeeds then I'll use it in future and let icacls take a running jump. I'll keep you updated.
Thanks!
It looks as though when used via icacls the "Domain Users" is not properly translated to the SID for the group....
you could try
use icacls <directory> of the one you change with icacls and the GUI.
icacls directory /Deny "addomain\Users":(D)
and see if it replicates the settings as would have been set by GUI?
you could try
use icacls <directory> of the one you change with icacls and the GUI.
icacls directory /Deny "addomain\Users":(D)
and see if it replicates the settings as would have been set by GUI?
ASKER
Hi Arnold, no it's translating the Domain Users part correctly. That's the 'DU' part at the end of the SDDL permission, i.e.
(D;;0x110000;;;DU)
It's the actual permissions bits that icacls is screwing up somehow.
It should be setting (D;;SD;;;DU) rather than (D;;0x110000;;;DU)
(D;;0x110000;;;DU)
It's the actual permissions bits that icacls is screwing up somehow.
It should be setting (D;;SD;;;DU) rather than (D;;0x110000;;;DU)
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Figured it out in the end!
Deny is overriding, supersedes all other settings,
I think your issue is that you are missing the /e option that deals/sets that you are editing the file ACL versus creating a new based on the parameters you provide on the command line.
Run icacls folder to see the permissions after your change.
Xcacls has a more granular control...
Double check the application of your restrictions....