Integrated Windows Authentication: Negotiate, SSPI, and SPNEGO

Overview

Understanding Integrated Windows Authentication requires distinguishing the API, Security Support Providers (SSPs), the negotiation mechanism, and the actual authentication protocols.

Layer	Term	Role
Application protocol	HTTP, SMB, LDAP, RPC, and others	Carries opaque security tokens generated by SSPI to the peer.
API	Security Support Provider Interface (SSPI)	Windows API that lets applications handle credentials and security contexts without depending on the details of a specific protocol.
Security package / SSP	Negotiate, Kerberos, NTLM, Schannel, CredSSP, and others	Implements authentication and message protection behind SSPI’s shared API.
Negotiation mechanism	Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)	Meta-protocol that selects an authentication mechanism both sides support; it underpins the Windows Negotiate SSP.
Authentication mechanism	Kerberos, NTLM, and others	Actually authenticates principals and establishes session keys and security contexts.

In other words, Negotiate is not a “third credential validation method” alongside Kerberos and NTLM. When an application selects the Negotiate package through SSPI, the Negotiate SSP uses SPNEGO to choose a mechanism supported by both sides. Kerberos or NTLM then usually performs the actual authentication.

flowchart LR
    A[Application<br/>HTTP / SMB / LDAP / RPC] -->|SSPI API| S[SSPI]
    S --> N[Negotiate SSP]
    N -->|Selected by SPNEGO| K[Kerberos SSP]
    N -->|Selected by SPNEGO| M[NTLM SSP]
    K --> T[Opaque security token]
    M --> T
    T -->|Carried by application protocol| P[Peer]

SSPI and SSPs

The Security Support Provider Interface (SSPI) is Windows’ shared authentication API. Applications and infrastructure services use Security Support Providers (SSPs) through SSPI. SSPI itself is not a network transport; the application protocol is responsible for carrying generated tokens over HTTP, SMB, RPC, or another transport.

The main benefits of SSPI are:

Applications do not need to construct the wire format of Kerberos tickets or NTLM messages directly.
Different security packages can be selected through the same API.
After authentication, capabilities such as integrity, confidentiality, and impersonation can be used according to the established security context.
Applications treat security tokens as opaque and do not need to read session keys or ticket caches directly.

Microsoft documentation uses “SSP” and “authentication package” in related contexts. Here, packages selectable through SSPI are collectively called SSPs or security packages.

Negotiate and SPNEGO

SPNEGO is a meta-protocol for safely selecting a mechanism that both parties support from multiple Generic Security Services (GSS)-compatible mechanisms. It does not authenticate a user on its own; at least one actual authentication mechanism is needed. SPNEGO tokens are also carried inside another application protocol, such as SMB, HTTP, RPC, or LDAP; SPNEGO is not a standalone transport.

The Windows Negotiate security package usually chooses between Kerberos and NTLM. It prefers Kerberos when the prerequisites for using it are met. Microsoft’s Negotiate documentation lists the following target names that let a client application select Kerberos:

Service Principal Name (SPN)
User Principal Name (UPN)
NetBIOS account name

For service authentication in particular, passing the correct SPN as the target name is important. The official SSPI documentation for InitializeSecurityContext also calls for a valid SPN to help mitigate replay attacks.

Negotiate does not always mean Kerberos

NTLM may be selected even when Negotiate is requested.

Domain, trust, OS, or application conditions prevent Kerberos from being used.
The client application does not provide the target information Kerberos needs.
Kerberos prerequisites such as SPN, DNS, KDC reachability, or time synchronization are unmet.
Client and server security policies or supported packages do not match.

This does not mean “every Kerberos error always triggers a retry with NTLM.” SPNEGO supports Late Fallback for non-fatal failures, but the outcome depends on both parties’ support and the type of error. Duplicate SPNs, a principal mismatch, or a policy that rejects NTLM may instead cause authentication to fail. Do not rely on fallback in operational design; confirm that Kerberos succeeded.

Relationship to HTTP `Negotiate`

In HTTP, the server commonly presents WWW-Authenticate: Negotiate and the client responds with Authorization: Negotiate <token>. Here, Negotiate names the HTTP authentication scheme. Within the token, SPNEGO may select Kerberos or NTLM.

The layers remain separate when HTTPS is used:

HTTPS:       TLS / Schannel protects the transport
HTTP auth:   Negotiate / SPNEGO selects Kerberos or NTLM
Application: IIS or another application authorizes the authenticated identity

TLS alone does not prevent NTLM fallback, and using Negotiate alone does not make the entire transport use TLS.

Difference from Negotiate Extensions

