2.1.2.2 Protocol Interactions
The following diagram illustrates the protocol interactions of the network logon authentication.
Figure 7: Protocol interactions for network logon authentication
As the preceding diagram shows, Authentication Services includes the following authentication and auxiliary protocols.
Authentication protocols:
Digest Protocol Extensions [MS-DPSP]
Credential Security Support Provider (CredSSP) Protocol [MS-CSSP]
NT LAN Manager (NTLM) Authentication Protocol [MS-NLMP]
Secure Sockets Layer (SSL)/Transport Layer Security (TLS) Protocols (SSL/TLS) [MS-TLSP]
Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism (SPNEGO) Protocol Extensions [MS-SPNG]
The Extended GSS-API Negotiation Mechanism (NEGOEX) [IETFDRAFT-NEGOEX-02]
SPNEGO Extended Negotiation (NEGOEX) Security Mechanism (NEGOEX-04) [MS-NEGOEX]
Public Key Cryptography Based User-to-User Authentication - (PKU2U) [PKU2U-DRAFT]
Kerberos Proxy Key Distribution Protocol [MS-KKDCP]
Auxiliary Protocols:
Authentication Protocol Domain Support [MS-APDS]
Remote Certificate Mapping Protocol [MS-RCMP]
Netlogon Remote Protocol [MS-NRPC]
Custom Authentication Protocols:
Authentication Services provides an extensible network logon authentication architecture, which allows implementers to add custom authentication protocol security support providers (SSPs) to the system architecture.
Authentication protocol selection
Both the client and server application protocols can select any authentication protocol from the list of supported authentication protocols through the GSS-API interface, either directly or indirectly.
The client and server application protocols can directly select any of the following authentication protocols through the GSS-API interface: Digest [MS-DPSP], NTLM [MS-NLMP], CSSP [MS-CSSP], Kerberos [MS-KILE], and SPNEGO [MS-SPNG].
Application protocols can select indirectly any of the following authentication protocols: NTLM [MS-NLMP], Kerberos [MS-KILE], NEGOEX [MS-NEGOEX], PKU2U, and CUSTOM.
The difference between direct and indirect selection is the use of the SPNEGO protocol. Application protocols use the SPNEGO protocol when they attempt to select an authentication protocol indirectly; alternatively, application protocols can select the authentication protocol directly without using SPNEGO. Because support for these authentication protocols varies across Windows releases and application environments, the client and server application protocols have to select a mutually supported authentication protocol either directly or indirectly. For example, for a client and server to use the Kerberos authentication protocol, each have to support it.
An authentication protocol is selected in one of three ways:
Assertion
Application-Level Negotiation
Negotiate
Application-Level Negotiation uses the application-specific method or configuration to select the mutually agreed-on authentication protocol between client and server application protocols, whereas the other two options use Authentication Services.
Assertion
As a precondition for using Assertion to specify a mutually agreed-on authentication protocol when calling GSS-API, both the client and the server directly specify a single authentication protocol from the supported authentication protocols.
When the application or server uses only one authentication protocol for the exchange, it specifies (asserts) the protocol to use when replying to a client request to access a service. If the client does not support that protocol, the communication fails. This method of selection is called Assertion.
Application-Level Negotiation
When a client and a server support multiple authentication protocols, before authentication can take place, applications exchange application-specific messages to select a commonly supported authentication protocol. For example, if a client supports Kerberos and Digest and the server supports NTLM and Digest, the common protocol that they both support is Digest, so the client and the server can negotiate to use the Digest protocol. Similarly, the HTTP protocol uses the WWW-Authenticate and Authorization headers in its negotiation.
Negotiate
The Negotiate option allows the client and server applications that are engaged in the authentication process to select a mutually agreed-upon authentication protocol from a set of possible authentication protocols by using the SPNEGO protocol [MS-SPNG].
When the authentication process begins with the option to negotiate for an authentication protocol, the server or client can initiate the negotiation.
The server-initiated SPNEGO exchange takes place as follows:
The client requests access to a service in an application-protocol-specific way.
The server replies with a list of authentication protocols that it supports with its preferred authentication protocol as its first choice in the application protocol message. For example, the server might list Kerberos [MS-KILE], NEGOEX [MS-NEGOEX], and NTLM [MS-NLMP], and select Kerberos as its preferred protocol.
The client examines the contents of the reply and checks to determine whether it supports any of the specified protocols.
If the client supports the preferred authentication protocol, authentication proceeds.
If the client does not support the preferred authentication protocol but does support one of the other protocols that the server lists, the client informs the server as to which authentication protocol it supports, and the authentication process continues.
If the client does not support any of the listed protocols, the authentication exchange fails.
The client-initiated SPNEGO takes place as follows:
The client sends a list of authentication protocols and also a preferred authentication protocol to the server.
The server examines the contents of the request message and checks to determine whether it supports any of the specified authentication protocols.
If the server supports the preferred authentication protocol, authentication proceeds.
If the server does not support the preferred authentication protocol but does support one of the other protocols that the client lists, the server informs the client as to which authentication protocol it supports, and the authentication process continues.
If the server does not support any of the listed protocols, the authentication exchange fails.
As shown in the preceding diagram, through the negotiation option, the client and server applications can select NTLM, Kerberos, PKU2U, or a custom authentication protocol as the mutually agreed-on authentication protocol. To select either the PKU2U or the custom authentication protocol, the application uses the NEGOEX protocol, which extends the SPNEGO protocol and enables the application protocol to choose a mutually agreed-on authentication protocol that is based on policy information.
For example, if the server specifies Kerberos and NTLM and returns Kerberos as its preferred authentication protocol, one client can immediately authenticate by using Kerberos, but another client could negotiate to complete the authentication exchange by using NTLM.
Auxiliary protocols
If the client and server agree on any of the following authentication protocols: Digest [MS-DPSP], NTLM [MS-NLMP], or SSL/TLS [MS-TLSP], an auxiliary protocol carries the credentials information from the server to the Authentication Authority (AA), for example, a Windows DC. This mechanism is called a pass-through mechanism.
When the client and server agree on either the Digest or the NTLM protocol, the Authentication Protocol Domain Support [MS-APDS] performs the pass-through. Otherwise, if the client and server agree on SSL/TLS, Remote Certificate Mapping Protocol [MS-RCMP] is used for pass-through.