Credentials Management in Windows Authentication

Articolo
04/10/2013

Updated: April 11, 2013

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

This reference topic describes the different credential management processes.

Windows credentials management is the process by which the operating system receives the credentials from the service or user and secures that information for future presentation to the authenticating target. In the case of a domain-joined computer, the authenticating target is the domain controller. The credentials used in authentication are digital documents that associate the user’s identity to some form of proof of authenticity, such as a certificate, a password, or a PIN.

By default, Windows credentials are validated against the Security Accounts Manager (SAM) database on the local computer, or against Active Directory on a domain-joined computer, through the WinLogon service. Credentials are collected through user input on the logon user interface or coded through the API to be presented to the authenticating target.

Local security information is stored in the registry under HKEY_LOCAL_MACHINE\SECURITY. Stored information includes policy settings, default security values, and account information, such as cached logon credentials. A copy of the SAM is also stored here, although it is write-protected.

The following diagram shows the components required and the paths that credentials take through the system to authenticate the user or process for a successful logon.

The following table correspond to the diagram above and describe each component that manages credentials in the authentication process at the point of logon.

Authentication components for all systems

Component	Description
User logon	Winlogon.exe is the executable file responsible for managing secure user interactions. The Winlogon service initiates the logon process for Windows operating systems by passing the credentials collected by user action on the secure desktop (Logon UI) to the Local Security Authority (LSA) through Secur32.dll.
Application logon	Application or service logons not requiring interactive logon. Most processes initiated by the user run in user mode by using Secur32.dll whereas processes initiated at start up, such as services, run in kernel mode by using Ksecdd.sys. For more information about user mode and kernel mode, see Applications and User Mode or Services and Kernel Mode in this topic.
Secur32.dll	The multiple authentication provider that forms the foundation of the authentication process.
Lsasrv.dll	The LSA Server service, which both enforces security policies and acts as the security package manager for the LSA. The LSA contains the Negotiate function, which selects either the NTLM or Kerberos protocol after determining which protocol will be successful.
Security Support Providers	A set of providers that can individually invoke one or more authentication protocols. The default set of providers can change with each version of Windows, and custom providers can be written.
Netlogon.dll	Some of the services that the Net Logon service performs include: Maintains the computer’s secure channel (not to be confused with Schannel) to a domain controller. Passes the user’s credentials through a secure channel to the domain controller and returns the domain SIDs and user rights for the user. Publishes service resource records in the Domain Name System (DNS) and uses DNS to resolve names to the Internet Protocol (IP) addresses of domain controllers. Implements the replication protocol based on remote procedure call (RPC) for synchronizing primary domain controllers (PDCs) and backup domain controllers (BDCs).
Samsrv.dll	The Security Accounts Manager (SAM), which stores local security accounts, enforces locally stored policies, and supports APIs.
Registry	Contains a copy of the SAM database, local security policy settings, default security values, and account information that is only accessible to the system.

Credential input for user logon

Two architectures exist for credential input in Windows. In Windows Server 2008 and Windows Vista, the Graphical Identification and Authentication (GINA) architecture was replaced with a credential provider model, which made it possible to enumerate different logon types through the use of logon tiles.

Graphical Identification and Authentication (GINA) architecture

The GINA architecture applies to the Windows Server 2003, Windows 2000 Server, Windows XP, and Windows 2000 Professional operating systems. In these systems, every interactive logon session creates a separate instance of the Winlogon service. The GINA architecture is loaded into the process space used by Winlogon, receives and processes the credentials, and makes the calls to the authentication interfaces through LSALogonUser.

The instances of Winlogon for an interactive logon run in Session 0. Session 0 hosts system services and other critical processes, including the Local Security Authority (LSA) process.

The following diagram shows the credential process for Windows Server 2003, Windows 2000 Server, Windows XP, and Windows 2000 Professional.

Credential provider architecture

The credential provider architecture applies to Windows Server 2008 R2, Windows Server 2008, Windows 7, and Windows Vista. In these systems, the credentials input architecture changed to an extensible design by using credential providers. These providers are represented by the different logon tiles on the secure desktop that permit any number of logon scenarios—different accounts for the same user and different authentication methods, such as password, smart card, and biometrics.