Negotiate Extensions (NegoExts) is a separate authentication package for selecting SSPs other than NTLM or Kerberos in particular Microsoft or third-party scenarios. The Windows Negotiate package can also consider NegoExts, but it does not renegotiate to another method if an authentication method selected within NegoExts fails. It is important not to conflate SPNEGO, the Negotiate SSP, and NegoExts.

Basic SSPI API flow

Conceptually, an SSPI application follows this process. Consult the API reference for the selected package for actual arguments, buffer management, and error handling.

sequenceDiagram
    participant CA as Client application
    participant CS as Client SSPI
    participant SA as Server application
    participant SS as Server SSPI

    CA->>CS: AcquireCredentialsHandle("Negotiate", OUTBOUND)
    SA->>SS: AcquireCredentialsHandle("Negotiate", INBOUND)
    loop While SEC_I_CONTINUE_NEEDED
        CA->>CS: InitializeSecurityContext(target SPN, input token)
        CS-->>CA: output token
        CA->>SA: Carry token in application protocol
        SA->>SS: AcceptSecurityContext(input token)
        SS-->>SA: output token
        SA->>CA: Return response token if needed
    end
    CS-->>CA: SEC_E_OK / client security context
    SS-->>SA: SEC_E_OK / server security context

The main APIs have these responsibilities:

API	Role
`EnumerateSecurityPackages` / `QuerySecurityPackageInfo`	Discover available packages and capabilities.
`AcquireCredentialsHandle`	Obtain a credential handle referring to existing logon credentials or similar material. This is not itself a network logon.
`InitializeSecurityContext`	Start or continue an outbound client security context and generate a token to send to the peer.
`AcceptSecurityContext`	Process a received token on the server and start or continue an inbound security context.
`QueryContextAttributes`	Inspect the selected package, peer name, context capabilities, and more. It can also identify the package actually selected by Negotiate.
`MakeSignature` / `VerifySignature`	Provide and verify message integrity with an established context.
`EncryptMessage` / `DecryptMessage`	Provide and verify message confidentiality and integrity when the package supports them.
`ImpersonateSecurityContext` / `RevertSecurityContext`	Run a server thread in the authenticated client’s security context, then revert it.
`DeleteSecurityContext` / `FreeCredentialsHandle`	Release the context and credential handle. Release SSPI-allocated buffers with `FreeContextBuffer`.

InitializeSecurityContext and AcceptSecurityContext may each be called multiple times while they return SEC_I_CONTINUE_NEEDED or similar results. An application carries the contents of SECBUFFER_TOKEN to the peer without interpreting them. It must also check that the returned context attributes satisfy the requested mutual authentication, integrity, confidentiality, and delegation, rather than relying only on a final SEC_E_OK.

Security contexts and credential delegation

A security context obtained after successful authentication represents an authenticated identity and session-specific security state. However, these are not the same thing:

Establishing a security context
Establishing a TLS transport
The server receiving the client’s reusable credentials
The server being able to delegate to another server as the client

For example, with ordinary Kerberos / NTLM remote authentication, the server does not receive the client’s plaintext password. Whether the server can delegate the client identity to another server depends on Kerberos delegation, requested context flags, account policy, and the application’s implementation. CredSSP differs: it delegates the user credentials themselves to the target server over TLS and SPNEGO.

Investigation and protection

Check whether the application requests the Negotiate, Kerberos, or NTLM package.
Use an FQDN and the correct SPN as the target name; avoid IP addresses and ambiguous aliases.
Use klist, setspn -Q / setspn -X, event logs, and network traces to check whether a Kerberos ticket was actually used.
Introduce NTLM audit and restriction policies gradually and identify applications that depend on fallback.
For HTTP and similar protocols, consider Extended Protection for Authentication (EPA) and Channel Binding Tokens (CBTs) in addition to TLS.
Application developers should supply a valid target name, check final context attributes, and reliably release handles and buffers.
Do not write authentication tokens to logs. Even opaque tokens may matter in investigations of replay attacks or information leaks.

Official Microsoft documentation

Security Support Provider Interface Architecture: SSPI architecture, standard SSPs, and the relationship between Negotiate and SPNEGO.
Microsoft Negotiate: How the Negotiate SSP selects a mechanism and the target names needed for Kerberos.
Using Security Packages: How SSPI uses the Kerberos and NTLM packages.
InitializeSecurityContext (Negotiate): Client context establishment, the token loop, target SPNs, and context attributes.
AcceptSecurityContext (General): Server context establishment and package-specific APIs.
MS-SPNG: SPNEGO Synopsis: SPNEGO, opaque security tokens, and Late Fallback.
MS-SPNG: Relationship to Other Protocols: SMB, HTTP, RPC, and LDAP as carriers of SPNEGO, and its role as a meta-protocol.