Inheritance and cumulative effectiveness
The combinations of permissions are complex. Before you consider them, think about the inheritance of permissions and the fact that permissions for user accounts and groups have a cumulative effect. This alone can be confusing.
Inheritance allows permissions to cascade downward to child objects
from a parent object. For example, if the Operations folder also
contains a Schedules folder and a Safety Documents folder, you could
allow permissions assigned to the Operations folder to be inherited by
both those child folders. This would assign the permissions from
Operations to those folders and their files.
Inheritance makes assigning permissions much easier because it is
not always necessary to assign permissions directly. However, relying
on inheritance can produce unexpected results when accessing these
objects.
Because Mikhail is a member of the operations group, he is allowed
Full Control on the Operations folder by default, and he inherits the
same permissions on the child objects within
operations. Because he has volunteered to participate in a project with
the customer service team to help ease their workload, you add him to
the customer service group to allow him access to the needed materials
for the project.
Customer service associates do not need access to operations and, to
ensure that they do not access operations materials, the group is
denied access to operations.
Removing Mikhail from the customer service group will restore the
proper access to operations. This is an example of the power of the
Deny permission. It takes effect regardless of other permissions an
account might be assigned.
A better method for handling removal of access might be to allow no permissions to an object. This way, the security
principal has no permissions and cannot access an object directly but
might be granted access based on group memberships and their permission
assignment.
Cumulative application means that all the permissions
a user account or group might have are evaluated to determine the
access allowed. If Maria belongs to the operations group, the
schedulers group, and the human resources group, all the access
permissions assigned to each of these groups
will affect Maria because she is a member of each group. In addition,
any permission assigned directly to her user account is evaluated.
For example, Orin is a member of the schedulers group, which can
view and read items in the Operations and Schedules folders. He can
view documents within the Schedules folder but cannot edit them. This
group also has List Folder Contents as the only permission assigned for
the Operations folder.
One of the operations managers asks Orin to help with a project for
a few months. The project involves updating safety documentation for
the operations team to ensure that the latest information is available.
When Orin accepts this project, his account is placed in the operations
safety group, which can add and remove documents from the Safety folder
within Operations. The group can also change items in the Schedules
folder to allow for the addition of training on new safety material.
Deny permissions
are processed before other permissions. After that, permissions are
cumulative. The overall access to items can be tricky to understand.
Fortunately, a tool in the Advanced Security Settings dialog box can
help. The Effective Access tab displays the permissions
currently applied to the specified user account or group. This
considers any access to an object, direct or inherited, and displays
the cumulative permissions for a security principal on the selected object. The Effective Access tab is shown in Figure 4.
A security principal who has permission to take ownership
of a file or folder can grant himself or herself the right to change
permissions on the object in addition to having full control of the
object. Taking
ownership of files and folders might be necessary when the original
owner of the object has left the organization and others within the
organization need access to the object. Generally, taking ownership is
useful for this type of recovery. The primary user of an object does
not need to be the object’s owner.
Understanding share-level permissions
Share permissions determine which
user accounts or groups
can access an object or group of objects over a network share. If the
Share permissions are not configured, access to resources across the
network might not function as needed.
Note
NTFS PERMISSIONS AND SHARE-LEVEL PERMISSIONS
If you intend to manage security by using NTFS permissions and do not want to worry about share-level
permissions, share-level permissions can be set to allow the Everyone
group Full Control at the share level. In this way, NTFS security is
the primary method for providing security. These permissions are not
cumulative with NTFS permissions, but, when not configured, they can be
an interesting issue to troubleshoot.