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.
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 XP operating system Service Pack 3 (SP3)
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
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows 11 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: By default, SPNEGO has the Kerberos Protocol and NTLM ([MS-NLMP]) available. With the exception of Windows XP SP3, the interface for authentication protocols is open and extensible.
<2> Section 1.5: In Windows, the CredSSP client first checks whether the user's credentials were passed in by the calling application. If so, these credentials are used by the client. If no credentials were passed in by the calling application, the CredSSP Protocol uses credentials that are stored locally in the credentials manager that is associated with the target server. If no credentials are available for the target server, the CredSSP client uses the user's default credentials, which are entered when the user first logs on to the operating system.
<3> Section 1.5: In Windows, the SPNEGO client negotiates Kerberos or NTLM. The Kerberos Protocol is always preferred over NTLM. NTLM is negotiated only if one or both parties do not support the Kerberos Protocol, as specified in [MS-NLMP] section 1.5 and in [MS-KILE].
<4> Section 2.1: The Windows component that implements the CredSSP Protocol is transport-independent—it simply returns opaque CredSSP data back to the calling application. It is up to the calling application to send this CredSSP Protocol data over a reliable transport to its CredSSP Protocol peer.
<5> Section 2.2: The CredSSP server is not supported on Windows XP SP3.
<6> Section 2.2: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<7> Section 2.2.1: Windows CredSSP clients never send Kerberos.
<8> Section 2.2.1: The CredSSP standard requires that a TLS encrypted message fragment contain an entire ASN.1 message. CredSSP expects the entire first tag and length to fall in the initial block of decrypted data and for the client to encrypt TSRequest messages as single blocks subject only to fragmentation at TLS’s maximum message length. The CredSSP server expects a TLS encryption of an entire TSRequest message without fragmentation. Otherwise, the server returns an error.
<9> Section 2.2.1: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<10> Section 2.2.1: In Windows XP SP3, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012, only version 2 of the CredSSP Protocol is supported.
<11> Section 2.2.1: Windows Group Policy determines which minimum protocol version is accepted by the client.
<12> Section 2.2.1: Windows XP SP3, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 do not implement the errorCode field.
<13> Section 2.2.1.1: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<14> Section 2.2.1.2: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<15> Section 2.2.1.2.1: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<16> Section 2.2.1.2.2: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<17> Section 2.2.1.2.2.1: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<18> Section 2.2.1.2.3: The TSRemoteGuardCreds structure is only supported on Windows 10 v1607 operating system client version and on Windows Server 2016 server version and later.
<19> Section 2.2.1.2.3: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<20> Section 2.2.1.2.3.1: Where data is a text string, Windows uses a Unicode string defined by a UNICODE_STRING structure to encode to ASN.1 OCTET STRING format. For more information see [MSDOCS-UNICODE_STRING]. For a description of Octet String see [MS-DTYP] and [X690].
<21> Section 2.2.1.2.3.1: Windows CredSSP servers use authentication packages provided by Microsoft.
<22> Section 2.2.1.2.3.1: In Windows, the logon credentials that are in the logonCred field of TSRemoteGuardCreds structure are required to be in a KERB_TICKET_LOGON structure ([KERB-TICKET-LOGON]). The TicketGrantingTicket member within the KERB_TICKET_LOGON structure is an ASN.1-encoded KRB_CRED message ([RFC4120], section 5.8.1). The EncryptionKey in KrbCredInfo ([RFC4120], section 5.8.1) is required to be in a KERB_RPC_ENCRYPTION_KEY structure ([MS-RDPEAR] section 2.2.1.2.8). The ServiceTicket member within the KERB_TICKET_LOGON structure is a ticket to the computer account. Windows CredSSP clients do not use Kerberos User to User tickets ([RFC4120], section 2.9.2) as the ServiceTicket, but can if necessary; the server does not enforce this. The session key of the ServiceTicket is used to encrypt the EncryptedData in the KRB_CRED message.
Supplemental credentials that are in the supplementalCreds field of TSRemoteGuardCreds structure are required in the following structure:
-
typedef struct _NTLM_REMOTE_SUPPLEMENTAL_CREDENTIAL { ULONG Version; ULONG Flags; MSV1_0_CREDENTIAL_KEY CredentialKey; MSV1_0_CREDENTIAL_KEY_TYPE CredentialKeyType; ULONG reservedsize; [size_is(reservedSize)] UCHAR* reserved; } NTLM_REMOTE_SUPPLEMENTAL_CREDENTIAL;
Version: A 32-bit unsigned integer that defines the credential version. This field is 0xFFFF0002.
Flags: A 32-bit unsigned integer containing flags that define the credential options. At least one of the following values is required.
-
0
1
2
3
4
5
6
7
8
91
0
1
2
3
4
5
6
7
8
92
0
1
2
3
4
5
6
7
8
93
0
10
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
C
0
N
L
Where the bits are defined as follows.
-
Value
Description
L
Indicates that the LM OWF member is present and valid.
N
Indicates that the NT OWF member is present and valid.
C
Indicates that the reserved credential key is present and valid ([MS-RDPEAR] section 2.2.1.3.5).
All other bits are set to zero and ignored on receipt.
CredentialKey: An MSV1_0_CREDENTIAL_KEY structure, see reserved5 field in [MS-RDPEAR] section 2.2.1.3.6. The credential key is a 20-byte length unsigned char (UCHAR [MS-DTYP] section 2.2.45) array and is calculated from the user’s password as follows:
The NTOWF of the user is calculated from the password as described in [MS-NLMP] section 3.3.1.
The previous NTOWF result is then used to obtain a 32-byte length intermediate key using the PBKDF2 function ([RFC2898] section 5.2) with the NTOWF as the password, the SID of the user in UNICODE_STRING format as the salt, SHA256 as the hash algorithm, and an iteration count of 10,000.
The final 16-byte key is calculated by running one iteration of PBKDF2 with the intermediate key as the password, the SID of the user in UNICODE_STRING format as the salt, and SHA256 as the hash algorithm. The last four bytes MUST be zeroed.
CredentialKeyType: A 32-bit unsigned integer. This MUST be 2. The DomainUserCredKey value from the MSV1_0_CREDENTIAL_KEY_TYPE enum, see reserved4 field in [MS-RDPEAR] section 2.2.1.3.6 MSV1_0_REMOTE_ENCRYPTED_SECRETS.
reservedsize: A ULONG that contains the size of the reserved field. See [MS-RDPEAR] section 2.2.1.3.6.
reserved: A pointer to a UCHAR, an array of characters that contains the credential. See reserved6 field in [MS-RDPEAR] section 2.2.1.3.6 MSV1_0_REMOTE_ENCRYPTED_SECRETS structure.
<23> Section 3.1.1: In Windows, the policy settings for the CredSSP client are expressed in terms of service principal names (SPNs), which define the servers to which the client is allowed to send the user's credentials.
<24> Section 3.1.5: With the exception of Windows XP SP3, the CredSSP server can be configured by using any X.509 certificate that is trusted by the client based on a commonly trusted certificate authority (CA) root or by using a self-signed certificate.
<25> Section 3.1.5: Version 5 of the protocol is available in Windows Server v1803 operating system and later, and by downloading a version-specific update from [MSKB-4088776]. Group Policy determines which minimum protocol version is accepted by the client.