With the credential provider architecture, Winlogon always launches Logon UI after it receives a SAS event. Logon UI queries each credential provider for the number of different credential types the provider is configured to enumerate. Credential providers have the option of specifying one of these tiles as the default. After all providers have enumerated their tiles, Logon UI displays them to the user. The user interacts with a tile to supply their credentials. Logon UI submits these credentials for authentication.

Combined with supporting hardware, credential providers can extend Windows to enable users to log on through biometric (fingerprint, retinal, or voice recognition), password, PIN and smart card certificate, or any custom authentication package and schema that a third-party developer creates. Your organization can develop and deploy custom authentication mechanisms for all domain users and explicitly require users to use this custom logon mechanism.

Credential providers are not enforcement mechanisms. They are used to gather and serialize credentials. The Local Authority and authentication packages enforce security.

Credential providers can be designed to support single sign-on (SSO), authenticating users to a secure network access point (leveraging RADIUS and other technologies) as well as machine logon. Credential providers are also designed to support application-specific credential gathering and may be used for authenticating to network resources, joining machines to a domain, or providing administrator consent for User Account Control (UAC).

Credential providers are registered on the computer and are responsible for the following:

Describing the credential information required for authentication.
Handling communication and logic with external authentication authorities.
Packaging credentials for interactive and network logon.

Packaging credentials for interactive and network logon includes the process of serialization. Serialization of credentials allows multiple logon tiles to be displayed on the logon UI. Therefore, your organization can control the logon display—such as users, target systems for logon, pre-logon access to the network and workstation lock/unlock policies—through the use of customized credential providers. Multiple credential providers can co-exist on the same computer.

Single sign-on providers (SSOs) may be developed as a standard credential provider or as a Pre-Logon-Access provider.

Each version of Windows contains one default credential provider and one default Pre-Logon-Access Provider (PLAP).

Logon UI

The credential provider enumerates the tiles for workstation logon. The credential provider will typically serialize credentials for authentication to the local security authority. This displays tiles specific for each user and specific to each user's target systems.

Unlock Workstation

The logon and authentication architecture allows a user to use tiles enumerated by the credential provider to unlock a workstation. Typically, the currently logged on user is the default tile; however, if more than one user is logged on, numerous tiles will be displayed.

Change Password

The credential provider enumerates tiles in response to a user request to change their password (or other private information, such as a PIN). Typically, the currently logged on user is the default tile; however, if more than one user is logged on, numerous tiles will be displayed.

Credential UI

The credential provider enumerates tiles based on the serialized credentials to be used for authentication on remote computers. Credential UI does not use the same instance of the provider as the Logon UI, Unlock Workstation, or Change Password. Therefore, state information cannot be maintained in the provider between instances of Credential UI. This results in one tile for each remote computer logon, assuming the credentials have been properly serialized. This scenario is also used for over-the-shoulder prompting in User Account Control (UAC).

Pre-Logon-Access Provider

The Pre-Logon-Access Provider (PLAP) permits users to make a connection to a network before logging on to the local computer. When this provider is implemented, the provider will not enumerate tiles on Logon UI. Users will see them only after clicking the PLAP button. Logon is then handled through the Pre-Logon-Access Provider screen.

A PLAP is intended to be used in the following scenarios:

