Overview
Last updated
Last updated
The Authentication Services protocols verify the identity of users, computers, and services through the interactive logon and network logon authentication processes. Once authenticated, these entities can be authorized to access network resources securely.
An entity with an identity that can be authenticated.
A security principal can be
a user
an autonomous program within the system, such as a logging daemon, a system backup program, or a network application.
a computer, a service, or a security group that represents a set of users
Windows uses a security identifier (SID), composed of
an account authority portion (typically a domain) and
a smaller integer representing an identity relative to the account authority termed the relative identifier (RID)
as an identity of a security principal.
An account database maintains the security principals and necessary information for authentication and other purposes.
an Active Directory database maintains the domain security principals, whereas
the security account manager (SAM) built-in database maintains local security principals
GSS API decoupled application protocols from authentication protocols by providing an abstraction layer between application-level protocols and security protocols.
The Windows implementation, SSPI, thus also allows an application to use various security models available on a computer or network without changing the interface to the security system.
SSPI is the Windows equivalent of GSS-API, and the two sets of APIs are on-the-wire compatible; hence the terms GSS-API and SSPI are used interchangeably.
In the GSS style or model, the authentication protocol produces opaque messages that are known as security tokens. The application protocol is responsible for security token exchange between sender and receiver but does not parse or interpret the security tokens.
For example, Kerberos tickets.
The Authentication Services protocols provide authentication services to client and server applications.
Client and server applications interact with
the Authentication Client and
components of Authentication Services respectively.
The client application contacts the local Authentication Client through a generic interface that abstracts the underlying authentication protocols for creating a security token.
The Authentication Client creates a security token with the help of the underlying authentication protocols and returns it to the calling application.
The client application embeds the security token within application messages of the application protocol and transmits them as an authentication request to the server side of the application.
On receipt of the authentication messages, the server application extracts the security token and supplies it to the Authentication Server.
The Authentication Server processes the security token with the help of the underlying authentication protocols and generates a response determining whether that authentication is complete for the server-side application.
If another security token is generated, the server-side application sends it back to the client, where the process continues.
When authentication is complete, session-specific security services are available.
When Microsoft adopted the Kerberos protocol for Windows and moved away from NT LAN Manager (NTLM) Protocol, Microsoft chose to insert a protocol, in this case, SPNEGO, to allow security protocol selection and extension.
SPNEGO is an authentication mechanism that allows Generic Security Services (GSS) peers to determine whether their credentials support a common set of GSS-API security mechanisms
to negotiate different options within a given security mechanism or different options from several security mechanisms
to select a service, and
to establish a security context among themselves using that service.
The Security Support Provider Interface (SSPI) is the Windows-specific API implementation of the GSS-style authentication model.
SSPI is implemented as DLLs containing SSPs for different types of authentication protocols.
SSPI provides the means for connected network applications to call one of several security support providers (SSPs), associated with different authentication protocols, to establish authenticated connections and to exchange data securely over those connections.
Both the client and server versions of Windows implement standard authentication protocols including:
and their extensions, as specified in [MS-KILE], [MS-TLSP], [MS-SPNG], and [MS-NEGOEX] respectively.
as part of an extensible architecture that consists of security support provider (SSP) security packages to enable the authentication of users, computers, and services. The authentication process, in turn, enables authorized users and services to access resources securely.
Each SSP provides mappings between the SSPI function calls of an application and the functions of an actual security model.
A security support provider (SSP) acts as an application layer between Security Support Provider Interface (SSPI) and the other SSPs.
Negotiate analyzes the request and picks the best SSP to handle the request based on customer-configured security policy.
Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless one of the following conditions applies:
It can't be used by one of the systems involved in the authentication.
The calling app didn't provide sufficient information to use Kerberos.
To allow Negotiate to select the Kerberos security provider, the client app must provide one of the following:
A service principal name (SPN).
A user principal name (UPN).
A NetBIOS account name as the target name.
Otherwise, Negotiate always selects the NTLM security provider.
