How Permissions Work

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

How Permissions Work

In this section

• Permissions

• Conflicts Between User Rights and Permissions

• Related Information

Permissions are a key component of the Windows Server 2003 security architecture that you can use to manage the process of authorizing users, groups, and computers to access objects on a network.

Permissions enable the owner of each secured object, such as a file, Active Directory object, or registry key, to control who can perform an operation or a set of operations on the object or object property. Because access to an object is at the owner’s discretion, the type of access control that is used in Windows Server 2003 is called discretionary access control. An owner of an object always has the ability to read and change permissions on the object.

Permissions are applied to secured objects, such as files and folders, Active Directory objects, services, or registry objects. Permissions can be granted to a user, group, or computer. You can assign permissions on objects to the following:

• Groups, users, and special identities in the domain

• Groups and users in the domain and any trusted domains

• Local groups and users on the computer where the object resides

The permissions that are attached to an object depend on the type of object. For example, the permissions that can be attached to a file are different from the permissions that can be attached to a registry key.

Optimal Environment

The following sections provide general guidelines for how permissions should be applied to files and folders and Active Directory objects in an optimal environment.

Permissions on Files and Folders

• Shared folders are stored on NTFS file system volumes. You can set permissions at the file level only if the files are stored on an NTFS volume. On a FAT or FAT32 volume, you can set permissions for shared folders but not for files and folders within a shared folder. Moreover, share permissions on a FAT or FAT32 volume restrict network access only, not access by users working directly on the computer.

• Security templates are used wherever possible, rather than individual permissions.

• Default permission entries are used on file system objects, particularly on system folders and root folders. Changing default permissions can cause unexpected access problems or reduce security.

Permissions on Active Directory Objects

• The same set of permissions is assigned to multiple objects wherever possible. Access control lists (ACLs) in Windows Server 2003 feature single instancing: If multiple objects have identical ACLs, Active Directory stores only one instance of the ACL.

• Default permissions on Active Directory objects are left unchanged. Changing default permissions can cause unexpected access problems or reduce security.

• The number of access control entries (ACEs) that apply to child objects is kept to a minimum. When you use the Apply Onto option to control inheritance, be aware that not only will the specified objects inherit that ACE, but all child objects will also receive a copy of that ACE. If there are enough objects that will get copies of this ACE, the increased amount of data can cause performance problems on your network.

Permissions

A permission is authorization to perform an operation on a specific object, such as a file. Permissions can be granted by owners and by anyone with the permission to grant permissions, which normally includes administrators on the system.

If you own an object, you can grant any user or security group any permission on that object, including the permission to take ownership.

When permission to perform an operation is not explicitly granted, it is implicitly denied. For example, if Alice allows the Marketing group, and only the Marketing group, permission to read her file, users who are not members of the Marketing group are implicitly denied access.

Permissions can also be explicitly denied. For example, Alice might not want Bob to be able to read her file, even though he is a member of the Marketing group. She can exclude Bob by explicitly denying him permission to read the file. This is normally how explicit denies are used — to exclude a subset (such as Bob) from a larger group (such as Marketing) that has been given permission to perform an operation. Note that use of explicit denials, while possible, increase the complexity of the authorization policy and can create unexpected errors. For example, you might want to allow domain administrators to perform an action but deny domain users. If you attempt to implement this by explicitly denying domain users, you also deny any domain administrators who are also domain users. Though it is sometimes necessary, you can and should avoid the use of explicit denies in most cases.

Each permission that an object’s owner grants to a particular user or group is stored as an ACE in a discretionary access control list (DACL) that is part of the object’s security descriptor.

Permissions and Security Descriptors

Every container and object on the network has a set of access control information attached to it that is called a security descriptor. This information controls the type of access that is allowed to users and groups. The security descriptor is automatically created along with the container or object that is created. For example, each file has a security descriptor.

An object’s security descriptor contains its permissions. Permissions are associated with, or assigned to, specific users and groups. For example, for a file Temp.dat, the Administrator group might be assigned Read, Write, and Delete permissions, while the Operator group might be assigned Read and Write permissions only.

Each assignment of permissions to a user or group is called a permission entry, which is a type of ACE. The entire set of permission entries in a security descriptor is known as a permission set or ACL. Therefore, for the file named Temp.dat, the permission set includes two permission entries, one for the Administrator group and one for the Operator group.

