This documentation is archived and is not being maintained.

Access Control

Visual Studio .NET 2003

Windows NT, Windows 2000, Windows XP, and Windows Server 2003 all share a common access-control model that is based on the following:

  • User-based authorization - Code processes within the security context of the user launching that code. It cannot do anything that user cannot do.
  • Discretionary access to securable objects - The owner of an object, such as a file or a folder, can grant or deny permission to control how that object is used and by whom.
  • Inheritance of permissions - Objects can inherit permissions from the object that contains them, such as a file object that inherits the permissions of the folder object in which it is contained.
  • Administrative privileges - You can control which users or groups can perform administrative functions and make changes that affect system-wide resources.
  • Auditing of system events - You can use the auditing features to detect security circumvention attempts or, to create an audit trail.

A security principal is any entity that can execute code. Security principals can be either users or, programs acting on behalf of a user or computer. Processes such as Windows services usually run in the context of special security identities, such as the LocalSystem account.

A Security Identifier (SID) is a unique value of variable length used to identify a security principal or security group.

The Local Security Authority (LSA) is a protected subsystem of Windows that maintains the information about all aspects of local security on a computer.

The security context is the user-account information that the system uses to enforce security when a process tries to access a secured object, such as a file. The security context includes such things as the user's SID, group membership SIDs, and privileges. Security principals establish a security context for their actions by presenting credentials from a trusted security authority, such as a domain controller, that is recognized by the LSA on the computer where the principal intends to act.

An access token is a data structure, which is attached to the principal and used by the thread executing code on that principal's behalf. It provides a complete description of the security context for a process or thread. It includes an extensive amount of information, such as the SID for the user's account, a list of SIDs for security groups of which the user is a member, and a list of privileges held on the local computer by the user and by the user's security groups.

An Access Control List (ACL) is an ordered list of access control entries (ACEs) that define the protections that apply to an object and its properties. Each ACE identifies a security principal and specifies a set of access rights allowed, denied, or audited for that security principal. Attached to each securable object is a security descriptor that can contain two kinds of ACLs:

  • Discretionary Access Control Lists (DACLs) - identify users and groups that are allowed or denied varying types of access (such as Read, Read/Write, and so on) to the secured object.
  • System Access Control Lists (SACLs) - control how access is audited by the operating system.

The operating system performs access checking whenever a security principal requests to perform a particular action on a secured object. The goal of an access check is to determine whether the security principal has the necessary access rights to perform the requested action on that object. To make this determination, the operating system evaluates the SIDs in the access token against the ACEs in the DACL for the secured object. If the access token has sufficient rights, the operating system permits the action. Otherwise, the operating system raises an access denied error.

See Also

Security Model