Windows Authentication Architecture
Published: April 11, 2013
Updated: April 11, 2013
Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista
This overview topic explains the basic architectural scheme for Windows authentication.
Authentication is the process by which the system validates a user's logon information. A user's name and password are compared against an authorized list, and if the system detects a match, access is granted to the extent specified in the permission list for that user.
Microsoft authentication technologies include Local Security Authority (LSA) Authentication, Credentials Management, Smart Card Authentication, Network Provider, Security Support Provider Interface (SSPI), Winlogon, and GINA (for Windows Server 2003).
The Windows Server operating systems implement a default set of authentication security support providers, including Negotiate, the Kerberos protocol, NTLM, Schannel (secure channel), and Digest, as part of an extensible architecture. The protocols used by these providers enable authentication of users, computers, and services; the authentication process, in turn, enables authorized users and services to access resources in a secure manner.
Windows Server provides a method for applications to authenticate users by using the Security Support Provider Interface (SSPI) to abstract calls to authentication. Thus, developers do not need to understand the complexities of specific authentication protocols or build authentication protocols into their applications.
Windows Server operating systems include a set of security components that make up 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). 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 LSA security subsystem provides services for validating access to objects, checking user rights, and generating audit messages.
The Security Support Provider Interface (SSPI) is the well-defined common API for obtaining integrated security services for authentication, message integrity, message privacy, and security quality of service for any distributed application protocol. SSPI is the implementation of the Generic Security Service API (GSSAPI). SSPI provides a mechanism by which a distributed application can call one of several security providers to obtain an authenticated connection without knowledge of the details of the security protocol.
The following topics describe the authentication architecture for the specified Windows operating systems. Smart card authentication is described in Smart Cards.
The following section describes the differences in Windows authentication for each of the Windows operating system versions and points to the relevant documentation where necessary.
The following list identifies the significant changes in the Windows authentication architecture from Windows Server 2003 and Windows XP. For additional information about related security changes, see Windows Vista Authentication Features or What's New in Security in Windows Server 2008.
Credential Provider model has replaced the need for GINAs
New Credential Security Service Provider, CredSSP
ECC Cipher Suite support added
The following topics describe the significant changes in Windows authentication architecture from Windows Server 2008 and Windows Vista.