1.1.1.2 Accounts

On a computer that is running Windows, an account represents a security principal. The security principal (or account) has at least a name and an identifier.

The name is a simple textual name for the account and can be a personal name, such as Rene Valdes, SYSTEM, or RedmondDc1$. However, the name is merely an attribute of the account and can change over time. A common scenario for a name change is when the person to whom the account refers changes his or her name.

Also, the name is treated as case-insensitive. That is, Rene Valdes, RENE VALDEZ, rene valdes, and reNe ValdEZ are treated as equivalent in Windows. Microsoft views case-sensitivity as an unnecessary burden on the administrator that can lead to mistakes.

The identifier, although also an attribute of the account, needs to satisfy other requirements as well. Of particular importance are the uniqueness and persistence of the identifier and the ability to identify the issuer of the identifier.

The persistence of the identifier provides the administrator the capability to assign a resource to that account and the capacity to accept future changes to the account.

For example, an administrator might assign a user who is named Rene Valdes access to a certain document at some point in time. If Rene Valdes leaves the company and a different Rene Valdes is hired, the new Rene Valdes is not to have access to the resources of the original Rene Valdes. Conversely, if Rene Valdes changes his name to Rene Q. Valdes, he is not to lose access to the resources that was previously granted to him.

The ability to identify the issuer of an identifier is important because it can determine whether a party is willing to accept the identifier. For example, in the physical world, a cashier generally accepts a driver's license as proof of identity, but the cashier refuses to accept a gymnasium membership card. In Windows, the issuer of an account is encoded with the identity so that any recipient can make a similar decision.

Windows has two basic accounts: user accounts and computer accounts. (The built-in administrator account is enabled by default, except in the Windows 7 operating system):

User account: Identifies users who belong to a domain. User accounts store the names of users, information that is required to verify their identity, and other user information.

Computer account: Identifies computers that belong to a domain. A computer account is commonly referred to as a "machine account". Every Windows computer that joins a domain has a computer account. Computer accounts provide a means for authenticating and auditing computer access to the network and to domain resources. Each computer account is unique.

For more information about user and computer accounts, see Active Directory naming [MSFT-ADN].

Windows supports two distinct methods for machine logon. An interactive logon is the process in which the account information and credentials that the user enters interactively are authenticated by a domain controller (DC), whereas a network logon is the process of making an authenticated connection to a server across the network.

Authentication methods range from a simple logon, which identifies users based on information that only the user knows, like a password, to more powerful security mechanisms that use something that the user has, like tokens, public key certificates, and biometrics. In a business environment, users might access multiple applications on many types of servers within a single location or across multiple locations. For these reasons, authentication methods need to support heterogeneous environments.

For network logon, the authenticating entities are called the client and the server. They are separate processes or programs that run on one or more computers. When the client/server computing paradigm was initially designed and adopted, the clients and servers usually communicated over secure self-contained networks. As more and more applications had to communicate over open nonsecure interconnected networks such as the Internet, the chances that message data could be intercepted, altered, or suppressed increased significantly. Therefore, authentication protocols also typically support the exchange of session keys that are used to protect the messages.

The client, the server, or both can be authenticated. Client authentication occurs when the client proves its identity to the server; server authentication occurs when the server proves its identity to the client.

An example of server authentication is the use of the Secure Sockets Layer (SSL) on the Internet, which assures the identity of the server to the client. An example of client authentication might be the authentication of a client in a protected network environment where all valuable resources reside on a single server, and the server is concerned only about the identity of the client. On modern networks, however, proving the identity of both the client and the server is critical. The client needs to be assured of the identity of the server to avoid divulging important information to a rogue server. The server has to be assured of the identity of the client to avoid granting the client inappropriate access. This process is referred to as mutual authentication.

Ultimately, authentication is performed by using cryptographic operations of some form, such as encryption or signatures. There are two main types of encryption: symmetric encryption and asymmetric encryption. Symmetric encryption uses the same key to encrypt and decrypt a message. Asymmetric encryption uses one key to encrypt and uses a different key to decrypt; these keys are linked by mathematical requirements. Symmetric signatures can be implemented through keyed hashes; asymmetric signatures can be implemented through encrypted hashes. See [SCHNEIER] for more details.

Multitier client/server applications present a special situation for the Kerberos protocol. In this kind of application, a client might connect to a front-end server that connects to a second server on the back end. In this scenario, the front-end server sometimes authenticates itself to the back-end server by getting a service ticket for the back-end server by using the invoking client's identity. Ideally, this service ticket limits the front-end server's access on the second server to what the client is authorized to do, rather than to what the front-end server is authorized to do.

The Kerberos protocol deals with this situation through a mechanism called delegation of authentication. Essentially, the client delegates authentication to a server by communicating to the Key Distribution Center (KDC) that the server is authorized to represent the client.

Similar to Kerberos delegation, the Credential Security Support Provider (CredSSP) Protocol [MS-CSSP] enables applications to securely delegate a user's credentials from the client to the target server. However, it does so by using a completely different mechanism with different usability and security characteristics. Unlike Kerberos delegation, the CredSSP Protocol requires prompting for user credentials when a policy specifies their delegation. This difference means that the user has some control over whether the delegation occurs and, more importantly, which credentials are used. With Kerberos delegation, only the user's Active Directory credentials can be delegated.

The CredSSP Protocol is used only in scenarios where other delegation schemes such as Kerberos delegation cannot be used; for example, in non-domain scenarios.

In one such scenario, the Microsoft Terminal Server uses the CredSSP Protocol to securely delegate the user's password or smart card PIN from the client to the server to log on a network user and establish a Terminal Services session.