Network authentication and computer logon are handled by different credential providers. Variations to this scenario include:
- A user has the option of connecting to a network (such as connecting to a virtual private network (VPN) before logging on to the machine but is not required to make this connection.
- Network authentication is required to retrieve information used during interactive authentication on the local computer.
- Multiple network authentications are followed by one of the other scenarios. For example, a user authenticates to an ISP, then authenticates to a VPN, and then uses their user account credentials to log on locally.
- Cached credentials are disabled, and a RAS/VPN connection is required before local logon to authenticate the user.
- A domain user does not have a local account set up on a domain-joined computer and must establish a RAS/VPN connection before completing interactive logon.
Network authentication and computer logon are handled by the same credential provider. In this scenario, the user is required to connect to the network before logging on to the computer.

The following diagram shows the credential process for Windows Server 2008 R2, Windows Server 2008, Windows 7, and Windows Vista operating systems.

Credential input for application and service logon

Windows authentication is designed to manage credentials for applications or services that do not require user interaction. Applications in user mode are limited in terms of what system resources they have access to, while services can have unrestricted access to the system memory and external devices.

System services and transport-level applications access an Security Support Provider (SSP) through the Security Support Provider Interface (SSPI), which provides functions for enumerating the security packages available on a system, selecting a package, and using that package to obtain an authenticated connection.

When a client/server connection is authenticated:

The application on the client side of the connection sends credentials to the server using the SSPI function InitializeSecurityContext (General).
The application on the server side of the connection responds with the SSPI function AcceptSecurityContext (General).
The SSPI functions InitializeSecurityContext (General) and AcceptSecurityContext (General) repeat until all the necessary authentication messages have been exchanged to either succeed or fail authentication.
After the connection has been authenticated, the LSA on the server uses information from the client to build the security context, which contains an access token.
The server can then call the SSPI function ImpersonateSecurityContext to attach the access token to an impersonation thread for the service.

Applications and user mode

User mode in Windows is composed of two systems capable of passing I/O requests to the appropriate kernel mode software drivers: the environment system, which runs applications written for many different types of operating systems, and the integral system, which operates system-specific functions on behalf of the environment system.

The integral system manages operating system−specific functions on behalf of the environment system and consists of a security system process (the LSA), a workstation service, and a server service. The security system process deals with security tokens; grants or denies access to user accounts based on resource permissions; handles logon requests and initiates logon authentication; and determines which system resources need to be audited by the operating system.

Applications can run in user mode where it can run as any principal, including in the security context of Local System (SYSTEM). Applications can also run in kernel mode where it would run in the security context of Local System (SYSTEM).

SSPI is available through the Secur32.dll module, which is an API used for obtaining integrated security services for authentication, message integrity, and message privacy. It provides an abstraction layer between application-level protocols and security protocols. Because different applications require different ways of identifying or authenticating users and different ways of encrypting data as it travels across a network, SSPI provides a way to access dynamic-link libraries (DLLs) containing different authentication and cryptographic functions. These DLLs are called Security Support Providers (SSPs).

Managed service accounts and virtual accounts were introduced in Windows Server 2008 R2 and Windows 7 to provide crucial applications, such as SQL Server and 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 What's New in Service Accounts.

Services and kernel mode

Even though most Windows applications run in the security context of the user who starts them, this is not true of services. Many Windows services, such as network and printing services, are launched by the service controller when the user starts the computer. These services might run as Local Service or Local System and might continue to run after the last human user logs off.

Note

Services normally run in security contexts known as Local System (SYSTEM), Network Service, or Local Service. Windows Server 2008 R2 introduced services that run under a managed service account, which are domain principals.

Before starting a service, the service controller logs on by using the account designated for the service and presents the service’s credentials for authentication by the LSA. (The Windows service implements a programmatic interface that the service controller manager can use to control the service. A Windows service can be started automatically when the system is started or manually with a service control program.) For example, when a Windows client computer joins a domain, the messenger service on the computer connects to a domain controller and opens a secure channel to it. To obtain an authenticated connection, the service must have credentials that the remote computer’s Local Security Authority (LSA) trusts. When communicating with other computers in the network, LSA uses the credentials for the local computer’s domain account, as do all other services running in the security context of the Local System and Network Service. Services on the local computer run as SYSTEM so credentials do not need to be presented to LSA.

The file Ksecdd.sys manages and encrypts these credentials and uses a local procedure call into the LSA. The file type is DRV (driver) and is known as the kernel-mode Security Support Provider (SSP) and, in Windows Server 2008 R2, Windows Server 2008, Windows 7, and Windows Vista, is FIPS 140-2 Level 1 compliant.

Kernel mode has full access to the hardware and system resources of the computer. The kernel mode stops user mode services and applications from accessing critical areas of the operating system that they should not have access to.

Local Security Authority

The Local Security Authority (LSA) is a protected system process that authenticates and logs users on to the local computer. In addition, LSA maintains information about all aspects of local security on a computer (these aspects are collectively known as the local security policy), and it provides various services for translation between names and security identifiers (SIDs). The security system process keeps track of the security policies and the accounts that are in effect on a computer system.

The LSA validates a user’s identity based on which of the following two entities issued the user’s account:

Local Security Authority. The LSA can validate user information by checking its own Security Accounts Manager (SAM) database. Any workstation or member server can store local user accounts and information about local groups. However, these accounts can be used for accessing only that workstation or computer.
Security authority for the local domain or for a trusted domain. The LSA contacts the entity that issued the account and requests verification that the account is valid and that the request originated from the account holder.

Security Accounts Manager (SAM) database

The Security Account Manager (SAM) is a database that stores local user accounts and groups. It is present in every Windows operating system; however, when a computer is joined to a domain, Active Directory manages domain accounts in Active Directory domains.

For example, client computers running Windows 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 LSA on the domain controller authenticates the computer’s identity and then constructs 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, or computer on a network. For example, the access token contained within the security context 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 that principal—a user, computer, or service 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 network, or as part of an Active Directory domain.

Local domains and trusted domains

When a trust exists between two domains, the authentication mechanisms for each domain relies on the validity of the authentications coming from the other domain. Trusts help to provide controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority (the trusted domain). In this way, trusts act as bridges that allow only validated authentication requests to travel between domains.

How a specific trust passes authentication requests depends on how it is configured. Trust relationships can be one-way, providing access from the trusted domain to resources in the trusting domain, or two-way, providing access from each domain to resources in the other domain. Trusts are also either nontransitive, in which case a trust exists only between the two trust partner domains, or transitive, in which case a trust automatically extends to any other domains that either of the partners trusts.

For information about domain and forest trust relationships in regards to authentication, see Delegated Authentication and Trust Relationships.

Cached credentials and validation

Validation mechanisms rely on the presentation of credentials at the time of logon. However, when the computer is disconnected from a domain controller, and the user is presenting domain credentials, then Windows uses the process of cached credentials in the validation mechanism.

Each time a user logs on to a domain, Windows caches the credentials supplied and stores them in the security hive of the operation system. The cached credentials is a function of the NT hash in that the hashed credentials are salted by using the user name and hashed again.

With cached credentials, the user can log on to a domain member without being connected to a domain controller within that domain.

For more information about cached credentials, see the Cached and Stored Credentials Technical Overview.

Credential storage and validation

It is not always desirable to use one set of credentials for access to different resources. For example, an administrator might want to use administrative rather than user credentials when accessing a remote server. Similarly, if a user will be accessing external resources, such as a bank account, he or she can only use credentials that are different than their domain credentials. There are differences in credential management between , Windows 7, Windows Vista, and Windows XP.

Stored user names and passwords in Windows Vista and Windows XP

In Windows Server 2008, Windows Server 2003, Windows Vista, and Windows XP, Stored User Names and Passwords in Control Panel simplifies the management and use of multiple sets of logon credentials, including X.509 certificates used with smart cards and Windows Live credentials (now called Microsoft Accounts). The credentials—part of the user’s profile—are stored until needed. This can increase security on a per-resource basis by ensuring that if one password is compromised, it does not compromise all security.

After a user logs on and attempts to access additional password-protected resources, such as a share on a server, and if the user’s default logon credentials are not sufficient to gain access, Stored User Names and Passwords is queried. If alternate credentials with the correct logon information have been saved in Stored User Names and Passwords, these credentials are used to gain access. Otherwise, the user is prompted to supply new credentials, which can then be saved for reuse, either later in the logon session or during a subsequent session.

The following restrictions apply:

If Stored User Names and Passwords contains invalid or incorrect credentials for a specific resource, access to the resource will be denied and the Stored User Names and Passwords dialog box will not appear.
Stored User Names and Passwords stores credentials only for NTLM, Kerberos protocol, Windows Live ID, and SSL authentication. Some versions of Microsoft Internet Explorer maintain its own cache for basic authentication.

These credentials become an encrypted part of a user’s local profile in the \Documents and Settings\Username\Application Data\Microsoft\Credentials directory. As a result, these credentials can roam with the user if the user’s network policy supports Roaming Profiles. However, if the user has copies of Stored User Names and Passwords on two different computers and changes the credentials that are associated with the resource on one of these computers, the change will not be propagated to Stored User Names and Passwords on the second computer.

For more information about Stored User Names and Passwords, see the Cached and Stored Credentials Technical Overview.

Windows Vault and Credential Manager in Windows 7

In Windows Server 2008 R2 and Windows 7, the storage and management of user names and passwords were integrated into Credential Manager—a Control Panel feature. Credential Manager allows users to store credentials to other systems and websites in the secure Windows Vault. Some versions of Internet Explorer use this feature for authentication to websites.

Credential management by using Credential Manager is controlled by the user on the local computer. Users can save and store credentials from supported browsers and Windows applications to make it convenient when they need to sign in to these resources. Credentials are saved in special encrypted folders on the computer under the user’s profile. Applications that support this feature (through the use of the Credential Manager APIs), such as web browsers and apps, can present the correct credentials to other computers and websites during the log on process.

When a website, an application, or another computer requests authentication through NTLM or the Kerberos protocol, an Update Default Credentials or Save Password check box is presented to the user. This dialog to request the saving of credentials locally is generated by an application that supports the Credential Manager APIs. If the user selects the Save Password check box, Credential Manager keeps track of the user's name, password, and related information for the authentication service that is in use.

The next time the service is used, Credential Manager automatically supplies the credential that is stored in the Windows Vault. If it is not accepted, the user is prompted for the correct access information. If access is granted with the new credentials, Credential Manager overwrites the previous credential with the new one and then stores the new credential in the Windows Vault.

Certificates in Windows authentication

A public key infrastructure (PKI) is the combination of software, encryption technologies, processes, and services that enable an organization to secure its communications and business transactions. The ability of a PKI to secure communications and business transactions is based on the exchange of digital certificates between authenticated users and trusted resources.

A digital certificate is an electronic document that contains information about the entity it belongs to; the entity it was issued by; a unique serial number or some other unique identification; issuance and expiration dates; and a digital fingerprint.

Authentication is the process of determining if a remote host can be trusted. To establish its trustworthiness, the remote host must provide an acceptable authentication certificate.

Remote hosts establish their trustworthiness by obtaining a certificate from a certification authority (CA). The CA may, in turn, have certification from a higher authority, and so on, creating a chain of trust. To determine whether a certificate is trustworthy, an application must determine the identity of the root CA, and then determine if it is trustworthy.

Similarly, the remote host (or local computer) must determine if the certificate presented by the user or application is authentic. The certificate presented by the user through the LSA and SSPI is evaluated for authenticity on the local computer (for local logon), on the network, or on the domain through the certificate stores in Active Directory.

To produce a certificate, authentication data passes through hash algorithms, such as Secure Hash Algorithm 1 (SHA1), to produce a message digest. The message digest is then digitally signed by using the sender’s private key to prove that the message digest was produced by the sender.

Smart card authentication

Smart card technology is an example of certificate-based authentication. Logging on to a network with a smart card provides a strong form of authentication because it uses cryptography-based identification and proof of possession when authenticating a user to a domain. Active Directory Certificate Services provides the cryptographic-based identification through the issuance of a logon certificate for each smart card.

For information about smart card authentication, see the Windows Smart Card Technical Reference.

Remote and wireless authentication

Remote and wireless network authentication is another technology that uses certificates for authentication. The Microsoft Internet Authentication Service (IAS) and virtual private network servers use Extensible Authentication Protocol-Transport Level Security (EAP-TLS), Protected Extensible Authentication Protocol (PEAP), or Internet Protocol security (IPsec) to perform certificate-based authentication for many types of network access, including virtual private network (VPN) and wireless connections.

For information about certificate-based authentication in networking, see Network access authentication and certificates.

Condividi tramite