Ownership

Every object has an owner, whether in an NTFS volume or in Active Directory. The owner controls how permissions are set on the object and to whom permissions are granted.

By default, in Windows Server 2003, the owner is the creator of the object. If the creator of an object is a member of the Administrators group, the Administrators group is the owner. The owner can always change permissions on an object, even when denied all access to the object.

Ownership can be taken by the following:

• Any user with the Take ownership of files or other objects user right, which can be granted to any user. By default, the Administrators group is given the Take ownership of files or other objects user right.

  An administrator who wants to repair or change permissions on a file must begin by taking ownership of the file.

• Anyone or any group who has the Take ownership permission on the object in question

• A user who has the Restore files and directories user right

Ownership can be transferred in the following ways:

• The current owner can grant the Take ownership permission to another user, allowing that user to take ownership at any time. The user must actually take ownership to complete the transfer.

• An administrator can take ownership.

• A user who has the Restore files and directories user right can assign ownership to any user or group.

Explicit vs. Inherited Permissions

There are two types of permissions, explicit permissions and inherited permissions:

• Explicit permissions are those that are set by default when the object is created or by user action.

• Inherited permissions are those that are propagated to a child object from a parent object. Inherited permissions ease the task of managing permissions and ensure consistency of permissions among all objects in a given container.

By default, objects that are created in a container inherit the permissions from that container when the objects are created. For example, when you create a folder called MyFolder, all subfolders and files that are created in MyFolder automatically inherit the permissions from MyFolder. Therefore, MyFolder has explicit permissions, while all subfolders and files in it have inherited permissions.

Notes

• Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry.

• Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.

Access Masks

In an ACE, permissions are represented by one or more bits in a 32-bit value called an access mask. When a thread requests access to an object, it specifies the type of access that it desires by using an access mask as well. During an access check, the operating system compares the desired access mask that is supplied by the thread with the access mask in each ACE of the object’s DACL, looking for bits that match. The following figure illustrates the layout of an access mask.

Layout of an Access Mask

Each bit corresponds to an access right — a particular operation or set of operations that can be performed on the object. Turning a bit on in a desired access mask signals that the thread requests the right to perform the corresponding operation. Turning a bit on in the access mask for an ACE signals that the corresponding operation is either allowed or denied, depending on the type of ACE.

Although many of the access rights in an access mask correspond to permissions that can be set through the user interface, not all of them do. Some can be set only by a process, such as the process that creates an object, and they cannot be manipulated through the user interface. Windows Server 2003 uses an access mask format that includes the following types of access rights.

Generic access rights

These rights apply to all objects, but they mean different things for different object types. Each object type maps each generic access right to a different set of standard and object-specific access rights. The following table lists generic access rights.

Generic Access Rights

Constant in Win32 API	Meaning
GENERIC_ALL	Read, write, and execute access
GENERIC_EXECUTE	Execute access
GENERIC_READ	Read access
GENERIC_WRITE	Write access

Standard access rights

These rights are more specific than generic access rights, but they still apply to operations that are available for most object types. The following table lists standard access rights.

Standard Access Rights

Constant in Win32 API	Meaning
DELETE	The right to delete the object
READ_CONTROL	The right to read the information in the object’s security descriptor, not including the information in the system access control list (SACL)
SYNCHRONIZE	The right to use the object for synchronization. Some object types do not support this access right.
WRITE_DAC	The right to modify the DACL in the object’s security descriptor
WRITE_OWNER	The right to change the owner in the object’s security descriptor

SACL access right

This right controls the ability to read or change an object’s SACL, which controls auditing for the object. The operating system allows access to the SACL only if the subject’s access token includes the Manage auditing and security log (SeSecurityPrivilege) user right.

Object-specific access rights

Each type of securable object defines its own set of access rights. For a list of the specific access rights that apply to each type of object, see the Microsoft Platform SDK link on MSDN.

Permissions for Files and Folders

Folder permissions include Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. Each of these permissions consists of a logical group of special permissions that are listed and defined in the following table.

Permissions for Files and Folders

