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
a smaller integer representing an identity relative to the account authority termed the relative identifier (RID)
as an identity of a security principal.
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.
For example, Kerberos tickets.
The Authentication Services protocols provide authentication services to client and server applications.
Client and server applications interact with
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.
to negotiate different options within a given security mechanism or different options from several security mechanisms
to select a service, and
SSPI is implemented as DLLs containing SSPs for different types of authentication protocols.
Both the client and server versions of Windows implement standard authentication protocols including:
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.
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.
A user principal name (UPN).
A NetBIOS account name as the target name.
Windows uses a , composed of
an account authority portion (typically a ) and
An account database maintains the and necessary information for authentication and other purposes.
an maintains the domain security principals, whereas
the maintains local security principals
In the GSS style or model, the authentication protocol produces opaque messages that are known as . The application protocol is responsible for security token exchange between sender and receiver but does not parse or interpret the security tokens.
the and
When Microsoft adopted the Kerberos protocol for Windows and moved away from , Microsoft chose to insert a protocol, in this case, SPNEGO, to allow security protocol selection and extension.
SPNEGO is an authentication mechanism that allows peers to determine whether their credentials support a common set of GSS-API security mechanisms
to establish a among themselves using that service.
The is the Windows-specific API implementation of the GSS-style authentication model.
SSPI provides the means for connected network applications to call one of several , associated with different authentication protocols, to establish authenticated connections and to exchange data securely over those connections.
,
, and
Simple and Protected Generic Security Service Application Program Interface (-API) Negotiation Mechanism (),
and their extensions, as specified in , , , and respectively.
Currently, the Negotiate security package selects between and . Negotiate selects Kerberos unless one of the following conditions applies:
To allow Negotiate to select the security provider, the client app must provide one of the following:
A (SPN).
Otherwise, Negotiate always selects the security provider.
