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:
- 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)
- Use these groups to set NTFS permissions to the appropriate user rights.
- 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
Exporting NTFS Permissions via Powershell
What are NTFS Permissions
NTFS (New Technology File System) is the standard file system for Windows NT and all later Windows operating systems. With NTFS, you use shared folders to provide network users with access to file resources and thereby manage permissions for drives and folders. NTFS permissions are available to all drives formatted with this file system. Each user can choose to share entire drives or individual folders with the network.
The main advantages of NTFS permissions are that they affect local users as well as network users and they are based on the permissions granted to each individual user at the Windows logon, regardless of where the user is connecting. Administrators can use the NTFS utility to control access to files and folders, containers and objects on the network as part of system security.