Security Principals used in Windows Authentication

Updated: April 11, 2013

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

This reference topic describes the role of security principals and authorization in the authentication process.

In Windows, any user, service, group, or computer that can initiate action is a security principal. Security principals have accounts, which can be local to a computer or domain-based.

For example, Windows client domain-joined computers can participate in a network domain by communicating with a domain controller even when no human user is logged on. To initiate communications, the computer must have an active account in the domain. Before accepting communications from the computer, the local security authority on the domain controller authenticates the computer’s identity and then defines the computer’s security context just as it would for a human security principal. This security context defines the identity and capabilities of a user or service on a particular computer or a user, service, group or computer on a network. For example, it defines the resources (such as a file share or printer) that can be accessed and the actions (such as Read, Write, or Modify) that can be performed by a user, service, or computer on that resource.

The security context of a user or computer can vary from one computer to another, such as when a user logs on to a server or a workstation other than the user’s own primary workstation. It can also vary from one session to another, such as when an administrator modifies the user’s rights and permissions. In addition, the security context is usually different when a user or computer is operating on a stand-alone basis, in a mixed network domain, or as part of an Active Directory domain.

Accounts

An account is a means to identify a claimant—the human user or service—requesting access or resources. Users, groups of users, objects and services can all have individual accounts or share accounts. Accounts can be member of groups and can be assigned specific rights and permissions. Accounts can be restricted to the local computer, workgroup, network, or be assigned membership to a domain.

Built-in accounts in Windows

Built-in accounts and groups are defined on each version of Windows. In addition, built-in accounts might vary between different editions of the same Windows operating system.

The following table lists the default built-in accounts available in Windows Server.

For descriptions and default values of these accounts, see:

• Default local groups in Windows Server 2008 and Windows Server 2008 R2.

• Default local groups in Windows Server 2003.

Managed service accounts

Managed service accounts and virtual accounts were introduced in Windows Server 2008 R2 and Windows 7 to provide crucial applications, such as Exchange Server and Internet Information Services (IIS), with the isolation of their own domain accounts, while eliminating the need for an administrator to manually administer the service principal name (SPN) and credentials for these accounts. For more information about these features and their role in authentication, see Managed Service Accounts.

Passwords

A password is a form of secret authentication data that is used to control access to a resource.

In Windows, passwords are encrypted by whatever the authentication protocol is chosen and packaged with other authentication information. The outcome of the encryption is a hashed password transformed into ciphertext, a string of numbers and letters that appears meaningless. The hashing process occurs by means of a hashing algorithm. Windows uses the same algorithm (used by the authentication protocol) to encrypt and decrypt a user’s password. This authenticated packet is stored by Windows so that, as with Interactive Logon, credentials do not require re-authentication when logging on with a domain account.

The following table compares characteristics and restrictions of password composition in Windows authentication architecture. Additional restrictions can be enforced by using security policy settings.

For conceptual information about passwords in Windows, including resets, the Account Lockout policy, and the system key utility, see Passwords Technical Overview.

For more information about the characteristics of strong passwords, see Strong passwords.

For information about creating strong password policies that include complexity and age requirements, see Creating a Strong Password Policy.

For information about hashing, see Data integrity with hash functions.

Personal identification numbers (PIN), certificates, and smart cards

A personal identification number (PIN) is a secret shared between a user and a system that can be used to authenticate the user to the system. Smart card use for Windows authentication requires a non-confidential user identifier or token, specifically a certificate issued for a user by a certification authority (CA) from the organization granting the authentication. In addition, the user is required to provide a confidential PIN to gain access to the system. Upon receiving the certificate and PIN, the system looks up the PIN based upon the user’s identification encrypted in the certificate and compares the looked-up PIN with the received PIN. If they match, the user is granted access. If they do not match, the user is not granted access.

For information about the infrastructure components of a Windows smart card deployment, see Smart Card Fundamentals.

Authorization and Windows authentication architecture

Authorization technologies play a key role in permitting access to the appropriate resources after authentication. The following sections describe how security identifiers and access tokens contribute in Windows authentication.

Security identifiers

The rights and permissions for a user, group, or computer account are determined by access control lists (ACLs) and contain security identifiers (SIDs) for a user, group, or computer. A SID is a unique value that identifies a user, group, or computer account within an enterprise. Every account is issued a SID when it is created. Access control mechanisms in Windows identify security principals by SID instead of by name. Therefore, even if the name of a security principal changes, the SID remains the same.

In addition to the unique SID, the user, group, or computer is identified by the SIDs of the groups to which they belong. This information is stored in an access token, which encapsulates all data that relates to your identity and security context during a given session.

For information about new SIDs in Windows Vista, see Security Identifiers (SIDs) New for Windows Vista.

For information about SIDs in Windows Server 2003, see the Security Identifiers Technical Reference.

For information about ACLs, see Access Control Lists.

Access tokens

An access token is re-created every time a security principal is authenticated (logs on), and it contains the following information used for accessing resources:

• The SID for the user’s account.

• A list of SIDs for security groups that include the user and the privileges held on the local computer by the user and the user’s security groups. This list includes SIDs both for domain-based security groups, if the user is a member of a domain, and for local security groups.

• The SID of the user or security group that becomes the default owner of any object that the user creates or takes ownership of.

• The SID for the user’s primary group.

• The default discretionary access control lists (DACLs) that the operating system applies to objects created by the user if no other access control information is available.

• A list of privileges associated with the user’s account.

• The source, such as the Session Manager or LAN Manager, that caused the access token to be created.

• A value indicating whether the access token is a primary token, which represents the security context of a process, or an impersonation token, which is an access token that a thread within a service process can use to temporarily adopt a different security context, such as the security context for a client of the service.

• A value that indicates to what extent a service can adopt the security context of a client represented by this access token.

• Statistics about the access token that are used internally by the operating system.

• An optional list of SIDs added to an access token by a process to restrict use of the token.

• A session ID that indicates whether the token is associated with a Terminal Services client session. (The session ID also makes fast user switching possible because it contains a list of privileges.)

A copy of the access token is attached to every thread and process that the user runs. The security reference monitor (SRM) then compares the security descriptors in the token with the security IDs for every file, folder, printer, or application that the user attempts to access. In this way, the access token provides a security context for the security principal’s actions on the computer.

For information about how access tokens are used in conjunction with logon and authentication in Windows, see the Access Tokens Technical Reference.

See Also

Concepts

Windows Authentication Concepts