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

  • 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

  • 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.8: Windows uses the capability specified in [RFC2617] to add a new directive via the auth-param in the digest-challenge message ([RFC2831] section 2.1.1). The server sends: charset=utf-8 in the auth-param field. This indicates that the server can process UTF-8 encoded strings and that the client might use Unicode encoding for the username field and in the password if it can also process UTF-8. Windows clients will use [UNICODE] encoding when it is offered by the server to allow authentication with a region's supported character sets.

<2> Section 2.1: In Windows, the Digest Authentication Protocol can be used for authentication during HTTP traffic through the use and configuration of Internet Information Server (IIS). In addition, LDAP clients and servers in an Active Directory domain can make use of the SASL mechanism for digest authentication.

The LDAP server in Active Directory offers digest authentication by default as one of several authentication mechanisms for Active Directory. This is exposed by the supported SASL Mechanism attribute, as specified in [RFC2829]. All native use of LDAP within Windows uses SPNEGO authentication not digest authentication.

<3> Section 2.1: Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 do not support channel binding for HTTP Digest Authentication.

<4> Section 2.2: Except on Windows 2000, when acting as a server, Windows attempts to decode the username field of the digest-response message ([RFC2617] section 3.2.2) using the RFC-compliant character escaping ([RFC2616] section 2.2).

However, if no account with that name can be found, or if the keyed hash computed by the server does not match the keyed hash sent by the client, the server attempts to decode the original username by using backslash '\' characters that are not properly escaped (treated as if the client specified '\\'), and then retries. Windows XP incorrectly escapes the backslash '\' character in the account name. If a backslash ('\') character is presented by the client, the string is treated as "NetbiosDomainName\\AccountName".

Unlike other authentication protocols, digest authentication does not support the diacritical folding that is applied by Active Directory.

<5> Section 2.2: The auth param extensions are not supported on Windows 2000.

<6> Section 3.1.3: The random number generator used in Windows is FIPS-140-compliant. For information on the FIPS-140 random number generator requirements, see [FIPS140] sections 4.7.1, 4.9.1, and 4.9.2.

<7> Section 3.1.4: For details on where digest authentication is used in the Windows environment, see section 1.6.

<8> Section 3.1.5.1: Windows digest implementations for HTTP do not support the Authentication-Info message. If a third-party server generates an Authentication-Info message, it is ignored on the Windows client. However, the third leg of the Digest Access Authentication: Microsoft Extensions as the SASL mechanism is supported, as specified in [RFC2831] section 2.1.3.

<9> Section 3.1.5.2: The realm directive is set to the domain name of the server by default. This can be overridden at the server by configuration options. The user is prompted and has the chance to override the realm value sent by the server (that is, the user can enter a realm other than the one sent by the server).

<10> Section 3.1.5.4: In Windows 2000, the opaque value is returned from the client to the server only during the initial authentication step. The opaque value is not returned for subsequent authentication ([RFC2617] section 3.3).

<11> Section 3.2.1: The Digest Access Authentication: Microsoft Extensions ensures that if the nonce count value wraps, the authentication fails.

<12> Section 3.2.5.1: In Windows (except Windows 2000), the cnonce contains 128 bits of entropy provided by a random-number generator, as specified in [FIPS140].

<13> Section 3.2.5.2: Applicable Windows Server releases indicate support for different qops, and clients select accordingly, using the qop values as specified in [RFC2617] section 3.2.1 (subject to exceptions specified in section 2.2) and in [RFC2831] section 2.1.1. The value of this directive depends on the quality of protection requested by the calling application. For information on Windows usage of the qop directive, see section 2.2.

<14> Section 3.2.5.2: Windows 2000 Server operating system accepts only quoted qop directive values as with 'qop="value"'.

<15> Section 3.3.5.1: In Windows (except Windows 2000), the nonce contains 128 bits of entropy provided by a random-number generator as specified in [FIPS140].

<16> Section 3.3.5.4: In Windows domain environments, validating the digest authentication exchange can be performed at a different computer (for more information, see [MS-APDS]). This does not affect the actual implementation of the digest authentication between the client and the server. For more information on digest authentication validation, see [RFC2617] section 3.2.2.