Partager via

6 Appendix A: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.

Windows Client

  • Windows 2000 Professional operating system

  • Windows XP operating system

  • Windows Vista operating system

  • Windows 7 operating system

  • Windows 8 operating system

  • Windows 8.1 operating system

  • Windows 10 operating system

  • Windows 11 operating system

Windows Server

  • Windows 2000 Server operating system

  • Windows Server 2003 operating system

  • Windows Server 2008 operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 operating system

  • Windows Server 2012 R2 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system

  • Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.4: Windows negotiates the following authentication protocols by using the object identifier (OID) assigned to them:

  • Kerberos Network Authentication Service (V5) protocol [RFC4120] [MS-KILE].

  • User-to-User Kerberos Authentication [UUKA-GSSAPI].

  • Extended GSS-API Negotiation Mechanism (NEGOEX) protocol [IETFDRAFT-NEGOEX-02]. The OID assigned for NEGOEX is iso.org.dod.internet.private.enterprise.Microsoft.security.mechanisms.NegoEx (1.3.6.1.4.1.311.2.2.30).

  • NT LAN Manager (NTLM) Authentication Protocol [MS-NLMP].

<2> Section 1.4: Windows 2000 operating system, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 do not support PKU2U [PKU2U-DRAFT]. Windows implementations of NEGOEX negotiate the following authentication protocols by the corresponding OIDs and AuthScheme GUIDs: so.org.dod.internet.security.kerberosv5.PKU2U. The OID and GUID assigned for PKU2U [PKU2U-DRAFT] is (1.3.6.1.5.2.7) 235F69AD-73FB-4dbc-8203-0629E739339B.

<3> Section 1.5: By default, the Kerberos protocol and NTLM are available in Windows. The interface for authentication protocols in Windows is open and extensible; other protocols might be installed by third parties.

<4> Section 2.2.1: Windows generates the NegTokenInit2 message.

<5> Section 2.2.1: Windows implementations use Microsoft Kerberos as the preferred optimistic mechanism by default.

<6> Section 2.2.1: In Windows 2000, Windows XP, and Windows Server 2003, the negHints.hintName field contains the name of the server principal, which is the service principal on the server in the form user-name@domain-name. The name is expressed in ANSI encoding, which uses an original equipment manufacturer (OEM) code page that the local system defines. For two parties to use this extension, they have to agree on the OEM code page prior to using this protocol.

<7> Section 3.1.1: Windows exposes the FragmentToFit logical parameter to applications through the SSPI interface on Windows.

<8> Section 3.1.5.1: Windows 2000, Windows Server 2003, and Windows XP do not process the mechListMIC field. No mechListMIC value is produced when either the client or server completes the exchange. The GSS mechanism notifies the SPNEGO extension that the server is pre-Windows Vista. When a Windows Vista and later client sends the last GSS token to a Windows Server 2003 or earlier server, it omits negState from the NegTokenResp message per [RFC4178] section 4.2.2. If a mechListMIC value is supplied to either the client or server, it is ignored. If the initiator in the GSS exchange has the last GSS token, the server returns a NegTokenResp token that has the negState field set to the accept_complete state and no mechListMIC field.

On all other product versions shown in the applicability list the following processing is used for the mechListMIC field:

  • If AES Kerberos ciphers are negotiated by Kerberos, the signature in the SPNEGO mechListMIC field has to be processed by the recipient.

  • If NTLM authentication is most preferred by the client and the server, and the client includes a MIC in AUTHENTICATE_MESSAGE ([MS-NLMP] section 2.2.1.3), then the mechListMIC field becomes mandatory in order for the authentication to succeed. Windows clients in this case send an NTLM token instead of an SPNEGO token.

<9> Section 3.1.5.2: Except in Windows 2000, Windows offers and accepts both standard and truncated OIDs as identifiers for the Kerberos authentication mechanism.

Windows 2000 incorrectly encoded the OID for the Kerberos protocol in the supportedMech field. Rather than the OID { iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2) }, an implementation error truncated the values at 16 bits. Therefore, the OID became { iso(1) member-body(2) United States(840) ???(48018) infosys(1) gssapi(2) krb5 (2) }.

Windows clients will fail if the accepter accepts the preferred mechanism token (1.2.840.48018.1.2.2) and produces a response token with the supportedMech being the standard Kerberos OID (1.2.840.113554.1.2.2).

<10> Section 3.3.5: Windows 2000, Windows Server 2003, and Windows Vista do not support non-compliant implementations of [RFC4178] that send a supportedMech field in a subsequent NegTokenResp message.