10 things about working with NTFS permissions
Tuesday, April 25, 2006 09:30 AM
Managing and troubleshooting permissions can be challenging, especially when everything looks like it should work. These tips and best practices will help you avoid some common problems.
1. NTFS vs. share permissions
The biggest point
of confusion about sharing with Windows systems is that the NTFS and
share-level permissions both have an effect on the user's ability to access
resources on a network. This is especially important to remember for Windows XP
and Windows Server 2003--and likely subsequent versions of Windows--which have
default share permissions as read-only. This makes the NTFS permissions limited
to read when accessing them over the network.
The best way to distinguish share permissions from NTFS permissions is to consider share permissions as an entry point to the resources. Only after the share permissions offer Change and/or Full Control can the NTFS permissions of that type be used.
The combination of share-level and NTFS permissions can seem like administrative overhead, but consider this: Share permissions act as a point of entry for the NTFS permissions over the network. When you enter a network resource through a share, the share permissions dictate what you cando through the share as a whole. The NTFS permissions dictate what you can do to specific files and folders. In the troubleshooting mode, identify whether share-level permissions can be ruled out of the issue.
2. Avoid nested shares
Troubleshooting issues that deal with both NTFS and share
permissions can seem overwhelming. Avoid having nested shares in your file
structures because they can create conflicting behavior for the same network
resources if 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 nonhidden shares
that are nested, there can be conflicting share permissions.
3. Use CACLS and XCACLS for granularity
You can use CACLS
and XCACLS to gather information on files that are a reflection of the NTFS
permissions you have configured. These tools will deliver data about the
permissions for specific file and folder resources. What's the difference
between NTFS permissions and an ACL (access control list)? The NTFS permissions
are set in Windows Explorer or via an automated mechanism for files and folders,
whereas an ACL (via these tools) is a display or management of allowed or
denied file operations for the same resource.
You can use CACLS and XCACLS to add or remove NTFS permissions in a scripted fashion as well. So if you have a great deal of permissions to adjust, a sophisticated script using these tools may be in order.
A good matter of practice for important shared files and folders with unique NTFS permissions is to make a script utilizing the CACLS.EXE tool to document the ACL for individual files and folders (or manually execute the steps to do this). But be careful: You can easily document your NTFS permissions by running "CACLS * /T" from a command prompt and document a folder, its contents, and subdirectories. This is very resource intensive and can require 100% CPU utilization on some systems when traversing extremely large folder paths. Depending on many factors, a large recursive ACL audit can take large amounts of time as well. This is similar to the scenario where new NTFS permissions are propagated to a large folder.
4. Distinguish between basic and special NTFS permissions
Only a right-click
away, special permissions give more options to particular access requirements. It's
important to note that using special permissions will increase the
administrative overhead associated with NTFS permissions simply by being more
complicated. Therefore, a best practice would be to use the special permissions
only when needed. The standard NTFS permissions provide most of the necessary
functionality to offer secure access to shared and local resources. However,
there are scenarios where using the special permissions makes sense.
Note: Be sure to rule out special permissions in troubleshooting. Every administrator has at one point not been sure of the application of various permissions--share permissions, NTFS permissions, group memberships, multiple user accounts, etc. Taking a quick look at the special permissions can quickly provide a hint as to whether they're part of the issue you are troubleshooting.
5. Keep resources warranting special permissions
separate
If the scenario permits, it can be a good practice to keep
resources requiring special permissions grouped in separate shares or folders
with other resources that have special permissions. Having standard permissions
intermixed with special permissions in the same location can add administrative
overhead.
6. Understand inherited permissions
Inherited
permissions is a default attribute of NTFS permissions on Windows Server 2003
and 2000 systems. Inherited permissions allow NTFS settings for a folder be
applied to its contents and all objects and folders contained within the top
folder.
Inheritance is fairly easy to understand when all defaults are used. But when inheritance is blocked, it becomes more difficult to troubleshoot. This difficulty is manifested when a folder deep within another folder has the Inherit Permissions option cleared. In troubleshooting inherited permissions, it is best to start at the root of the problem and work your way up the folder structure.
7. If clearing inheritance, be careful
When you clear inheritance of NTFS permissions from a parent
container, you are presented with two options: Copy and Remove. The Copy option
will recurse the child objects and write the NTFS permissions from the parent
folder. The Remove option removes all default NTFS-created permissions--that of
Administrators, Users, Creator Owner, System, etc.--from the list of Group or
User Names. Exercise caution when using the Remove option on inheritance
blocking!
8. Don't dodge the issue
The worst thing you can do to solve a rights problem is to
make someone a member of Administrators or some other powerful group to
circumvent a permissions issue. Simply giving more rights to a user does not
address the issue. Always identify the issue to determine the best solution.
9. Never over-privilege
A common misstep is
to provide too many rights--usually through group memberships--to users for
access to resources. Especially if you are using Active Directory, a clearly
organized structure with the membership and access requirements defined will
lend to a more correctly administered user or group. Take the firewall stance
of granting that which is explicitly required.
Too many permissions may not arise as a problem in a troubleshooting mode, but you may see one group or other membership attribute that gives too many rights--accidentally.
Group membership is one of the easiest ways to over- or under-privilege access to resources. Especially in domain configurations, the complexity is increased by multiple memberships and/or nested groups. Use the Effective Permissions tool to see what the resultant set of access is, determined by group membership when using Active Directory. Although this is not a direct display of NTFS permissions, you can then examine each group membership for an object as part of troubleshooting NTFS permissions.
10. Know when to copy and when to move
Standard copy and move
operations deliver default results that can maintain your configured
permissions--or break them. A good way to remember this is that copy operations
will create the permissions of the destination container, and move operations
will maintain that of the parent container.
Memorization mechanism: CC/MM--CopiesCreate/MovesMaintain or CopiesCreate/MovesMake.
Of course, there is also the need to copy resources and maintain NTFS permissions that would be difficult to re-create. The fallen SCOPY utility has given way to XCOPY with the /O and /X parameters to perform this type of function. Using XCOPY with these parameters will allow copy operations to copy the files and/or folders to a new location and create them with the NTFS permissions equal to that of the source container.
RF Engineer / New Horizons Student - Windows Server 2003
Thanks for de-mystifying some of the relationships between Shared and NTFS Permissions. Please continue to provide this type of information.
Posted by Doug Trotter on Friday, May 02 2008 09:22 PM