6 Appendix A: Product Behavior

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

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system

  • Windows Server 2016 operating system

  • Windows Server 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 [NEGOEX-DRAFT]. The OID assigned for NEGOEX is iso.org.dod.internet.private.enterprise.Microsoft.security.mechanisms.NegoEx (

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

<2> Section 1.4: Windows 2000, 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 ( 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 on a specific system by third parties.

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

<5> 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.

<6> Section 3.1.1: Windows exposes this logical parameter (FragmentToFit) to applications through the SSPI interface on Windows.

<7> Section 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. 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 accept_complete and no mechListMIC field.

On all other product versions shown in the applicability list at the beginning of this section, 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, 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.

<8> Section 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).

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