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 released service packs.
Windows Server 2003 R2 operating system
Windows Server 2008 operating system
Windows Server 2008 R2 operating system
Windows Server 2012 operating system
Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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 220.127.116.11: 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 18.104.22.168: 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 22.214.171.124: 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 126.96.36.199: 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].
<6> Section 188.8.131.52.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 184.108.40.206.1: Windows never specifies a particular account store identifier.
<8> Section 220.127.116.11.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 18.104.22.168.2.1: Windows uses the Status value and CredentialsVerification values to populate an error message for displaying to the web browser requestor.
<10> Section 22.214.171.124.2.2: Windows emits a GetProxyTrustConfiguration request if the policy version specified in the response does not match the locally cached version.
<11> Section 126.96.36.199.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 188.8.131.52.1: In the server role, Windows supports both SSL client certificate authentication as well as username and password authentication.
<13> Section 184.108.40.206.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 220.127.116.11.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 18.104.22.168.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 MAY be included here.
<16> Section 22.214.171.124.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.