Access Control User Interface

The access control user interface is a series of dialog boxes that allows you to alter NTFS permissions, manage the ownership of objects and specify the auditing scope on an object. You can find this feature by clicking the Security tab on the Properties page of an object that allows you to set NTFS permissions.

Access control is the process of authorizing users, groups, and computers to access objects for which you can set permissions on the computer or network. This section contains the following topics:

  • Access Control Overview

  • Checklist: Setting Access Controls on Objects

  • Manage Permissions

  • Manage Object Ownership

  • Manage Security Auditing

  • Resources for Access Control

  • User Interface: Access Control


Access Control Overview

Access control is the process of authorizing users, groups, and computers to access objects on the network or computer. Key concepts that make up access control are permissions, ownership of objects, inheritance of permissions, user rights, and object auditing.

Permissions

Permissions define the type of access granted to a user or group for an object or object property. For example, the Finance group can be granted Read and Write permissions for a file named Payroll.dat.

Using the access control user interface, you can set NTFS permissions for objects such as files, Active Directory® objects, registry objects, or system objects such as processes. Permissions can be granted to any user, group, or computer. It is a good practice to assign permissions to groups because it improves system performance when verifying access to an object.

For any object, you can grant permissions to:

  • Groups, users, and other objects with security identifiers in the domain.

  • Groups and users in that domain and any trusted domains.

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

The permissions attached to an object depend on the type of object. For example, the permissions that can be attached to a file are different from those that can be attached to a registry key. Some permissions, however, are common to most types of objects. These common permissions are:

  • Read

  • Modify

  • Change owner

  • Delete

When you set permissions, you specify the level of access for groups and users. For example, you can let one user read the contents of a file, let another user make changes to the file, and prevent all other users from accessing the file. You can set similar permissions on printers so that certain users can configure the printer and other users can only print.

When you need to change the permissions on a file, you can run Windows Explorer, right-click the file name, and click Properties. On the Security tab, you can change permissions on the file. For more information, see Manage Permissions.

Note

Another kind of permissions, called share permissions, is set on the Sharing tab of a folder's Properties page or by using the Shared Folder wizard. For more information see Share and NTFS Permissions on a File Server.

Ownership of objects

An owner is assigned to an object when that object is created. By default, the owner is the creator of the object. No matter what permissions are set on an object, the owner of the object can always change the permissions on an object. For more information, see Manage Object Ownership.

Inheritance of permissions

Inheritance allows administrators to easily assign and manage permissions. This feature automatically causes objects within a container to inherit all the inheritable permissions of that container. For example, the files within a folder, when created, inherit the permissions of the folder. Only permissions marked to be inherited will be inherited.

User rights

User rights grant specific privileges and logon rights to users and groups in your computing environment. Administrators can assign specific rights to group accounts or to individual user accounts. 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. Although user rights can apply to individual user accounts, user rights are best administered on a group account basis. There is no support in the access control user interface to grant user rights; however, user rights assignment can be administered through the Local Security Settings snap-in.

Object auditing

With administrator's rights, you can audit users' successful or failed access to objects. You can select which object access to audit by using the access control user interface, but first you must enable the Audit Policy by selecting Audit object access under Local Policies in the Local Security Settings snap-in. You can then view these security-related events in the Security log in Event Viewer.

For more information about authorization and access control, see Windows Security Collection on Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=4565). For information about authorization strategy, see Designing a Resource Authorization Strategy on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=4734).


Checklist: Setting Access Controls on Objects

Access control is the process of authorizing users, groups, and computers to access objects on the computer or network. You can accomplish the tasks in the following table by using the access control user interface.

Task | Reference
View the effective permissions on and ownership of an object | View Effective Permissions on Files and Folders Manage Object Ownership
Manage the permissions on an object | Manage Permissions
Take ownership of a file or folder | Take Ownership of a File or Folder
Manage the security auditing policy settings on an object | Manage Security Auditing


Manage Permissions

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information controls the type of access allowed to users and groups. Permissions are defined within an object's security descriptor. Permissions are associated with, or assigned to, specific users and groups.

When you are a member of a security group that is associated with an object, you have some ability to manage the permissions on that object. For those objects you own, you have full control. You can use different methods, such as Active Directory, Group Policy, or access control lists, to manage different types of objects.

This section contains:

  • What are Permissions?

  • File and Folder Permissions

  • Share and NTFS Permissions on a File Server

  • Determine Where to Apply Permissions

  • Inherited Permissions

  • Set, View, Change, or Remove Permissions on an Object

