To understand and manage access control, you need to understand the relationship between:

• Objects (files, printers, and other resources)
  
  
• Access tokens
  
  
• Access control lists (ACLs) and access control entries (ACEs)
  
  
• Subjects (users or applications)
  
  
• The operating system
  
  
• Permissions
  
  
• User rights and privileges
  
  

Before a subject can gain access to an object, the subject must identify itself to the security subsystem for the operating system. This identity is contained within an access token that is re-created every time a subject logs on. Before allowing the subject to access an object, the operating system checks to determine whether the access token for the subject is authorized to access the object and complete the desired task. It does this by comparing information in the access token with access control entries (ACEs) for the object.

ACEs can allow or deny a number of different behaviors, depending on the type of object. For example, options on a file object can include Read, Write, and Execute. On a printer, the ACEs that are available include Print, Manage printers, and Manage documents.

Individual ACEs for an object are combined in an access control list (ACL). The security subsystem checks the object's ACL for ACEs that apply to the user and the groups that the user belongs to. It steps through each ACE until it finds one that either allows or denies access to the user or one of the user's groups, or until there are no more ACEs to check. If it comes to the end of the ACL and the desired access is still not explicitly allowed or denied, the security subsystem denies access to the object.

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 Managing 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.

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 Policy snap-in under Local Policies\User Rights Assignment. For more information, see User Rights and Privileges.

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 Policy\Audit Policy\Local Policies in the Local Security Policy snap-in. You can then view these security-related events in the Security log in Event Viewer.

Additional references

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