Permission	Description
Traverse Folder/ Execute File	For folders: Traverse Folder allows or denies moving through folders to reach other files or folders, even if the user has no permissions on the traversed folders. (Applies to folders only.) Traverse folder takes effect only when the group or user is not granted the Bypass traverse checking user right in the Group Policy snap-in. (By default, the Everyone group is given the Bypass traverse checking user right.) For files: Execute File allows or denies running program files. (Applies to files only.) Setting the Traverse Folder permission on a folder does not automatically set the Execute File permission on all files in that folder.
List Folder/ Read Data	List Folder allows or denies viewing file names and subfolder names in the folder. List Folder only affects the contents of that folder; it does not affect whether the folder you are setting the permission on will be listed. (Applies to folders only.) Read Data allows or denies viewing data in files. (Applies to files only.)
Read Attributes	Allows or denies viewing the attributes of a file or folder, such as read-only and hidden. Attributes are defined by NTFS.
Read Extended Attributes	Allows or denies viewing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program.
Create Files/ Write Data	Create Files allows or denies creating files in the folder. (Applies to folders only.) Write Data allows or denies making changes to the file and overwriting existing content. (Applies to files only.)
Create Folders/ Append Data	Create Folders allows or denies creating folders in the folder. (Applies to folders only.) Append Data allows or denies making changes to the end of the file but not changing, deleting, or overwriting existing data. (Applies to files only.)
Write Attributes	Allows or denies changing the attributes of a file or folder, such as read-only or hidden. Attributes are defined by NTFS. The Write Attributes permission does not imply creating or deleting files or folders, it only includes the permission to make changes to the attributes of a file or folder. To allow (or deny) create or delete operations, see Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files, and Delete.
Write Extended Attributes	Allows or denies changing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program. The Write Extended Attributes permission does not imply creating or deleting files or folders, it only includes the permission to make changes to the attributes of a file or folder. To allow (or deny) create or delete operations, see Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files, and Delete.
Delete Subfolders and Files	Allows or denies deleting subfolders and files, even if the Delete permission has not been granted on the subfolder or file. (Applies to folders.)
Delete	Allows or denies deleting the file or folder. If you do not have Delete permission on a file or folder, you can still delete it if you have been granted Delete Subfolders and Files on the parent folder.
Read Permissions	Allows or denies reading permissions of the file or folder, such as Full Control, Read, and Write.
Change Permissions	Allows or denies changing permissions of the file or folder, such as Full Control, Read, and Write.
Take Ownership	Allows or denies taking ownership of the file or folder. The owner of a file or folder can always change permissions on it, regardless of any existing permissions that protect the file or folder.
Synchronize	Allows or denies different threads to wait on the handle for the file or folder and synchronize with another thread that may signal it. This permission applies only to multithreaded, multiprocess programs.

You cannot access an encrypted file without the Encrypting File System (EFS) key, even if you have the necessary permissions.

The following table lists the special permissions and their corresponding file and folder permissions.

Special Permissions

Special Permissions	Full Control	Modify	Read & Execute	List Folder Contents (folders only)	Read	Write
Traverse Folder/Execute File
List Folder/Read Data
Read Attributes
Read Extended Attributes
Create Files/Write Data
Create Folders/Append Data
Write Attributes
Write Extended Attributes
Delete Subfolders and Files
Delete
Read Permissions
Change Permissions
Take Ownership
Synchronize

You should also be aware of the following:

• Groups or users that are granted Full Control on a folder can delete any files in that folder, regardless of the permissions protecting the file.

• Although List Folder Contents and Read & Execute appear to have the same special permissions, these permissions are inherited differently. List Folder Contents is inherited by folders but not files, and it should only appear when you view folder permissions. Read & Execute is inherited by both files and folders, and it is always present when you view file or folder permissions.

• In Windows Server 2003, by default, Everyone does not include Anonymous Users; therefore, permissions that are applied to Everyone do not affect Anonymous Users.

Permissions on a Shared Folder

Access on a shared folder is determined through two sets of permission entries; the permissions that are set on the share (called share permissions) and the permissions that are set on the folder (called NTFS file and folder permissions). Share permissions are often used for managing computers with FAT32 file systems or for managing other computers that do not use the NTFS file system.

Share permissions and NTFS permissions are independent in the sense that neither changes the other. The final access permissions on a shared folder are determined by taking into consideration both the share permission and the NTFS permission entries. The more restrictive permissions are then applied.