For information about managing permissions by using Active Directory, see Assign, change, or remove permissions on Active Directory objects or attributes (http://go.microsoft.com/fwlink/?LinkId=63970)

For information about managing permissions by using Group Policy, see Apply or Modify Permission Entries for Objects Using Group Policy (http://go.microsoft.com/fwlink/?LinkId=64928).


What are Permissions?

Permissions and security descriptors

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information controls the type of access allowed to users and groups. The security descriptor is automatically created along with the container or object that is created. A typical example of an object with a security descriptor is a file.

Permissions are defined within an object's security descriptor. Permissions are associated with, or assigned to, specific users and groups. For example, for the file Temp.dat, the built-in Administrators group might be assigned Read, Write, and Delete permissions, while the Backup Operators group might be assigned Read and Write permissions only.

Each assignment of permissions to a user or group is represented in the system as an access control entry (ACE). The entire set of permission entries in a security descriptor is known as a permission set or access control list (ACL). Thus, for a file named Temp.dat, the permission set includes two permission entries, one for the built-in Administrators group and one for the Backup Operators 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 on non-child objects when the object is created, or by user action on non-child, parent or child objects.

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

By default, objects within 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 created within MyFolder automatically inherit the permissions from that folder. Therefore, MyFolder has explicit permissions, while all subfolders and files within it have inherited permissions.

Note

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.

Additional References

  • File and Folder Permissions

  • Set, View, Change, or Remove Permissions on an Object


File and Folder Permissions

The following table lists the access limitations for each set of special NTFS permissions.

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

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

Note

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 is always present when you view file or folder permissions.

Note

In this version of Windows and Windows Server 2003, by default the Everyone group does not include the Anonymous group, so permissions applied to the Everyone group do not affect the Anonymous group.


How Inheritance Affects File and Folder Permissions

How Inheritance Affects File and Folder Permissions

After you set permissions on a parent folder, new files and subfolders that are created in the folder inherit these permissions. If you do not want them to inherit permissions, select This folder only in the Apply onto box when you set up special permissions for the parent folder. Special permissions are accessible through the Permissions tab. In cases where you want to prevent only certain files or subfolders from inheriting permissions, right-click the file or subfolder, click Properties, click the Security tab, click Advanced, and then clear the Include inheritable permissions from this object's parent. check box.

If the Allow or Deny check boxes associated with each permission appear shaded, the file or folder has inherited permissions from the parent folder. There are three ways to make changes to inherited permissions:

  • Select the opposite permission (Allow or Deny) to override the inherited permission.

  • Clear the Include inheritable permissions from this object's parent. check box. You can then make changes to the permissions or remove the user or group from the permissions list. However, the file or folder will no longer inherit permissions from the parent folder.

  • Make the changes to the parent folder, and then the file or folder will inherit these permissions.

In most cases, Deny overrides Allow unless a folder is inheriting conflicting settings from different parents. In that case, the setting inherited from the parent closest to the object in the subtree will have precedence.

Only inheritable permissions are inherited by child objects. When setting permissions on the parent object, you can decide whether folders or subfolders can inherit them with the Apply onto box from the Permissions tab of the Advanced Security Settings for <object> dialog box.


Share and NTFS Permissions on a File Server

Access to a folder on a file server can be determined through two sets of permission entries: the share permissions set on a folder and the NTFS permissions set on the folder (which can also be set on files). Share permissions are often used for managing computers with FAT32 file systems, or 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 equivalent permissions that a security-conscious administrator can grant to the Users group for certain shared folder types. There are alternative approaches. For example, some experienced administrators prefer always to set share permissions to Full Control for Everyone, and to rely entirely on NTFS permissions to restrict access.

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 the 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 is an option 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.

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 for the Users group.

Grant Read, Read and 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 on their respective folder.

Grant the Full Control permission to each user for their respective folder.

Addition considerations

  • Granting a user Full Control NTFS permission on a folder enables that user to take ownership of the folder unless the user is restricted in some other way. Be cautious in granting Full Control.

  • If you want to manage folder access by using NTFS permissions exclusively, set Share permissions to Full Control for Everyone. This frees you from having to think about Share permissions, but NTFS permissions are more complex than Share permissions.

  • 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. Thus, Share permissions do not provide privacy between users on a computer used by several users, nor on a terminal server accessed by several users.

  • By default, the Everyone group does not include the Anonymous group, so permissions applied to the Everyone group do not affect the Anonymous group.


Determine Where to Apply Permissions

Determining where to apply permissions

When you set advanced permissions on files and folders, you can use the Permission Entry for <Object Name> dialog box to set which descendant objects will inherit permissions.

To find this dialog box, click the Advanced button on the access control user interface. On the Permissions tab click Edit twice.

In the Permission Entry for <Object Name> dialog box, the Apply onto box on the Object tab lists the locations where you can apply permissions. How these permissions are applied depends on whether you select the Apply these permissions to objects and/or containers within this container only check box.

Important

For Active Directory objects, not only do the specified objects in the Apply onto box inherit the access control entries but ALL child objects receive a copy of that ACE. The child objects not specified in the Apply onto box do not utilize the ACE whose copy they receive, but if there are enough objects that get copies of this ACE, that increased amount of data can cause serious performance problems to your network.

By default, this check box is cleared. See the following tables for details about how the inherited permissions are applied:

  • When the Apply these permissions to objects and/or containers within this container only check box is cleared

  • When the Apply these permissions to objects and/or containers within this container only check box is selected

When the Apply these permissions to objects and/or containers within this container only check box is cleared

Apply onto | Applies permissions to current folder | Applies permissions to subfolders in current folder | Applies permissions to files in current folder | Applies permissions to all subsequent subfolders | Applies permissions to files in all subsequent subfolders
This folder only | x |  |  |  |
The folder, subfolders and files | x | x | x | x | x
This folder and subfolders | x | x |  | x |
This folder and files | x |  | x |  | x
Subfolders and files only |  | x | x | x | x
Subfolders only |  | x |  | x |
Files only |  |  | x |  | x

When the Apply these permissions to objects and/or containers within this container only check box is selected

Apply onto | Applies permissions to current folder | Applies permissions to subfolders in current folder | Applies permissions to files in current folder | Applies permissions to all subsequent subfolders | Applies permissions to files in all subsequent subfolders
This folder only | x |  |  |  |
The folder, subfolders and files | x | x | x |  |
This folder and subfolders | x | x |  |  |
This folder and files | x |  | x |  |
Subfolders and files only |  | x | x |  |
Subfolders only |  | x |  |  |
Files only |  |  | x |  |

For information about where to assign permissions to Active Directory objects, see Best practices for assigning permissions on Active Directory objects (http://go.microsoft.com/fwlink/?LinkId=63971)

For more information about setting permissions, see the following:

  • File and Folder Permissions

  • Set, View, Change, or Remove Permissions on an Object


Inherited Permissions

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

Inheritance for all objects

If the Allow and Deny permission check boxes in the various parts of the access control user interface are shaded when you view the permissions of an object, the object has inherited permissions from the parent object. You can set these inherited permissions through the Permissions tab of the Advanced Security Settings Properties page. There are three recommended ways to make changes to inherited permissions:

  • Make the changes to the parent object where the permissions are explicitly defined, and then the child object will inherit these permissions.

  • Select the Allow permission to override the inherited Deny permission.

  • Clear the Include inheritable permissions from this object's parent check box. Then you can make changes to the permissions or remove users or groups from the Permissions list. However, the object will no longer inherit permissions from the parent object.

    Note

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

    Note

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

If the Special Permissions entry in Permissions for <User or Group> is shaded, it does not imply that this permission has been inherited. This means that a special permission has been selected.

On the Permissions tab of the Advanced Security Settings for <Folder> page, in Permission entries, the Apply To column lists what folders or subfolders a permission is applied to. The Inherited From column lists where the permissions have been inherited from.

You can use the Apply onto field of the Permission Entry for <Folder> page to select the folders or subfolders you would like permissions to be applied to.

Inheritance for Active Directory objects

For Active Directory objects, when using an Apply Onto option to control inheritance, be aware that not only do the objects specified in the Apply onto field inherit that access control entry (ACE), but also all child objects also receive a copy of that ACE. The child objects that are not specified in the Apply onto box receive copies of the ACE but do not enforce it. If there are enough objects getting copies of this ACE, then that increased amount of data can cause serious performance problems to your network.

If you assign permissions to a parent object and want child objects to inherit these permission entries, you can keep performance optimal by making sure all the child objects have identical access control lists (ACLs). In Windows Server 2003, single-instancing allows for Active Directory to store only one copy of all identical ACLs. By creating ACLs that many objects can utilize, you can preserve the performance of your network.

For more information about permissions, see the following topics:

  • What are Permissions?

  • Set, View, Change, or Remove Permissions on an Object

  • Determine Where to Apply Permissions

For more information about permissions for Active Directory objects, see Access control in Active Directory (http://go.microsoft.com/fwlink/?LinkId=63972).


How Effective Permissions Are Determined

Each object has a set of effective permissions associated with it. The Effective Permissions tab of the Advanced Security Settings property page lists those permissions that would be granted to the selected group or user based solely on the permissions granted directly through group membership. If you would like to find out what permissions a user or group has on an object, you can use the Effective Permissions Tool.

Factors That are Used to Determine Effective Permissions

  • Global group membership

  • Local group membership

  • Local permissions

  • Local privileges

  • Universal group membership

Factors That are not Used to Determine Effective Permissions

The following well-known security identifiers (SIDs) are not used to determine effective permissions:

  • Anonymous Logon

  • Batch, Creator Group

  • Dialup

  • Enterprise Domain Controllers

  • Interactive

  • Network

  • Proxy

  • Restricted

  • Remote

  • Service

  • System

  • Terminal Server User

  • Other Organization

  • This Organization

Also, share permissions are not part of the effective permissions calculation. Access to shares can be denied through share permissions even when access is allowed through NTFS permissions.

Factors That are not Used for Objects That are Accessed Remotely

  • Local group membership

  • Local privileges

  • Share permissions

Effective Permissions evaluates the user's group membership, user privileges, and permissions locally. If the resource being queried is on a remote computer, the effective permissions displayed will not include permissions granted or denied to the user through the use of a local group on the remote computer.

Retrieving Effective Permissions

Accurate retrieval of the above information requires permission to read the membership information. If the specified user or group is a domain object, you must have permission to read the object's group information about the domain. Here are some relevant default domain permissions:

  • Domain administrators have permission to read membership information about all objects.

  • Local administrators on a workstation or stand-alone server cannot read membership information for a domain user.

  • Authenticated domain users can only read membership information when the domain is in Pre-Windows 2000 compatibility mode.

Effective Permissions Tool

If you would like to find out what permissions a user or group has on an object, you can use the Effective Permissions tool. It calculates the permissions that are granted to the specified user or group. The calculation takes the permissions in effect from group membership into account, as well as any permissions inherited from the parent object. It looks up all domain and local groups in which the user or group is a member.

The Everyone group will always be included, as long as the selected user or group is not a member of the Anonymous Logon group.

Important
  • The Effective Permissions tool only produces an approximation of the permissions that a user has. The actual permissions the user has may be different, since permissions can be granted or denied based on how a user logs on. This logon-specific information cannot be determined by the Effective Permissions tool, since the user is not logged on; therefore, the effective permissions it displays reflect only those permissions specified by the user or group and not the permissions specified by the logon.
  • For example, if a user is connected to this computer through a shared folder, then the logon for that user is marked as a network logon. Permissions can be granted or denied to the well-known security ID (SID) Network which the connected user receives, so a user has different permissions when logged on locally than when logged on over a network.
  • For information about granting access for effective permissions, see article 331951 in the Microsoft Knowledge Base ().

For information about using the Effective Permissions tool, see View Effective Permissions on Files and Folders.

Additional references

  • Manage Permissions


Set, View, Change, or Remove Permissions on an Object

Permissions on objects can be modified or viewed using the access control list user interface.

  • Set, View, Change, or Remove Permissions on Files and Folders

  • View Effective Permissions on Files and Folders

  • Set, View, Change, or Remove Special Permissions

  • Set Permissions on a Shared Resource


Set, View, Change, or Remove Permissions on Files and Folders

When a file or folder is created, Windows assigns default permissions to that object.

Modify is the minimum permission required to complete this procedure. Review the details in "Additional considerations" in this topic.

To set, view, change, or remove permissions on files and folders

  1. Right-click the file or folder for which you want to set permissions, click Properties, and then click the Security tab.

  2. Click Edit to open the Permissions for <Object> dialog box.

  3. Do one of the following:

    • To set permissions for a group or user that does not appear in the Group or user names box, click Add. Type the name of the group or user you want to set permissions for and then click OK.

    • To change or remove permissions from an existing group or user, click the name of the group or user.

  4. Do one of the following:

    • To allow or deny a permission, in the Permissions for <User or Group> box, select the Allow or Deny check box.

    • To remove the group or user from the Group or user names box, click Remove.

Additional considerations

  • For a description of all permissions, see Permission Entry Dialog Box.

  • Performing this procedure might require you to elevate permissions through User Account Control.

  • To open Windows Explorer, click Start, point to All programs, point to Accessories, and then click Windows Explorer.

  • You can only set file and folder permissions on drives formatted to use NTFS.

  • To change permissions, you must be the owner or have been granted permission to do so by the owner.

  • Groups or users that are granted Full Control for a folder can delete files and subfolders within that folder, regardless of the permissions that protect the files and subfolders.

  • If the check boxes under Permissions for <User or Group> are shaded or if the Remove button is unavailable, the file or folder has inherited permissions from the parent folder.

  • When adding a new user or group, by default, this user or group will have Read & Execute, List Folder Contents, and Read permissions.

Additional references

  • View Effective Permissions on Files and Folders

  • Set, View, Change, or Remove Special Permissions

  • File and Folder Permissions


View Effective Permissions on Files and Folders

When a file or folder is created, Windows assigns default permissions to that object or the creator can assign specific permissions.

Read is the minimum permission required to view effective permissions. Review the details in "Additional considerations" in this topic.

To view effective permissions on files and folders

  1. Open Windows Explorer, and then locate the file or folder for which you would like to view effective permissions.

  2. Right-click the file or folder, click Properties, and then click the Security tab.

  3. Click Advanced, click the Effective Permissions tab, and then click Select.

  4. In Enter the object name to select (examples), enter the name of a user or group, and then click OK. The selected check boxes indicate the effective permissions of the user or group for that file or folder.

Additional considerations

  • To open Windows Explorer, click Start, point to All programs, point to Accessories, and then click Windows Explorer.

  • If the specified object grants access to the Everyone group, the Authenticated Users group, or the Local Users group, the effective rights always includes those permissions, except when the specified user or group is the Anonymous group. This version of Windows does not include the Anonymous users in the Everyone group.

  • The Effective Permissions tab shows information that is calculated from the existing permissions entries. Therefore, the information displayed on that page is read-only and does not support changing a user's permissions by selecting or clearing permission check boxes.

  • Permissions are set only on drives formatted to use NTFS when using the access control user interface.

  • Share permissions are not part of the effective permissions calculation. Access to shared folders can be denied through share permissions even when access is allowed through NTFS permissions.

Additional references

  • File and Folder Permissions


Set, View, Change, or Remove Special Permissions

Each object has permissions associated with it which can restrict access. You can modify those special permissions to define the access on a particular object.

You must be the owner of the object or have been granted permission by the owner to complete this procedure. Review the details in "Additional considerations" in this topic.

To set, view, change, or remove special permissions

  1. Right-click the object you want to set advanced or special permissions on, click Properties, and then click the Security tab.

  2. Click Advanced, and then click Edit.

  3. On the Permissions tab, do one of the following:

    • Set special permissions for an additional group or user.

      Click Add. In Enter the object name to select (examples), type the name of the user or group, and then click OK.

    • View or change special permissions for an existing group or user.

      Click the name of the group or user, and then click Edit.

    • Remove an existing group or user and its special permissions.

      Click the name of the group or user and then click Remove. If the Remove button is unavailable, clear the Include inheritable permissions from this object's parent check box, and then click Remove.

  4. In the Permissions box, select or clear the appropriate Allow or Deny check boxes.

  5. In the Apply onto box, click the folders or subfolders you would like these permissions to be applied to.

  6. To configure security so that the subfolders and files will not inherit these permissions, clear the Apply these permissions to objects and/or containers within this container only check box.

  7. Click OK, and then, in Advanced Security Settings for <ObjectName>, click OK.
Caution

If you select the Include inheritable permissions from this object's parent check box, then all subfolders and files will have all of their permission entries reset to those inheritable from the parent object. Implicit permissions will be removed and, if the object was "protected" from automatic inheritance, protection will be removed as well. Once you click Apply or OK, you cannot undo this operation by clearing the check box.

Additional considerations

  • Groups or users that have been granted Full Control for a folder can delete files and subfolders within that folder, regardless of the permissions that protect the files and subfolders.

  • Performing this procedure might require you to elevate permissions through User Account Control.

  • To open Windows Explorer, click Start, point to All programs, point to Accessories, and then click Windows Explorer.

  • The Everyone group no longer includes the Anonymous Logon permission.

  • If you clear the Include inheritable permissions from this object's parent. check box, then this file or folder will not inherit permission entries from the parent object.

  • You can set NTFS permissions only on drives formatted to use NTFS.

  • If the check boxes under Permissions are shaded, the permissions are inherited from the parent folder.

Additional references

  • Determine Where to Apply Permissions


Set Permissions on a Shared Resource

A shared resource is a resource that is made available to network users, such as folders, files, printers, and named pipes. It can also refer to a resource on a server that is available to network users. When you share a resource, you use Share permissions instead of NTFS permissions.

Important

Share permissions apply only to users who gain access to the resource over the network. They do not apply to users who log on locally, such as on a terminal server. To restrict access to objects for users who log on locally, set NTFS permissions on the Security tab of the object's Properties page.

Setting permissions on a shared resource

There are two methods to set permissions on a shared resource, depending on the resource type.

  • Using the File Sharing Wizard to set permissions of a file or folder

    You can start the File Sharing wizard by right-clicking the file or folder, and then clicking Share.

    The wizard allows you to select the user and group which can share the file or folder, and allows you to set permissions on the file or folder for each user or group.

  • Using Windows Explorer to set permissions on a resource

    You can use Windows Explorer to set permissions through the Share option or through the Properties page on a resource. When you right-click the object, selecting the Share or Properties option displays the Properties dialog box. Permissions can be set or modified by using the Advanced Sharing button on the Sharing tab.

Additional considerations

  • To open Windows Explorer, click Start, point to All programs, point to Accessories, and then click Windows Explorer.

  • You can use File Sharing to manage shared resources on both local and remote computers. With Windows Explorer and the command line, you can manage shared resources on your local computer only.

  • When permissions have been assigned both to the shared resource and at the file system level, the more restrictive permission always applies.

  • It is usually easier to assign permissions to groups and then add users to groups, rather than assigning identical permissions to individual users.

  • If you change permissions on special shared resources, such as ADMIN$, the default settings may be restored when the Server service is stopped and restarted or when the computer is restarted. Note that this does not apply to user-created shared resources whose share name ends in $.


Manage Object Ownership

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

Important

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

By default, the owner is the entity which created the object. The owner can always change permissions on an object, even when denied all access to the object.

Ownership can be taken by:

  • An administrator. By default, the Administrators group is given the Take ownership of files or other objects user right.

  • 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 if that user is a member of a group defined in the current owner's access token. 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 double-click Other users and groups and choose any user or group to assign ownership to.

Additional references

  • Take Ownership of a File or Folder


Take Ownership of a File or Folder

The owner of the object controls how permissions are set on the object and to whom permissions are granted.

The Take ownership permission on an object or the Restore files and directories user right are the minimum requirements to complete this procedure. Review the details in "Additional considerations" in this topic.

To take ownership of a file or folder

  1. Open Windows Explorer, and then locate the file or folder you want to take ownership of.

  2. Right-click the file or folder, click Properties, and then click the Security tab.

  3. Click Advanced, and then click the Owner tab.

  4. Click Edit, and then do one of the following:

    • To change the owner to a user or group that is not listed, click Other users and groups and, in Enter the object name to select (examples), type the name of the user or group, and then click OK.

    • To change the owner to a user or group that is listed, in the Change owner to box, click the new owner.

  5. (Optional) To change the owner of all subcontainers and objects within the tree, select the Replace owner on subcontainers and objects check box.

Additional considerations

  • An administrator can take ownership of any file on the computer.

  • Assigning ownership of a file or a folder might require you to elevate your permissions using User Access Control.

  • To open Windows Explorer, click Start, point to All programs, point to Accessories, and then click Windows Explorer.

  • You can transfer ownership in two ways:

    • The current owner can grant the Take ownership permission to others, allowing those users to take ownership at any time. A user granted the Take ownership permission can take ownership of the object or assign ownership to any group that the user is a member of.

    • A user who has the Restore files and directories privilege can double-click Other users and groups and choose any user or group to assign ownership to.

  • The Everyone group no longer includes the Anonymous Logon group.

Additional references

  • Manage Object Ownership


Manage Security Auditing

Monitoring the creation or modification of objects gives you a way to track potential security problems, helps to ensure user accountability, and provides evidence in the event of a security breach.

The most common types of events to be audited are:

  • Access to objects, such as files and folders.

  • Management of user accounts and group accounts.

  • Users logging on to and logging off from the system.

This section contains:

  • Audit Policies

  • Define or Modify Auditing Policy Settings for an Event Category

  • Apply or Modify Auditing Policy Settings for a Local File or Folder

  • View the Security Log


Audit Policies

Before you implement auditing, you must decide on an auditing policy. An auditing policy specifies categories of security-related events that you want to audit. When this version of Windows is first installed, all auditing categories are disabled. By enabling various auditing event categories, you can implement an auditing policy, one that suits the security needs of your organization.

The event categories that you can choose to audit are:

  • Audit account logon events

  • Audit account management

  • Audit directory service access

  • Audit logon events

  • Audit object access

  • Audit policy change

  • Audit privilege use

  • Audit process tracking

  • Audit system events

If you choose to audit access to objects as part of your audit policy, you must enable either the audit directory service access category (for auditing objects on a domain controller), or the audit object access category (for auditing objects on a member server or workstation). Once you have enabled the object access category, you can specify what types of access you would like to audit for each group or user.

To enable auditing of local objects, you must be logged on as a member of the Built-in Administrators group.


Define or Modify Auditing Policy Settings for an Event Category

The auditing settings that you choose for the event categories define your auditing policy. On member servers and workstations that are joined to a domain, auditing settings for the event categories are undefined by default. On domain controllers, auditing is turned on by default. By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization. For more information and a list of event categories, see Audit Policies.

Defining or modifying auditing policy settings for an event category

  • For your local computer

  • For a domain or organizational unit, when you are on a member server or on a workstation that is joined to a domain

Local Administrator is the minimum group membership required to complete this procedure.

To define or modify auditing policy settings for an event category for your local computer

  1. Open the Local Group Policy Object Editor snap-in and select Local Computer.

  2. In the console tree, click Audit Policy.

    Where?

    • Local Computer Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy

  3. In the results pane, double-click an event category that you want to change the auditing policy settings for.

  4. Do one or both of the following, and then click OK.

    • To audit successful attempts, select the Success check box.

    • To audit unsuccessful attempts, select the Failure check box.

Additional considerations

  • To open the Local Computer Policy snap-in, open Microsoft Management Console (MMC). In the File menu, click Add/Remove Snap-in, select Local Group Policy Object Editor from the list of snap-ins, and then click Add. From the Group Policy Wizard, keep Local Computer in the Group Policy Object box, and then click Finish.

Domain Admins is the minimum group membership required to complete this procedure.

To define or modify auditing policy settings for an event category for a domain or organizational unit, when you are on a member server or on a workstation that is joined to a domain

  1. If the Group Policy Management Console (GPMC) is not installed, open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the Group Policy Management Console was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Audit Policy.

  7. In the results pane, double-click an event category that you want to change the auditing policy settings for.

  8. If you are defining auditing policy settings for this event category for the first time, select the Define these policy settings check box.

  9. Do one or both of the following, and then click OK.

    • To audit successful attempts, select the Success check box.

    • To audit unsuccessful attempts, select the Failure check box.

Additional considerations

  • To open the Microsoft Management Console through the Windows interface, click Start, click in the Start Search text box, type mmc, and then press ENTER.

  • To audit object access, enable auditing of the object access event category by following the steps above. Then, enable auditing on the specific object.

  • After your audit policy is configured, events will be recorded in the Security log. Open the Security log to view these events.

  • The default auditing policy setting for domain controllers is No Auditing. This means that even if auditing is enabled in the domain, the domain controllers do not inherit auditing policy locally. If you want domain auditing policy to apply to domain controllers, you must modify this policy setting.


Apply or Modify Auditing Policy Settings for a Local File or Folder

You can apply audit policies to individual files and folders on your computer by setting the permission type to record in the security log successful access attempts or failed access attempts.

Local Administrator is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To apply or modify auditing policy settings for a local file or folder

  1. Open Windows Explorer.

  2. Right-click the file or folder that you want to audit, click Properties, and then click the Security tab.

  3. Click Edit, and then click Advanced.

    Note

    If you are not logged on as a member of the Administrator group on this computer, you must provide your Administrator logon credentials to proceed.

  4. On the Advanced Security Settings for <object> dialog box, click the Auditing tab.

  5. Do one of the following:

    • To set up auditing for a new user or group, click Add. In Enter the object name to select, type the name of the user or group that you want, and then click OK.

    • To remove auditing for an existing group or user, click the group or user name, click Remove, click OK, and then skip the rest of this procedure.

    • To view or change auditing for an existing group or user, click its name, and then click Edit.

  6. In the Apply onto box, click the location where you want auditing to take place.

  7. In the Access box, indicate what actions you want to audit by selecting the appropriate check boxes:

    • To audit successful events, select the Successful check box.

    • To stop auditing successful events, clear the Successful check box.

    • To audit unsuccessful events, select the Failed check box.

    • To stop auditing unsuccessful events, clear the Failed check box.

    • To stop auditing all events, click Clear All.

  8. If you want to prevent subsequent files and subfolders of the original object from inheriting these audit entries, select the Apply these auditing entries to objects and/or containers within this container only check box.
Important

Before setting up auditing for files and folders, you must enable object access auditing by defining auditing policy settings for the object access event category. If you do not enable object access auditing, you will receive an error message when you set up auditing for files and folders, and no files or folders will be audited.

Additional considerations

  • You must be logged on as a member of the Administrators group or you must have been granted the Manage auditing and security log right in Group Policy to perform this procedure.

  • To open Windows Explorer, click Start, point to All programs, point to Accessories, and then click Windows Explorer.

  • After object access auditing is enabled, view the security log in Event Viewer to review the results of your changes.

  • You can set up file and folder auditing only on NTFS drives.

  • If you see the following:

    • In the Auditing Entry for <File or Folder> dialog box, in the Access box, the check boxes are unavailable ...

    • In the Advanced Security Settings for <File or Folder> dialog box, the Remove button is unavailable ...

    auditing has been inherited from the parent folder.

  • Because the security log is limited in size, select the files and folders to be audited carefully. Also, consider the amount of disk space that you want to devote to the security log. The maximum size for the security log is defined in Event Viewer.

Additional references

  • Advanced Security Settings Properties Page - Auditing Tab


View the Security Log

The Security log records each event as defined by the audit policies you set on each object.

To view the Security log

  1. Open Event Viewer.

  2. In the console tree, open Global Logs, and then click Security. The results pane lists individual security events.

  3. If you want to see more details about a specific event, in the results pane, double-click the event.

Additional considerations

  • To open Event Viewer, click Start, click Control Panel, click System and Maintenance, double-click Administrative Tools, and then double-click Event Viewer.

  • If your computer is connected to a network, network policy settings might also prevent you from completing this procedure.


Resources for Access Control

For more information about access control, see the following resources on the Microsoft Web site:

  • Authorization and Access Control Technologies (http://go.microsoft.com/fwlink/?LinkId=63965)

  • Designing a Resource Authorization Strategy (http://go.microsoft.com/fwlink/?LinkId=63966)

  • Microsoft Technical Security Notifications (http://go.microsoft.com/fwlink/?LinkId=63967)

  • Auditing Security Events (http://go.microsoft.com/fwlink/?LinkId=63968)

  • Troubleshooting Access Control (http://go.microsoft.com/fwlink/?LinkId=63969)


User Interface: Access Control

  • Select Users, Computers, or Groups Dialog Box

  • Object Types Dialog Box

  • Select Users, Computers, or Groups Dialog Box - Advanced Page

  • Advanced Security Settings Properties Page - Permissions Tab

  • Permission Entry Dialog Box

  • Advanced Security Settings Properties Page - Auditing Tab

  • Advanced Security Settings Properties Page - Owner Tab

  • Learn more about access control and permissions

  • Auditing Entry Dialog Box

  • Access Control and User Account Control


Select Users, Computers, or Groups Dialog Box

Item | Details
Object Types | Click to choose the types of objects that you want to select. For more information about object types, see Object Types Dialog Box
Locations | Click to define the root location from which to begin your search.
Check Names | Locates all matching or similar object names listed in the Enter the object names to select text box using the selected object types and directory location.
Enter the object names to select (examples) | Provides a space for you to type the object names that you want to find. You can search for multiple objects by separating each name with a semicolon. Use one of the following syntax examples: DisplayName (example: FirstName LastName) ObjectName (example: Computer1) UserName (example: User1) ObjectName@DomainName (example: User1@Domain1) DomainName\ObjectName (example: Domain1\User1)
Advanced | Click to select advanced search options. For more information about advanced search options, see Select Users, Computers, or Groups Dialog Box - Advanced Page


Object Types Dialog Box

You can access the Object Types dialog box by clicking Object Types in the Select Users, Computers, or Groups dialog box. The Object Types dialog box lists the available object types that you can look for. This list can include one or more of the following types of objects.

Object Type | Details
Built-in security principals | Objects that represent default built-in groups and foreign security principals. Examples include: Administrators, System Operators, Users, Power Users, Everyone, Authenticated Users, Anonymous Logon, Guests, and System.
Computers | Objects used to represent a computer’s access to network resources.
Groups | Objects that can have users, computers, and other groups as its members.
Users | Objects used to allow people to access network resources.
Contacts | Objects used to locate information about people. Contact objects cannot be assigned permissions and therefore do not have access to network resources.
Other | Objects that can be created by applications.


Select Users, Computers, or Groups Dialog Box - Advanced Page

Item | Details
Object Types | Click to choose the types of objects that you want to select. For more information about object types, see Object Types Dialog Box.
Locations | Click to define the root location from which to begin your search.
Columns | Click to change the columns shown in the Search results list for this view.
Find Now | Click to start your search. If you want to search for all objects specified in Object types and Locations, do not enter any search values, and then click Find Now. Note that this type of search could require significant network resources depending on the scope of the search. To minimize the impact on network resources, specify search values.
Stop | Click to stop your search. Objects found up to the point of stopping the search will be displayed.
Name | Lists the search variables used to find user, computer, or group names and provides a space for you to type the name of the query.
Description | Lists the search variables used to find user, computer, or group descriptions and provides a space for you to type a description of the query.
Disabled accounts | Specifies whether the search will include disabled accounts.
Non expiring password | Specifies whether the search will include user accounts with non-expiring passwords.
Days since last logon | Specifies the number of days that users within the specified query root last logged on to the domain.
Search results | Lists the results of the search for user, computer, or group names by the columns you choose.


Permission Entry Dialog Box

Folder permissions include Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. For information about these permissions, see File and Folder Permissions. Each of these permissions consists of a logical group of special permissions which are listed and defined below. Not all of the special permissions will apply to all objects.

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 for 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 within that folder.

List Folder/Read Data

List Folder allows or denies viewing file names and subfolder names within the folder. List Folder only affects the contents of that folder and 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 within 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 within 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. In order 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. In order 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.
Note

You will not be able to access an encrypted file without the Encrypting File System (EFS) key, even if you have the necessary permissions.

Additional references

  • What are Permissions?

  • File and Folder Permissions

  • Determine Where to Apply Permissions

  • Take Ownership of a File or Folder


Advanced Security Settings Properties Page - Auditing Tab

Requirements for Auditing Object Access

Establishing audit policy is an important facet of security. Monitoring the creation or modification of objects gives you a way to track potential security problems, helps to ensure user accountability, and provides evidence in the event of a security breach.

The most common types of events to be audited are:

  • Access to objects, such as files and folders.

  • Management of user accounts and group accounts.

  • Users logging on to and logging off from the system.

When you implement audit policy:

  • If you want to audit directory service access or object access, determine which objects you want to monitor access of and what type of access you want to monitor. For example, if you want to audit any attempts by users to open a particular file, you can configure auditing policy settings in the object access event category so that both successful and failed attempts to read a file are recorded.

  • Specify the categories of events that you want to audit. Examples of event categories are user logon, user logoff, and account management. The event categories that you select constitute your audit policy. For more information about each event category, see Audit Policies.

  • Set the size and behavior of the Security log. You can view the Security log with Event Viewer.

You can have one or more auditing entry for the same user or group depending on the type of auditing, where it was inherited from, the type of access, and what it will be applied to.

Item Description

Object name

Names the currently selected object.

Auditing entries

Displays each auditing entry for this object:

  • Type - The result on which to apply the audit policy. This can be Success, Fail, or All. Type is set by permission access.

  • Name - Name of object to apply audit policies

  • Access - Permission types, such as Full control, Traverse folder / execute file, Read attributes, Delete. Includes file and folder permissions, Active Directory object permissions, and file server permissions.

  • Inherited from - Object from which permissions are inherited. You can include inheritable auditing entries from the object's parent if one exists by selecting the check box on this dialog box.

  • Apply To - Those child objects to which the permissions are also applied

Include inheritable auditing entries from this object's parent

When selected, inheritable auditing entries from the object's parent will be written to the Security log.

Replace all existing inheritable auditing entries on all descendants with inheritable auditing entries from this object

When selected, auditing settings on this parent object will replace those on its descendant objects.

When deselected, auditing settings on each object, whether parent or its descendant, can be unique.

Additional references

  • Manage Permissions

  • Apply or Modify Auditing Policy Settings for a Local File or Folder


Advanced Security Settings Properties Page - Owner Tab

Object Ownership

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

Important

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

By default, the owner is the entity which created the object. The owner can always change permissions on an object, even when denied all access to the object.

Ownership can be taken by:

  • An administrator. By default, the Administrators group is given the Take ownership of files or other objects user right.

  • 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 double-click Other users and groups and choose any user or group to assign ownership to.

Item | Description
Object name | Currently selected object
Current owner | User or Group that owns the object
Change owner to | Users or Groups that can be granted ownership, or select Other users or groups to select additional choices from the computer or network

Additional references

  • Take Ownership of a File or Folder


Learn more about access control and permissions

Access Control

In order to secure a computer and its resources, you must take into consideration what rights users will have. You can secure a computer or multiple computers by granting users or groups specific user rights. You can secure an object, such as a file or folder, through assigning permissions to allow users or groups to perform specific actions on that object.

Item Description

Object name

Names the currently selected object.

Group or user names

Displays a list of groups or users that have been granted access to this computer.

Edit

Allows modification of security settings on this object.

Note

If this button is UAC protected, you might not be able to modify any security settings. However, you can at least view them by using the Advanced button.

Permissions for

Displays a list of Allow and Deny permissions in effect for each group or user selected.

Additional references

  • Access Control Overview

  • Manage Permissions


Advanced Security Settings Properties Page - Permissions Tab

Advanced Security Settings on Permissions

You can add additional resources, groups or users to have explicit NTFS permissions to access this object, or you can edit or remove the NTFS permissions granted to a resource, group or user on the object. For the access limitations for each set of NTFS permissions, see File and Folder Permissions.

Inherited permissions are those that are propagated to an object from a parent object. Inherited permissions ease the task of managing permissions and ensure consistency of permissions among all objects within a given container. For more information about the effects of inherited permissions, see How Inheritance Affects File and Folder Permissions.

Item Description

Object name

Names the currently selected object.

Permission entries

Displays each permission entry for this object:

  • Type - Either Allow or Deny this group or user this permission for this object

  • Name - Resource, user or group

  • Permission - Restrictions currently applied to this object for this resource, user or group

  • Inherited from - Identifies the parent object

  • Apply To - Identifies any descendant objects to which the permissions are also applied

Include inheritable permissions from this object's parent

When selected, each child object will have permissions inherited from its parent object.

When deselected, the permissions applied on the parent object will no longer be applied to its child object or objects.

Replace all existing inheritable permissions on all descendants with inheritable permissions from this object.

When selected, permissions on this parent object will replace those on its descendant objects.

When deselected, permissions on each object, whether parent or its descendant, can be unique.


Auditing Entry Dialog Box

Each object has a set of security information, or security descriptor, attached to it. Part of the security descriptor specifies the groups or users that can access an object and the types of access (permissions) that are granted to those groups or users. This part of the security descriptor is known as a discretionary access control list (DACL).

A security descriptor for an object also contains auditing information. This auditing information is known as a system access control list (SACL). More specifically, a SACL specifies the following:

  • The group or user accounts to audit when they access the object.

  • The operations to be audited for each group or user, for example, modifying a file.

  • A Success or Failure attribute for each access event, based on the permissions that are granted to each group and user in the object's DACL.

You can apply auditing to an object, and, through inheritance, the auditing can apply to any child objects. For example, if you want to audit failed access to a folder, this auditing event can be inherited by all files within the folder.

To audit files and folders, you must be logged on as a member of the Administrators group.

Item | Description
Apply onto | The object or all the parent and child relationships of that object. You can also apply the auditing entries to objects or containers within the container.
Access | The type of access permitted as listed by each individual permission.
Successful | Apply onto this object when accessed successfully for each individual permission.
Failed | Apply onto this object when access fails for each individual permission.

Additional references

  • Audit Policies

  • Define or Modify Auditing Policy Settings for an Event Category

  • View the Security Log


Access Control and User Account Control

Viewing and editing an object’s security properties is an operation that requires administrative credentials or ownership of the object. The shield icon on the Continue button indicates that the intended operation requires elevated permissions to proceed. This is enabled by User Account Control (UAC).

How User Account Control Works with Access Control

In this version of Windows, UAC allows you to perform common tasks as non-administrators, called standard users, without having to switch users, log off, or use Run as administrator to elevate your permissions. A standard user account is the equivalent of a user account in Windows XP. If your account is a member of the local Administrators group, UAC will allow most applications to run under the standard user account.

UAC provides the means to elevate your permissions so that you are able to continue to view or edit security properties by using the access control user interface. Therefore, you might be required to provide administrative credentials when you are already logged in as a standard user. Or, when you are logged in as an administrator, you might be prompted to provide your consent to proceed, or you might be prompted to enter your credentials.

Note

In some cases, you might not be able to view the object's security properties even if you have administrative credentials. This is because the object's security permissions do not grant the required access even to administrators. In this case, you need to take ownership of the object. For more information about taking object ownership, see Take Ownership of a File or Folder.