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.