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 Server 2003 R2 operating system

  • Windows Server 2008 operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 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 3.1.3.1:  After the data described in the GetProxyTrustConfiguration section is obtained for the first time via a GetProxyTrustConfiguration exchange, Windows maintains a cached copy of the data described in the GetProxyTrustConfiguration section.

<2> Section 3.1.4.1: Windows sends a GetProxyTrustConfiguration request when the client service is started, and caches the data from the response. If the cached version of the data described in section GetProxyTrustConfiguration is not available when a security token request is received, Windows will attempt to obtain the data again by sending a GetProxyTrustConfiguration request upon receipt of the security token.

<3> Section 3.1.4.2: Windows always emits an <LsRequestSecurityTokenWithCookie> request message when the web browser requestor presents a session cookie, given that no token has been posted in the wresult parameter described by [MS-MWBF].

<4> Section 3.1.4.4: Windows always emits an LsRequestSecurityTokenWithCookie request message when the web browser requestor presents a session cookie, given that no token has been posted in the wresult parameter described by [MS-MWBF].

<5> Section 3.1.5.1.2.4: Windows displays the security realm display names to web browser requestors.

<6> Section 3.1.5.2.1:  Without modifying the code that ships with this component, Windows can only perform username and password authentication at the client component of this protocol.

<7> Section 3.1.5.2.1: Windows never specifies a particular account store identifier.

<8> Section 3.1.5.2.1: Windows will never emit a cookie value in the LsRequestSecurityToken request, because the presence of a session cookie in the request from the web browser requestor will cause Windows to emit a LsRequestSecurityTokenWithCookie message.

<9> Section 3.1.5.2.2.1: Windows uses the Status value and CredentialsVerification values to populate an error message for displaying to the web browser requestor.

<10> Section 3.1.5.2.2.2: Windows emits a GetProxyTrustConfiguration request if the policy version specified in the response does not match the locally cached version.

<11> Section 3.2.5.1.2.4: Windows allows administrators to enter the accepted authentication methods for a security realm. By default, all methods are acceptable and Windows returns an empty list for the acceptableAuthenticationMethodStrings element.

<12> Section 3.2.5.2.1:  In the server role, Windows supports both SSL client certificate authentication as well as username and password authentication.

<13> Section 3.2.5.2.1:  If an identifier is specified, and the identifier correctly identifies a configured account store, Windows will honor the request by using only that account store to generate claims about the user.

<14> Section 3.2.5.2.1:  If a cookie previously issued by the server is included in the request, Windows will validate that the cookie matches the credentials presented. If the validation fails, Windows will issue a status of "WrongPrincipal". If the validation succeeds, Windows will use the cookie contents to generate the claims as a performance optimization to avoid the account store.

<15> Section 3.2.5.2.2.3: Windows does not include the AdditionalValidationInfo element if the user validation was successful. If there was an error in validating the user, any string that represents the cause of the failure can be included here.

<16> Section 3.2.5.3.1:  If a cookie previously issued by the server is included in the request, Windows will validate that the cookie matches the credentials presented. If the validation fails, Windows will issue a status of "WrongPrincipal". If the validation succeeds, Windows will use the cookie contents to generate the claims as a performance optimization to avoid the account store.