The following table suggests permissions that a security-conscious administrator can grant to the Users group for certain shared folder types. The recommended permissions have been tested and they work correctly, but there are alternative approaches. For example, some experienced administrators prefer to always set share permissions to Full Control for Everyone and to rely entirely on NTFS permissions to restrict access.

Permissions for File Servers

Folder Type	Share Permissions	NTFS Permissions
Public folder. A folder that can be accessed by everyone.	Grant Change permission to the Users group.	Grant Modify permission to the Users group.
Drop folder. A folder where users can drop confidential reports or homework assignments that only the group manager or instructor can read.	Grant Change permission to the Users group. Grant the Full Control permission to the group manager.	Grant the Write permission for the users’ group that is applied to This Folder only. (This option is available on the Advanced page.) If each user needs to have certain permissions to the files that he or she dropped, you can create a permission entry for the Creator Owner well-known security identifier (SID) and apply it to Subfolder and files only. For example, you can grant the Read and Write permission to the Creator Owner SID on the drop folder and apply it to all subfolders and files. This grants the user who dropped or created the file (the Creator Owner) the ability to read and write to the file. The Creator Owner can then access the file through the Run command using \\ServerName\DropFolder\FileName. Note that as creator of the file, the user has the ability to Read and Change the permission on the file independent of any permissions that are granted explicitly. Grant the Full Control permission for the group manager.
Application folder. A folder containing applications that can be run over the network.	Grant Read permission to the Users group.	Grant Read, Read & Execute, and List Folder Content permissions to the Users group.
Home folders. Individual folders for each user. Only the user has access to the folder.	Grant the Full Control permission to each user for their respective folders.	Grant the Full Control permission to each user for their respective folders.

In addition, you should know the following information:

• NTFS permissions affect access both locally and remotely. NTFS permissions apply regardless of protocol. Share permissions, by contrast, apply only to network shares. Share permissions do not restrict access to any local user, or to any terminal server user, of the computer on which you have set share permissions. Therefore, share permissions do not provide privacy between users on a computer that is used by several users, nor on a terminal server that is accessed by several users.

• By default, Everyone does not include Anonymous Users; therefore, permissions that are applied to Everyone do not affect Anonymous Users. This default behavior is new for Windows Server 2003.

• A user who places a file on a share is the creator of that copy of the file and therefore has the ability to read and change the permissions on the file independent of the permissions that are inherited.

• When possible, you should attempt to grant permissions to groups instead of to specific user accounts.

Permissions on Active Directory Objects

You can manage permissions on objects in Active Directory at two levels:

• At the object level. Permissions that are allowed or denied at the object level apply to the entire object. For example, you can set an object-level permission on an organizational unit (OU) object that allows a particular group, such as Account Operators, to create child objects in the OU.

• At the property level. Permissions that are allowed or denied at the property level apply only to specific properties. For example, you can set a property-level permission on a User object that allows a particular user, such as Principal Self (that is, the user that is represented by the object), to change the Home Address property of the User object.

There is an important difference between how permissions are propagated from container objects in NTFS and how they are propagated from container objects in Active Directory. If you own a folder object in an NTFS volume, you can control who has access to the folder and all that it contains by setting a permission on the folder that applies not only to the folder but to all objects in the folder. For example, you can add a permission to a Folder object that allows the Marketing group read access. If you apply the permission to This folder, subfolders and files, it is propagated to all objects that are contained in the folder. The Marketing group then has read access to the folder and to all its subfolders and files.

Propagation of permissions works differently for Active Directory objects. If you own a container object in Active Directory, you can allow access to certain types of objects in the container without allowing access to other types of objects in the container. For example, if you own an OU object, you can add a permission that allows the Marketing group read access and then apply the permission to a particular type of child object that is contained by the OU. If you apply it to Contact objects, for example, the permission is propagated only to Contact objects but not to User objects or to any other type of child object. In other words, permissions that are propagated from container objects in Active Directory can be object specific, whereas permissions that are propagated from container objects in an NTFS volume cannot be object specific.

Permissions on Registry Keys

Registry permissions are set on container objects only, and the individual keys inherit their permissions from the container. A registry key has two basic permissions: Full Control and Read. The Read permission includes the special permissions Read Control, Query Value, Notify, and Enumerate Subkeys. The Full Control permission includes all the special registry permissions, as shown in the following table. You can use Regedit.exe or the Subinacl.exe command-line tool to modify registry permissions.

