10.2 The Windows authorization model

Although Windows Server 2003 includes quite a few new authorization features, the authorization model is basically the same as the one that was used in Windows 2000 and NT4. It is based on the following key concepts: access token, access mask, security descriptor, and impersonation.

Figure 10.2 brings the different Windows authorization concepts together. It shows how upon every object access, the security reference monitor (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. Let’s have a closer look at the these key authorization concepts.

Figure 10.2: Windows authorization model.

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

• The access token contains a user’s authorization data (such as group memberships and user rights).

• The access mask tells the SRM what the process wants to do with the resource (e.g., read a file? write to a file?).

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

Based on the outcome of the authorization comparison process, the SRM decides if the process can access the resource. To inform the process of what it can do with the resource, the SRM will return another access mask, the granted access mask. In the following section we will examine these key concepts more in detail and link them to the subject and object we introduced in Section 10.1.

To allow the operating system to associate a user’s authorization data (the user’s rights and group memberships, explained next) with every process that is started by the user, Windows uses an object called the access token. Access tokens are linked to a user’s logon session. They are generated on every machine to which the user logs on, independent of the logon type (interactive, network, and so forth). An access token is always local and never travels across the network. The operating system component that generates access tokens is the Local Security Authority (LSA). Besides the user’s domain authorization data, an access token also contains the user’s local authorization data. The latter are the authorization data that are stored in a system’s local security database (the SAM): It includes a user’s local group member- ships and local user rights. A complete overview of all the fields in the access token can be found in the Windows Server 2003 resource kit or the Microsoft Windows platform SDK. To look at the content of your Windows access token (including group memberships and user rights), use the whoami tool with the /all switch (as illustrated in Figure 10.3).

Figure 10.3: Using whoami /all to look at the access token content.

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 are a file, a folder, a file system share, a printer, a registry key, an AD object, and a service. The security descriptor of an AD object is stored in the object’s nTSecurityDescriptor attribute (which is also replicated to the Global Catalog). The security descriptor of a file system object is stored in the NTFS file system.

Every object’s security descriptor contains a set of Access Control Lists (ACLs), illustrated in Figure 10.4. 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 (e.g., 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.”

Figure 10.4: Access control list (ACL) content.

In a security descriptor, an access right is represented using a hexadecimal value called the access mask. Table 10.1 shows some access mask values and their meaning. If an access right is made up of multiple access rights, then the associated access mask value will be the sum of the individual access rights. For example, an access right holding the read and write access right will have an access mask of 0x60000.

Table 10.1: Typical Windows Access Masks and Their Meaning

Access Mask Values	Meaning (Associated Access Right)
0x10000	Delete
0x20000	Read
0x40000	Write

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 is 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. This behavior can be changed in Windows Server 2003 thanks to the following GPO setting (part of the Security Options): “System objects: default owner for objects created by members of Administrators group.” This GPO setting affects the nodefaultadminowner (REG_DWORD) registry value that’s located in the HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Control\Lsa registry key.

  An account can take ownership of an object if it has the modify owner permission on the object or if it has the Take ownership of files or other user objects user right—by default, this right is given to members of the Administrators group. In an object’s security descriptor, the owner is represented by its SID in the Owner SID field.

  To look at an object’s discretionary ACLs from the Windows GUI, you will typically use the ACL editor (explained in detail as follows). To look at the DACLs of a file system object from the command prompt, you can use the cacls, xcacls, or showacls tools. For an AD object, you can use dsacls. We will come back to these tools at the end of this chapter.

• System ACLs (SACLs) contain an object’s auditing settings and are set by an administrator. They are nondiscretionary: They are not related in any way to the owner of an object. SACLs are not the only thing that is needed in order to enable auditing on the object level. You also must enable “Audit object access” in a machine’s audit policy. We will come back to Windows auditing in Chapter 18 of this book.

To look at an object’s system ACL from the Windows GUI, you will also use the ACL editor. However, Windows does not include a native command-line utility to do this.

Besides the discretionary and system ACLs, an object’s security descriptor also contains two other fields:

• The Owner SID field holding the SID of the owner of the object

• The Primary group SID field holding the SID of the object owner’s primary group. The concept of a primary group is used for Posix and Macintosh compatibility reasons.

In the Windows authroziation model, a user never accesses a resource all by himself or herself: There is 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.

The degree to which a process can act on behalf of a user can be controlled using impersonation levels, which are set in a user’s access token. Windows Server 2003 uses the following impersonation levels: anonymous, identify, impersonate, and delegate. They are explained in Table 10.2. The anonymous and delegate impersonation levels were introduced in Windows 2000. The delegate level is the only impersonation level that can be controlled from the administration interface. Chapter 5 contains more information on the delegate impersonation level (or, in short, delegation) and they way it differs from the impersonate impersonation level.

Table 10.2: Windows Impersonation Levels

Impersonation Level	Meaning
Anonymous	The process impersonates an anonymous user (this means unidentified user). The access token will not contain any authorization information.
Identify	The process can use the identity of the user for its proper security processes. It cannot impersonate the user.
Impersonate	The process can act on behalf of a user to access resources on the local machine. The access token will contain the user’s authorization information.
Delegate	A service can act on behalf of a user to access resources on the local machine and also on remote machines. The access token will contain the user’s authorization information.