NTFS Permissions Management Best Practices

Configuring NTFS Permissions

• Create a file server permissions policy that clearly defines your permissions management process.
• Use Active Directory groups everywhere. Don't assign NTFS permissions to individuals, even if you have to create hundreds of groups. It's far easier to manage 200 groups than 2,000 one-off permissions.
• Configure NTFS permissions for the assets, assign roles to those permissions, and assign people to roles. For example, suppose you have a share named HR on fileserver1. Do the following:

1. For this share, create the following domain local groups in your AD with the permissions shown:
   • fileserver1_HR_read (Read-only)
   • fileserver1_HR_modify (Read and Modify)
   • fileserver1_HR_fullcontrol (Full Control)
2. Use these groups to set NTFS permissions to the appropriate user rights.
3. Create a global group in AD named HR for your HR people. Add this global group to the domain local group fileserver1_HR_read, and then add user accounts to the global group HR. What you have now done is tied an asset to a permission, and the permissions to a role. As you expand your network and add different assets and areas of access to the role, you'll be able to easily see what assets a role can access.

People (user accounts) -> Role (AD global group) -> Permissions (AD domain local group) -> Asset (file or folder on a file server)

• Avoid giving users the Full Control permission. Full Control enables users to change NTFS permissions, which average users should not need to do. Modify rights should be all that's necessary for most users.
• Assign the most restrictive permissions that still allow users to perform their jobs. For example, if users need only to read information in a folder and not to change, delete or create files, assign the Read permission only.
• Remove the Everyone permission from every resource except the global folder designated for file exchanges.
• Create a Global Deny group so that when employees leave the company, you can quickly remove all their file server access by making them members of that group.
• Avoid breaking permissions inheritance as much as possible. There will be a few folders where this may be necessary, but generally avoid it. If something would break inheritance, then it either needs to move up a level or you need to reassess who's got what permissions on the parent folder. For example, if a you need to give someone Read/Write permissions for all of the \Finance folder but not \Finance\Budget, you're gonna have a bad time later.
• Have users log on using domain user accounts rather than local accounts. This approach centralizes the administration of share permissions.
• All permissions changes should be audited as they occur, and the permissions hierarchy should be audited at least once a year.

Configuring File Shares

• Create a top-level folder that will serve as the root storage folder for all user-created data (for example, C:\Data). Create sub-folders in it to segregate and organize data according to job roles and security requirements.
• Ensure that only IT can create root-level folders. Don't even let managers or executive create folders at the top 1 or 2 levels. If you don't lock down the root-level hierarchy, your neat folder structure will quickly be destroyed. Departments can organize their folders how they want, but don't allow junk folders.
• Organize your resources so that objects with the same security requirements are located in the same folder. For example, if users require the Read permission for several application folders, store those folders in the same parent folder. Then give Read permissions to the parent folder, rather than sharing each individual application folder separately.
• Make sure access-based enumeration is enabled. Access-based enumeration displays only the files and folders that a user has permissions to access. If a user does not have Read (or equivalent) permissions for a folder, Windows hides the folder from the user’s view.
• Set the Windows file share permissions pretty leniently — give Everyone, Authenticated Users or Domain Users the Full Control or Change permissions — and rely on NTFS for the real permissions management.
• Avoid having nested shares in your file structures because they can create conflicting behavior for the same network resources if it is accessed through different shares. This can be asking for trouble, especially when the share permissions are different. A nested share is a shared folder that resides in a separate shared folder. There are, of course, the default hidden shares (C$, D$, etc.), which make all shares nested beneath them, and they're a default. However, if your users use two separate non-hidden shares that are nested, there can be conflicting share permissions.
• Know when to copy and when to move. Standard copy and move operations deliver default results that can maintain your configured NTFS permissions — or break them. Copy operations will create the permissions of the destination container, and move operations will maintain that of the parent container. To keep this straight, just remember CC/MM — Copies Create, Moves Maintain.

Top 5 NTFS Permissions Tools

• Effective Permissions Reporting Tool from Netwrix
• NTFS Permissions Reporterfrom Cjwdev
• Access Enum (Microsoft utility)
• Permissions Reporter from Key Metric Software
• Permissions Analyzer from SolarWinds

Exporting NTFS Permissions via Powershell

• Exporting folder permissions using PowerShell
• Exporting user permissions using PowerShell