Compartir a través de

5 Appendix A: Product Behavior

  • Artículo

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 Client

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Vista operating system

  • Windows 7 operating system

  • Windows 8 operating system

  • Windows 8.1 operating system

  • Windows 10 operating system

  • Windows 11 operating system

Windows Server

  • Windows Server 2003 operating system

  • Windows Server 2008 operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 operating system

  • Windows Server 2012 R2 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 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: Because Kerberos does not account directly for authorization information such as group membership or logon policy information but does allow a field within the Kerberos ticket to carry authorization information, Windows uses that field to carry information about Windows groups. When Windows receives the structure containing group information, Windows can interpret the group information in a manner consistent with other authorization decisions and information on the system.

<2> Section 2.2.3: The DOMAIN_GROUP_MEMBERSHIP structure is not supported in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

<3> Section 2.4: Windows 2000, Windows XP, and Windows Server 2003 do not support UPN and DNS information.

<4> Section 2.4: The client claims information structure is not supported in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.

<5> Section 2.4: The device information structure is not supported in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.

<6> Section 2.4: The device claims information structure is not supported in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.

<7> Section 2.4: For more information about the ticket signature, see Kerberos Security Feature Bypass Vulnerability security update November 2020 [MSFT-CVE-2020-17049]. This update applies to  Windows Server 2008 operating system with Service Pack 2 (SP2) and later.

<8> Section 2.4: The PAC Attributes value is not supported in Windows Server 2008 Service Pack 1 and earlier.

<9> Section 2.4: The PAC Requestor SID value is not supported in Windows Server 2008 Service Pack 1 and earlier.

<10> Section 2.4: For more information about the Extended KDC checksum usage see section 2.8.3. See also Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability security update, November 2022 [MSFT-CVE-2022-37966] and Windows Kerberos Elevation of Privilege Vulnerability security update November 2022 [MSFT-CVE-2022-37967]. These updates apply to Windows Server 2008 with SP2 and later.

<11> Section 2.5: Windows enforces the LogoffTime value for SMB connections only.

<12> Section 2.5: Windows enforces the KickoffTime value for SMB connections only.

<13> Section 2.6.1: This buffer is inserted into the PAC only when initial authentication is done through the PKINIT protocol (as specified in [RFC4556]) and is inserted only during initial logon; it is not included when the ticket-granting ticket (TGT) is used for further authentication.

<14> Section 2.6.1: RC4 with Hash Message Authentication Code (HMAC) is preferred and is most often seen, except when the principal has been configured to require a Data Encryption Standard (DES) encryption type.

<15> Section 2.6.1: AES128_CTS_HMAC_SHA1_96 is not used in Windows 2000, Windows XP, or Windows Server 2003.

<16> Section 2.6.1: AES256_CTS_HMAC_SHA1_96 is not used in Windows 2000, Windows XP, and Windows Server 2003.

<17> Section 2.6.3: The only package name that Microsoft KDCs use is "NTLM". If any other package name is provided, Windows discards the supplemental credential.

<18> Section 2.8.2: For more information about the ticket signature, see Kerberos Security Feature Bypass Vulnerability security update November 2020 [MSFT-CVE-2020-17049]. This update applies to  Windows Server 2008 with SP2 and later.

<19> Section 2.8.3: For more information about the Extended KDC Signature, see Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability security update November 2022 [MSFT-CVE-2022-37966] and Windows Kerberos Elevation of Privilege Vulnerability security update November 2022 [MSFT-CVE-2022-37967]. These updates apply to Windows Server 2008 with SP2 and later.

<20> Section 2.8.5: AES is not supported in Windows 2000 and Windows Server 2003.

<21> Section 2.8.5: AES is not supported in Windows 2000 and Windows Server 2003.

<22> Section 2.9: Constrained delegation is not supported in Windows 2000.

<23> Section 2.10: Windows 2000, Windows XP, and Windows Server 2003 do not support UPN and DNS information. The SAM name and SID are not supported by Windows 2000 Server operating system,  Windows Server 2003, and Windows Server 2008 Service Pack 1.

<24> Section 2.11: For implementations that use a Windows authorization model, it is used to populate a Token/Authorization Context as defined in [MS-DTYP] section 2.5.2.

The client claims information structure is not supported in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.

<25> Section 2.12: For implementations that use a Windows authorization model, it is used to populate a Token/Authorization Context as specified in [MS-DTYP] section 2.5.2. The device information structure is not supported in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.

<26> Section 2.13: For implementations that use a Windows authorization model, it is used to populate a Token/Authorization Context as specified in [MS-DTYP] section 2.5.2. The device claims information structure is not supported in Windows 7, and earlier or in Windows Server 2008 Service Pack 1 and earlier.

<27> Section 2.14: For implementations that use a Windows authorization model, it is used to populate a Token/Authorization Context as specified in [MS-DTYP] section 2.5.2. The device claims information structure is not supported in Windows 7 and earlier or in Windows Server 2008 Service Pack 1 and earlier.

<28> Section 2.15: For implementations that use a Windows authorization model, it is used to populate a Token/Authorization Context as specified in [MS-DTYP] section 2.5.2. The device claims information structure is not supported in Windows 7 and earlier or in Windows Server 2008 Service Pack 1 and earlier.

<29> Section 4.1.2: Windows enforces SID-filtering rules.

<30> Section 4.1.2: Interdomain trusts have been augmented with filtering information to prevent forged identity attacks. For trusts between two Windows domains, all of the SIDs are validated in the PAC. For trusts between a Windows Kerberos domain and a Massachusetts Institute of Technology (MIT) Kerberos realm, as specified in [RFC4120], SIDs are irrelevant, but a similar attack can be mounted by spoofing the cname within a cross-realm TGT.

<31> Section 4.1.2.2: Windows 2000 domain controllers do not perform SID filtering on PACs arriving from outside the domain. Windows 2000 domain controllers do not filter an arriving PAC for SIDs that are defined locally to the computer processing the PAC. 

<32> Section 4.1.2.2: Claims transformation is not supported on Windows 2000, Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 domain controllers.

<33> Section 4.1.2.2: Claims transformation is not supported on Windows 2000, Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 domain controllers.

<34> Section 4.1.2.2: Privileged Identity Management trusts are not supported on Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 operating system. They are supported on Windows Server 2012 R2 domain controllers when [MSKB-3155495] is also installed.

<35> Section 4.1.2.2: Where an action is followed by an asterisk (*), Windows 2000, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 treat the pattern as DomainSpecific.

<36> Section 4.1.2.2: Windows 2000, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 treat this pattern as ForestSpecific.

<37> Section 4.1.2.2: Windows 2000, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 treat this pattern as ForestSpecific.

<38> Section 4.1.2.3: The TGT's crealm field is compared against the realm names listed on the TDO, as specified in [MS-ADTS], corresponding to the cross-realm trust. If there is a mismatch, the TGT is rejected. TDOs marked as within the forest pass all crealm names through. TDOs marked as forest transitive indicate that the server will only accept crealm names if it is a name claimed by the forest on the TDO. If the TDO used for the cross-realm TGT has neither indicator set, the server checks if the FQDN matches the FQDN of any domain in the server's forest; if so, the TGT is accepted. Finally, if the crealm field matches the FQDN of the TDO, then it is accepted.