Q: In the Windows authorization process, what do the terms access token, security descriptor, and impersonation mean, and what's the relationship between these concepts?

A: Windows authorization always deals with two entities - as illustrated in Figure 1: a subject and an object that the subject wants to access.

A subject can be a security principal, such as a user, computer, or application. The object can be file resources hosted on a file server, printer queues on a print server, Active Directory (AD) objects in the AD database on a Domain Controller (DC), or any other object that's kept in a Windows IT infrastructure. Authorization between the subject and the object is governed and enforced by a third entity that is referred to as the reference monitor. In Windows OSs, this third entity is called the Security Reference Monitor (SRM). The SRM is the authorization authority on a Windows box. It is a process that runs in the highly privileged OS kernel mode and that checks all access to resources located on a Windows system.

Windows Authorization and the SRM deal with access to visible Windows objects, such as files, printers, registry keys, and AD objects, and with access to less visible objects, such as system processes and threads. Authorization also controls the ability to perform system-related tasks, such as changing the system time or shutting down the system. Microsoft calls these system-related tasks user rights.

Under the hood the Windows authorization model in is based on the key concepts of access tokens, access masks, security descriptors, and impersonation. Figure 2 shows how these concepts are brought together.

The figure shows how, upon every object access, the SRM checks the access token and the access mask against an object's security descriptor. The access token and access mask are both linked to a process that impersonates a user. Here's a closer look at the terms involved:

·         Impersonation means that a process acts on behalf of a user.

·         The access token contains a user's access control data such as group memberships and user rights.

·         The access mask tells the SRM what the process wants to do with the resource (for example, reading a file or writing to a file). At the end of the authorization decision making process, the SRM returns another access mask, called the "granted" access mask to inform the process of what it can do with the resource.

·         The security descriptor of an object tells the SRM who can do what with this particular object.

In the Windows authorization model, a user never accesses a resource directly—there's always a server process that acts on behalf of a user. This process is known in Windows terminology as impersonation. When a process impersonates a user, it means that it runs in the security context of the user and that it uses the user's authorization attributes.

To allow Windows to associate a user's authorization data (the user's rights and group memberships) with every process that's started by the user, Windows uses an object called the access token. Access tokens are linked to a user's logon session. They're generated on every machine that the user logs on to. An access token is always local to a machine and never travels across the network. The OS component that generates access tokens is the Local Security Authority (LSA). Besides the user's domain authorization data (stored in AD), an access token also contains the user's local authorization data. The latter is the authorization data that are stored in a system's local security database (the SAM): they include a user's local group memberships and local user rights. To look at the content of your Windows access token (including group memberships and user rights), you can use the whoami tool with the /all switch.

The main authorization attribute on the object side is called a security descriptor. A security descriptor tells the authorization system who can do what with the object. Every object that has a security descriptor linked to it is called a securable object. Securable objects can be shared between different users, and every user can have different authorization settings. Examples of securable objects include a file, a folder, a file system share, a printer, a registry key, an AD object, and a service. The security descriptor of a file system object is stored in the NTFS file system. The security descriptor of an AD object is stored in the object's nTSecurityDescriptor attribute. Note that the nTSecurityDescriptor attribute is also replicated to the Global Catalog, which ensures that access to AD objects will be secured even if the object is replicated outside its domain boundary to GCs in other domains.

Every object's security descriptor contains a set of Access Control Lists (ACLs). An ACL is composed of multiple Access Control Entries (ACEs)—an ACE is also referred to as a permission. An ACE links a security identity (SID) to an access right (for example, read, write, delete, execute). Typical examples of permissions are "Joe can read the monthly expense claim report," or "Alice can print on the human resource department printer." In a security descriptor, an access right is represented using a hexadecimal value called the access mask.

Every security descriptor contains two types of ACLs: discretionary and system ACLs.

·       Discretionary ACLs (DACLs) contain ACEs that are set by the owner of an object. They are called discretionary because their content is set at the object owner's discretion. Ownership is a key concept in the Windows security model. It's a very powerful concept because the owner of an object is always granted the right to manage the object's permissions. By default, the object owner is the Windows user account that created the object. In the case in which a domain administrator or a member of the local administrators group creates an object, by default the Domain Admins or Administrators groups become the object owner. To look at an object's discretionary ACLs from the Windows GUI, you typically use the ACL editor, which you can access from the Security tab in an object's properties. To look at the DACLs of a file system object from the command prompt, you can use the cacls tool.

·       System ACLs (SACLs) contain an object's auditing settings and are set by an administrator. They're non-discretionary—they're not related in any way to the owner of an object. To look at an object's SACL from the Windows GUI, you use the ACL editor.

In addition to the DACLs and SACLs, an object's security descriptor also contains two other fields:

·       The Owner SID field, which holds the SID of the owner of the object.

·       The Primary group SID field, which holds the SID of the object owner's primary group that is used for Posix and Macintosh access control management compatibility.