Special Registry Permissions

Permission	Description
Query Value	Allow the registry key value to be read.
Set Value	Allow the value of an existing key to be written.
Create Subkey	Allow the creation of subkeys.
Enumerate Subkeys	Allow the enumeration of subkeys.
Notify	Notify permission is required to request change notifications for registry keys or subkeys.
Create Link	Reserved by the operating system.
Delete	Allow the key to be deleted.
Write DACL	Allow modification of the container’s DACL.
Write Owner	Allow modification of the container’s owner.
Read Control	Allow the SACL to be read.

Permissions on Services

Each service has a DACL containing the permissions on the service. You can view or modify the DACL by using Subinacl.exe. You can also export the security configuration of a computer into a security template and view the DACL by using the Security Templates Microsoft Management Console (MMC) snap-in. The following table shows the permissions for services.

Permissions on Services

Permission	Description
Full Control	Grant full control of the service.
Query Template	Allow the service configuration to be viewed.
Change Template	Allow the service configuration to be modified.
Query Status	Allow the Service Control Manager (SCM) to be queried for the service status.
Enumerate Dependents	Allow the dependent services to be displayed.
Start	Allow the service to be started.
Stop	Allow the service to be stopped.
Pause and Continue	Allow the service to be paused and resumed.
Interrogate	Allow the service to respond to status queries.
User Defined Control	Allow special instructions to be given to the service.
Delete	Allow the service to be deleted.
Read Permissions	Allow the DACL of the service to be viewed.
Change Permissions	Allow the DACL of the service to be changed.
Take Ownership	Allow the owner of the service to be changed.

Conflicts Between User Rights and Permissions

User rights enable administrators to assign specific privileges and logon rights to groups or users. These rights authorize users to perform specific actions, such as logging on to a system interactively or backing up files and directories. User rights are different from permissions because user rights apply to user accounts and permissions are attached to objects.

Administrators can use user rights to manage who has the authority to perform operations that span an entire computer, rather than a particular object. Administrators assign user rights (also known as privileges) to individual users or groups as part of the security settings for the computer. Although user rights can be managed centrally through Group Policy, they are applied locally. Users can (and usually do) have different user rights on different computers.

Unlike permissions, which are granted by an object’s owner, user rights are assigned as part of the local security policy for the computer.

There are two types of user rights: privileges, such as the right to back up files and directories, and logon rights, such as the right to log on to a system locally. For more information about user rights and their descriptions and default settings, see “Security Policy Settings.”

Conflicts between privileges and permissions normally occur only in situations where the rights that are required to administer a system overlap the rights of resource ownership. When rights conflict, a privilege overrides a permission.

For example, to create a backup of files and folders, backup software must be able to traverse all folders in an NTFS volume, list the contents of each folder, read the attributes of every file, and read data in any file that has its archive attribute set. It is impractical to arrange this access by coordinating with the owner of every file and folder; therefore, the required rights are included in the Back up files and directories (SeBackupPrivilege) privilege, which is assigned by default to two built-in groups: Administrators and Backup Operators. Any user who has this privilege can access all files and folders on the computer for the purpose of backing up the system. The same default permissions granted to Backup Operators that allow them to back up and restore files also make it possible for Backup Operators to use the group’s permissions for other purposes, such as reading another user’s files or installing Trojan horse programs. Therefore, the backup operators group should be limited to only highly trusted user accounts that require the ability to back up and restore computers.

The ability to take ownership of files and other objects is another case where an administrator’s need to maintain the system takes priority over an owner’s right to control access. Normally, you can take ownership of an object only if its current owner gives you permission to do so. Owners of NTFS objects can allow another user to take ownership by granting the other user Take Ownership permission; owners of Active Directory objects can grant another user Modify Owner permission. A user who has this privilege can take ownership of an object without the current owner’s permission. By default, the privilege is assigned only to the built-in Administrators group. It is normally used by administrators to take and reassign ownership of resources when their current owner is no longer available.

Related Information

The following resources contain additional information that is relevant to this section:

• Microsoft Platform SDK link on the Web Resources page

• Security Policy Settings

• Permissions Tools and Settings