Members of the Administrators group have additional powers and responsibilities. They each get two-piece, or split, SAT. One part of the SAT is built with the full privileges of the Administrators group. Members of this group enjoy full access to the computer and can perform many tasks that can be harmful to the computer. The other part of the SAT is built to reflect the more limited capabilities of a normal user. All processes initially run using the limited SAT. If a process requires a privilege that is allowed for administrators and the process also contains an administrator SAT, Windows will prompt the user for an escalation confirmation (FIGURE 3-3). Windows asks the user to confirm escalating the process to administrator privileges. This confirmation is designed to stop malicious software from making unauthorized changes by running at a higher-than-expected privilege level.

This Windows feature of prompting users before escalating to administrator privileges is called User Account Control (UAC).

Each time a process needs access to an object, Windows refers to the process’s SAT and the object’s DACL to see if the access request is allowed. If the access request is allowed, the process accesses the object. If the access request is not allowed, Windows returns an error and the process cannot complete the requested object access.

Once Windows builds the SAT and attaches it to each process, the SAT becomes the subject part of the authorization process. Before granting access to an object, Windows must first authorize the request. Windows uses the DACL defined for an object to decide whether the access request will be granted or denied. DACLs will be covered in the next section.

The SAT for each process is built from the user’s SID and group SIDs. The SAT is specific to a computer in a stand-alone or workgroup environment. Recall that workgroups do not share users or groups. As user and group settings and assignments are customized, synchronizing changes across computers in a workgroup becomes increasingly difficult. This makes Active Directory even more appealing. Active Directory stores the shared necessary information to construct SATs, which are identical for a given user, regardless of the computer where the user logs on.

If the domain controller sends security information to the computer where a user logs on, how does Windows stop an attacker from intercepting the SAT information and impersonating an authorized user? Windows extends the concept of authentication to the computer level when constructing SATs. The complete SATs are never shared across a network—only the parts necessary to construct the SAT (FIGURE 3-5). The domain controller stores the domain user’s SID and the SIDs for all of the domain groups to which the user is assigned. The target server, the server where the resource access resides, already has the local group list of groups to which the user is defined and the local user rights definitions. The domain controller sends the domain user and group SIDs to the target server using one of two Windows authentication protocols.

Windows Server 2012 added support for a new type of account to help administrators manage servers. In previous versions of Windows, administrators had to maintain passwords for multiple system accounts. These accounts provide the credentials that critical Windows services and tasks use. Administrators commonly use multiple accounts to handle the needs of various critical services. For example, backup needs are different from the account for an IIS server. Administrators define each system account with just the permissions required to carry out its tasks. Manually maintaining the passwords for system accounts across many servers was tedious.

Windows Server 2012 and newer includes managed service accounts, which can be shared across systems. Administrators create these accounts as managed domain accounts that provide automatic password management. Earlier versions of Windows provided computer accounts and managed server accounts, but neither of these account types could be shared across systems. The new group managed service accounts allow the Windows Server 2012 and newer domain controllers to manage the passwords automatically at the domain level.

The default authentication protocol since Windows 2000 is Kerberos. Kerberos is a fast and scalable protocol that allows for secure exchange of information (FIGURE 3-6). Each domain controller functions as a Kerberos key distribution center (KDC). The KDC stores all user and computer Kerberos master keys. When a subject requests access to an object, the subject asks the domain controller for an access ticket. The domain controller authenticates the subject. If successful, the domain controller issues the access ticket. The access ticket contains all of the subject’s SIDs and is encrypted with the target server’s public key. The subject then presents the access ticket to the server where the desired object resides. Since the access ticket was encrypted with the server’s public key, the server can decrypt it with its private key. Successful decryption means the ticket is valid and the server evaluates the SIDs for access permission.