Windows Server 2008 and Windows Vista Authentication Architecture
Updated: April 11, 2013
Applies To: Windows Server 2008, Windows Vista
This reference topic describes the authentication architecture including the Local Security Authority (LSA) security subsystem architecture for Windows Server 2008 and Windows Vista.
Windows Server 2008 and Windows Vista authentication services, with its security subsystem architecture, allows your organization to provide a standard or custom logon experience. With the implementation of the Credential Security Support Provider (CredSSP), the authentication service does not depend on the Graphical Identification and Authentication (GINA). The credential provider passes the credential information directly from the logon screen to Winlogon.exe, which interacts with LSA to communicate with a remote authentication source, such as a domain controller, and the protocol layer within the LSA architecture.
In addition, Windows Server 2008 and Windows Vista provide a method for applications to authenticate users by using the Security Support Provider Interface (SSPI) to abstract calls to authentication protocols. Developers should understand the different types of authentication, the effects of using different protocols, and the interfaces they support. Then they can specify their preferred authentication protocol and use the authentication protocols provided by the Windows platform. If the preferred protocol is not in Windows Server 2008 or Windows Vista, developers can use a custom Security Support Provider.
Windows Server 2008 and Windows Vista operating system includes a set of security components that makes up part of the Windows security model. These components ensure that applications cannot gain access to resources without authentication and authorization.
The Local Security Authority (LSA) is a protected subsystem 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). There are two domains in which logon attempts are trusted. The local account domain is used on a standalone computer, and the domain account is used on a domain-joined computer.
The security subsystem keeps track of the security policies and the accounts that are in effect on a computer system. In the case of a domain controller, these policies and accounts are the ones that are in effect for the domain in which the domain controller is located. These policies and accounts are stored in Active Directory.
The local security policy identifies the following:
Who can have access to the system and in what way (for example, interactively, over the network, or as a service).
Who is assigned what rights.
What security auditing is performed.
What the default memory quotas are for paged and non-paged memory pool usage.
LSA architecture
The LSA security subsystem provides services for validating access to objects, checking user rights, and generating audit messages. A local procedure call (LPC) occurs between components on the same system. A remote procedure call (RPC) can occur between components on different systems (as do LDAP communications) or between components on the same system.
In general, the LSA performs the following functions:
Manages local security policy.
Provides interactive user authentication services.
Generates access tokens.
Manages the audit policy and settings.
The following illustrations show the architecture for Windows Server 2008 and Windows Vista authentication services on the local system, whether a client computer of member server, and those distinct components on the domain controller.
.gif)
The following illustration shows the components on the domain controller involved in handling the authentication request from the client.
.gif)
LSA components for all systems
| Component | Description |
|---|---|
Credssp.dll |
The default dynamic-link library (DLL) module that operates in the security context of Winlogon. For information about this new component for Windows Server 2008 and Windows Vista, see Credential Security Service Provider and SSO for Terminal Services Logon. For information about credential management in Windows Server 2008 and Windows Vista, see Credentials Management in Windows Authentication. |
Netlogon.dll |
Some of the services that Net Logon performs include:
|
Msv1_0.dll |
The NTLM authentication protocol. This protocol authenticates clients that do not use Kerberos authentication. |
Schannel.dll |
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) authentication protocol. This protocol provides authentication over an encrypted channel instead of a less-secure clear channel. |
Kerberos.dll |
The Kerberos V5 authentication protocol. This protocol provides authentication using Kerberos protocol instead of plaintext, NTLM, or digest method. |
Wdigest.dll |
Simple challenge-and-response protocol that provides increased security over basic authentication. |
Lsasrv.dll |
The LSA Server service, which both enforces security policies and acts as the security package manager for the LSA. |
Samsrv.dll |
The Security Accounts Manager (SAM), which stores local security accounts, enforces locally stored policies, and supports APIs. |
Secur32.dll |
The authentication provider that exposes the SSP interfaces to applications. |
LSA components unique to domain controllers
| Component | Description |
|---|---|
Kdcsvc.dll |
The Kerberos Key Distribution Center (KDC) service, which is responsible for the Kerberos authentication service and the ticket granting service. |
Ntdsa.dll |
The directory service module, which supports the Windows replication protocol and LDAP, and manages partitions of data |
Ntdsapi.dll |
A directory service module which can communicate over RPC through a set of COM interfaces used for accessing directory services to manage network resources. |
Security Support Provider Interface (SSPI) and authentication protocols
The Security Support Provider Interface (SSPI) is the foundation for authentication in Windows Server 2008 and Windows Vista. The default Security Support Providers (SSPs) are implemented with the SSPI in the form of DLLs. Additional SSPs, such as customized ones, can be plugged in if they are interoperable with the SSPI. The SSPs contain one or more authentication protocols.
Each authentication protocol is composed of a series of steps, used by two or more parties, that verifies the identity of one or more of the parties.
The authentication protocols are designed to address potential security threats by verifying the identities of one or more of the communicating parties. The following topics describe each SSP included with these versions of Windows and link to additional information about the authentication protocol:
For information about the Security Support Provider Interface in Windows, see Security Support Provider Interface Architecture.
For developer resources for the Security Support Provider Interface, see SSPI.
Changes in authentication architecture from previous version
For a list and description of changes in architecture and functionality, see Windows Vista Authentication Features.
Additional resources
For information about the Local Security Policy and new policy settings in Windows Vista, see Viewing Local Security Policy Settings and Security Policy Settings New for Vista.
For information about Security Identifiers, see Security Identifiers Technical Reference.
For information about access to resources, see What Are Access Tokens?.
For information about rights, see About user rights.
For information about security auditing, see Security auditing.