Overview
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.
Introduction
Security Principal
An entity with an identity that can be authenticated.
Types
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
Security Identifier (SID)
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.
Account Database
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
Generic Security Services (GSS)
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.
Security Token
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.
Authentication Service
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.
Authentication Process
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.
Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
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.
Security Support Provider Interface (SSPI)
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.
Security Support Package (SSP)
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.
Windows Negotiate
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.
Kerberos & NTLM
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.
Last updated