Security Support Provider Interface Architecture
Updated: April 11, 2013
Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista
This reference topic for the IT professional describes the use of Windows authentication protocols used within the SSPI architecture.
Architecture
The Microsoft Security Support Provider Interface (SSPI) is the foundation for Windows authentication. Applications and infrastructure services that require authentication use SSPI to provide it.
SSPI is the implementation of the Generic Security Service API (GSSAPI) in Windows Server operating systems. For more information about GSSAPI, see RFC 2743 and RFC 2744 in the IETF RFC Database.
The default Security Support Providers (SSPs) that invoke specific authentication protocols in Windows are incorporated into the SSPI as DLLs. These default SSPs are described below. Additional SSPs can be incorporated if they can operate with the SSPI.
The SSPI in Windows provides a mechanism that carries authentication tokens over the existing communication channel between the client computer and server. When two computers or devices need to be authenticated so that they can communicate securely, the requests for authentication are routed to the SSPI, which completes the authentication process, regardless of the network protocol currently in use. The SSPI returns transparent binary large objects—these are passed between the applications, at which point they can be passed to the SSPI layer on that side. Thus, the SSPI enables an application to use various security models available on a computer or network without changing the interface to the security system.
.jpg)
The following sections describe the default SSP components that interact with the SSPI. Each of the SSPs is used in different ways in Windows operating systems to promote secure communication in an unsecure network environment.
Kerberos Security Support Provider
NTLM Security Support Provider
Digest Security Support Provider
Schannel Security Support Provider
Negotiate Security Support Provider
Credential Security Support Provider
Negotiate Extensions Security Support Provider
PKU2U Security Support Provider
Kerberos Security Support Provider
This SSP uses only Microsoft’s implementation of the Kerberos version 5 protocol, which is based on Internet RFC 4120 and draft revisions. It is an industry-standard protocol that is used with either a password or a smart card for interactive logon. It is also the preferred authentication method for services in Windows.
The Kerberos SSP, Kerberos.dll, uses the Kerberos V5 authentication protocol (RFC 4120).
Because Kerberos has been the default authentication protocol since Windows 2000, all domain services support the Kerberos SSP, which include:
Active Directory queries using the Lightweight Directory Access Protocol (LDAP)
Remote server or workstation management using RPC calls
Print services
Client-server authentication
Remote file access using Common Internet File System/server message block (CIFS/SMB)
Distributed file system management and referral
Intranet authentication to Internet Information Services (IIS)
Security authority authentication for Internet Protocol security (IPsec)
Certificate requests to Active Directory Certificate Services for domain users and computers
Location: %windir%\Windows\System32\kerberos.dll
| Supported server versions | Supported client versions |
|---|---|
|
|
Additional resources for the Kerberos protocol and the Kerberos SSP
Kerberos Enhancements for Windows Vista
Changes in Kerberos Authentication for Windows 7
NTLM Security Support Provider
The NTLM Security Support Provider (NTLM SSP) is a binary messaging protocol used by the Security Support Provider Interface (SSPI) to allow NTLM challenge-response authentication and to negotiate integrity and confidentiality options. NTLM SSP is used wherever SSPI authentication is used including for Server Message Block or CIFS authentication, HTTP Negotiate authentication, for example Internet Web Authentication, and Microsoft RPC services. The NTLM SSP includes the NTLM and NTLMv2 authentication protocols.
The supported Windows operating systems can use the NTLM SSP for the following:
Client/server authentication
Print services
File access using CIFS/SMB
Secure RPC/DCOM-based services
Location: %windir%\Windows\System32\msv1_0.dll
| Supported server versions | Supported client versions |
|---|---|
|
|
Additional resources for the NTLM protocol and the NTLM SSP
Changes in NTLM Authentication in Windows 7
Digest Security Support Provider
Digest Authentication is an industry standard that, beginning with Windows 2000, is used for Lightweight Directory Access Protocol (LDAP) and web authentication. Digest Authentication transmits credentials across the network as an MD5 hash or message digest.
Digest SSP (Wdigest.dll) is used for the following:
Internet Explorer (IE) and Internet Information Services (IIS) access
LDAP queries
Location: %windir%\Windows\System32\Digest.dll
| Supported server versions | Supported client versions |
|---|---|
|
|
Additional resources for the Digest protocol and the Digest SSP
Schannel Security Support Provider
Schannel implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) Internet standard authentication protocols. Schannel is used for web-based server authentication, such as when a user attempts to access a secure web server.
The Transport Layer Security (TLS) protocol, Secure Sockets Layer (SSL) protocol, versions 2.0 and 3.0, and the Private Communications Transport (PCT) protocol are based on public key cryptography. The Security Channel (Schannel) authentication protocol suite provides these protocols. All Schannel protocols use a client/server model. The Schannel SSP, which includes the suite of three authentication protocols, uses public key certificates to authenticate parties. When authenticating parties, Schannel SSP selects one of the three protocols in the following order of preference:
Transport Layer Security (TLS) version 1.0
Transport Layer Security (TLS) version 1.1
Transport Layer Security (TLS) version 1.2
Secure Socket Layer (SSL) version 2.0
Secure Socket Layer (SSL) version 3.0
Private Communications Technology (PCT)
Note: PCT is disabled by default in Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003.
The protocol that is selected is the preferred authentication protocol that both parties can support. For example, if a server supports all the Schannel protocols and the client supports only SSL 3.0 and SSL 2.0, the authentication process uses SSL 3.0.
Location: %windir%\Windows\System32\Schannel.dll
| Supported server versions | Supported client versions |
|---|---|
|
|
Additional resources for the TLS and SSL protocols and the Schannel SSP
Negotiate Security Support Provider
The Negotiate (SPNEGO) SSP can be used to negotiate a specific authentication protocol. When an application calls into SSPI to log on to a network, it can specify an SSP to process the request. If the application specifies Negotiate, the SSP analyzes the request and picks the best SSP to handle the request based on customer-configured security policies.
Negotiate implements RFC 2478, “The Simple and Protected GSS-API Negotiation Mechanism.”
In supported versions of the Windows operating systems, the Negotiate security package selects between the Kerberos protocol and NTLM. Negotiate selects Kerberos by default unless Kerberos cannot be used by one of the systems involved in the authentication or the calling application did not provide sufficient information to use Kerberos.
Location: %windir%\Windows\System32\lsasrv.dll
| Supported server versions | Supported client versions |
|---|---|
|
|
Additional resources for the Negotiate SSP
[MS-SPNG]: Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Extensions
[MS-N2HT]: Negotiate and Nego2 HTTP Authentication Protocol Specification
Credential Security Support Provider
The Credential Security Service Provider, or CredSSP, provides a single sign-on (SSO) user experience when starting new Terminal Services and Remote Desktop sessions. CredSSP enables applications to delegate users' credentials from the client computer (by using the client-side security service provider) to the target server (through the server-side security service provider) based on client policies. CredSSP policies are configured by using Group Policy and delegation of credentials is turned off by default.
Location: %windir%\Windows\System32\credssp.dll
| Supported server versions | Supported client versions |
|---|---|
|
|
Additional resources for the Credentials SSP
[MS-CSSP]: Credential Security Support Provider (CredSSP) Protocol Specification
Credential Security Service Provider and SSO for Terminal Services Logon
Negotiate Extensions Security Support Provider
Negotiate Extensions (NegoExts) is an authentication package that negotiates the use of SSPs, other than NTLM or the Kerberos protocol, for applications and scenarios implemented by Microsoft and other software companies.
This extension to the Negotiate package permits the following scenarios:
Rich client availability within a federated system. Documents can be accessed on other SharePoint sites and can be edited by using a full-featured Microsoft Office application.
Rich client support for Microsoft Office Live. Users can log on to Microsoft Office Live services and use a full-featured Microsoft Office application.
Hosted Microsoft Exchange Server and Outlook. There is no domain trust established because Exchange is hosted on the web. Outlook uses the Windows Live service to authenticate users.
Rich client availability between client computers and servers. The operating system's networking and authentication components are used.
The Windows Negotiate package treats the NegoExts SSP in the same manner as it does for Kerberos and NTLM. NegoExts.dll is loaded into the Local System Authority (LSA) at startup. When an authentication request is received, based on the request's source, NegoExts negotiates between the supported SSPs. It gathers the credentials and policies, encrypts them, and sends that information to the appropriate SSP, where the security token is then created. The SSPs supported by NegoExts are not stand-alone SSPs such as Kerberos and NTLM. Therefore, within the NegoExts SSP, when the authentication method fails for any reason, an authentication failure message will be displayed or logged. No renegotiation or fallback authentication methods are possible.
Location: %windir%\Windows\System32\negoexts.dll
| Supported server versions | Supported client versions |
|---|---|
|
|
PKU2U Security Support Provider
The PKU2U protocol was introduced in Windows 7 and Windows Server 2008 R2 and implemented as an SSP. The SSP enables peer-to-peer authentication, particularly through the Windows 7 media and file sharing feature called Homegroup, which permits sharing between computers that are not members of a domain.
Location: %windir%\Windows\System32\pku2u.dll
| Supported server versions | Supported client versions |
|---|---|
|
|
Additional resources for the PKU2U protocol and the PKU2U SSP
Security Support Provider Selection
The Windows SSPI can use any of the protocols that are supported through the installed security support providers. However, because not all operating systems support the same SSP packages that any given Windows Server supports, clients and servers must negotiate to use a protocol that they both support. Windows Server prefers client computers and applications to use the Kerberos protocol, a strong standards-based protocol, when possible, but continues to allow client computers and client applications that do not support Kerberos, to authenticate.
Before authentication can take place, however, the two communicating computers must agree on a protocol that they both can support. For any protocol to be usable through the SSPI, each party must have the appropriate SSP. For example, in order for a client computer and server to use the Kerberos authentication protocol, they must both support Kerberos V5. Windows Server uses the function EnumerateSecurityPackages to identify which SSPs are supported on a computer and what the capabilities of those SSPs are.
The selection of an authentication protocol can be handled in one of two ways, each of which is described in the sections that follow.
Single authentication protocol specified
When a single acceptable protocol is specified on the server, the client computer must support the protocol specified or the communication fails. When a single acceptable protocol is specified, the authentication exchange takes place as follows:
The client computer requests access to a service.
The server replies to the request in which it specifies the protocol that will be used.
The client computer examines the contents of the reply and checks to determine whether it supports the specified protocol. If the client computer does support the specified protocol, the authentication continues. If the client computer does not support the protocol, the authentication fails, regardless of whether the client computer is authorized to access the resource.
Negotiate option is used
The negotiate option can be used to allow the parties to attempt to find an acceptable protocol. This is based on the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO, RFC 2478). When the authentication begins with the option to negotiate for an authentication protocol, the SPNEGO exchange takes place as follows:
The client computer requests access to a service.
The server replies with a list of authentication protocols that it can support and an authentication challenge or response based on the protocol that is its first choice. For example, the server might list the Kerberos protocol and NTLM, and send a Kerberos authentication response.
The client computer examines the contents of the reply and checks to determine whether it supports any of the specified protocols.
If the client computer supports the preferred protocol, authentication proceeds.
If the client computer does not support the preferred protocol, but does support one of the other protocols listed by the server, the client computer lets the server know which authentication protocol it supports, and the authentication proceeds.
If the client computer does not support any of the listed protocols, the authentication exchange fails.