Allow vs. Deny Permissions
When establishing permissions, you need to specify whether the entry should have access (Allow) or not have access (not Allow) to the resource.
After permissions have been set, the LSASS (Local Security Authority) controls access to the resource. LSASS compares the SID (Security ID) that you placed on the ACL (Access Control List) with the SID placed on the security access token that is given to the user at logon. If the SID associated with the user is on the ACL, the LSASS must determine whether the access is set to Allow or Deny. The Allow and Deny permissions inherit down through the structure.
Use the Deny permission sparingly, because of the fact that restrictive permissions override lenient permissions. It is more common to clear all the Allow check box for a group, thereby removing the group from the ACL.
This has the same result, giving no access to the resource. "Not-Allow" access in this way is easier to troubleshoot, manage and configure. It is easy to forget that you have used the Deny option.
You deny permissions (using explicit Deny) only to a specific user when it is necessary to override permissions that are otherwise allowed for the group to which this user belongs.
- NTFS Permissions
- Setting Permissions
- File and Folder Basic Permissions
- File and Folder Advanced Permissions
- Effective Permissions
- Changing Ownership of Files and Folders
- Moving and Copying Protected Files
- Troubleshooting Access to Files and Shared Folders
- Permissions for Other Objects
- User Rights vs. NTFS Permissions
- Share Permissions vs. NTFS Permissions
- Explicit vs. Inherited Permissions
- Allow vs. Deny Permissions
- Permission Precedence
- Combining Shared Folder Permissions and NTFS Permissions
- Sharing and Adding Permissions
- Backing up and Restoring NTFS Permissions on a Specified Volume
- Off-line Access to Shared Folders (Caching)
- Metafile $Secure
- Appendix. Script to Backup or Restore NTFS Permissions