7 Appendix B: 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.

The following tables show the relationships between Microsoft product versions or supplemental software and the roles they perform.

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.3.2: There is no supported configuration in which this method is called from Windows clients. See section 2.2.7.15 for details on the conditions under which this method is called from a client.

<2> Section 1.6: The DC implementation of this protocol is largely for backward compatibility with Windows NT 4.0–style applications. The LDAP protocol can be used to access a superset of the information exposed in this protocol (see [MS-ADTS] section 3.1.1.3). The notable exceptions to this rule are that Windows clients use this protocol to join a domain ([MS-ADOD] sections 2.7.7 and 3.1) and that they use the SamrUnicodeChangePasswordUser2 method to change passwords.

<3> Section 1.6: Windows clients depend on this protocol to perform an end-user password change and join computers to a domain, as specified in [MS-ADTS] section 6.4.

<4> Section 1.7.1: The following table depicts a timeline of when each method was introduced. The Product column indicates the Windows version in which each method was introduced. Unless otherwise noted, all methods listed in the table continue to be supported in later versions of Windows according to the applicability lists at the beginning of this section.

<5> Section 1.7.2: Windows clients call deprecated methods under the following conditions. There is no benefit in doing so.

<6> Section 1.7.3: All information levels are supported in Windows NT 4.0, Windows 2000 Server, and later with the exception of GroupReplicationInformation for SamrQueryInformationGroup. This information level is supported in Windows Server 2003, and later.

<7> Section 2.1: Windows NT operating system, Windows 2000, Windows Server 2003, and Windows Server 2003 R2 operating system implementations of the server for this protocol can be configured to use the SPX (NCACN_SPX) protocol, as specified in [MS-RPCE] section 2.1.1.3; the AppleTalk (NCACN_AT_DSP) protocol, as specified in [MS-RPCE] section 2.1.1.7; and the Banyan VINES protocol. This configuration can be enabled by adding the following registry values of type REG_DWORD and by modifying the value to be nonzero:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

• For SPX: NetWareClientSupport

• For Appletalk: AppletalkClientSupport

• For Banyan VINES: VinesClientSupport

In addition, none of the Windows implementations of the client for this protocol can be configured to use protocols that are not listed in section 2.1.

<8> Section 2.1: Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 process calls for all opnums over the RPC-over-named-pipes (NCACN_NP) protocol. Windows Vista operating system with Service Pack 2 (SP2), Windows 7, and later, and Windows Server 2008 operating system with Service Pack 2 (SP2), Windows Server 2008 R2, and later behave in the same way, except that calls made to SamrValidatePassword using NCACN_NP are rejected with RPC_S_ACCESS_DENIED.

<9> Section 2.1: By default, the endpoint "\PIPE\samr" allows anonymous access on Windows NT 3.1, Windows NT 3.5, Windows NT 3.51, Windows 2000, Windows XP, Windows Server 2003, Windows Server 2003 R2, and Windows Vista. Anonymous access to this pipe on non–domain controller machines is removed by default on Windows Vista operating system with Service Pack 1 (SP1), Windows 7, and later, and on Windows Server 2008 and later. The pipe access check happens before any other access check, and therefore overrides any other access.

<10> Section 2.1: Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 process calls for all opnums over TCP (NCACN_IP_TCP). Windows Vista SP2, Windows 7, and later, and Windows Server 2008 with SP2, Windows Server 2008 R2, and later behave in the same way, except that calls made to SamrSetDSRMPassword using NCACN_IP_TCP are rejected with RPC_S_ACCESS_DENIED.

<11> Section 2.1: A service-specific service principal name is not registered for this protocol. Windows-based clients use the host-based service principal name to identify the server for mutual authentication for the SMB and TCP RPC transports.

<12> Section 2.1: Servers running Windows 2000, Windows XP, and Windows Server 2003 accept calls at any authentication level. Without [MSKB-3149090] installed, servers running Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10 v1507 operating system, or Windows 10 v1511 operating system also accept calls at any authentication level.

<13> Section 2.1: Windows clients use transport security to encrypt the message for SamrValidatePassword.

<14> Section 2.2.6.1: Windows interactive-logon applications expect this value to be a UNC path (for example, \\machine-name\share-name\directory-name), or a fully qualified local path, including the drive letter (for example, "c:\directory\folder").

<15> Section 2.2.6.1: Windows interactive-logon applications expect this value to be either a zero-length string or a string with two characters: an alphabetic character, 'a' through 'z', in lower- or uppercase, followed by a colon (':').

<16> Section 2.2.6.1: This value is not accurate in multiple-DC configurations, as this value is not replicated among DCs. Therefore, this field is not to be used by clients. Windows clients do not use this field.

<17> Section 2.2.6.1: This value is not accurate in multiple-DC configurations, because this value is not replicated among DCs. Windows clients do not use this field.

<18> Section 2.2.6.1: This value is not accurate in multiple-DC configurations, because this value is not replicated among DCs. Therefore, this field is not to be used by clients. Windows clients do not use this field.

<19> Section 2.2.7.15: The following Windows servers return this flag with March 14^th, 2023, updates installed: Windows Server 2022 with [MSKB-5023705] and later, Windows Server 2019 with [MSKB-5023702], Windows Server 2016 with [MSKB-5023697],and Windows Server 2012 R2 with [MSKB-5023765]. For more information, see [MSKB-5020276].

<20> Section 2.2.7.15: The following Windows servers return this flag and perform these validations with the September 12^th, 2023, updates installed: Windows Server 2022 with [MSKB-5030216] and later, Windows Server 2019 with [MSKB-5030214], Windows Server 2016 with [MSKB-5030213], and Windows Server 2012 R2 with [MSKB-5030269]. For more information, see [MSKB-5020276].

<21> Section 2.2.7.15: There is no supported configuration in which Windows implementations of the server of this protocol (for example, a DC) return nonzero values for the SupportedFeatures field. However, Windows protocol clients running Windows XP and later are implemented to behave as specified in the description for the SupportedFeatures field. For example, after calling SamrCreateUser2InDomain (section 3.1.5.4.4), Windows NT 4.0–style client applications assume that the RID returned by SamrCreateUser2InDomain can be concatenated with the domain SID in which the user was created to obtain the SID of the newly created user. This assumption limits the server's ability to create SIDs that differ in format from this assumption, and thus limits the number of accounts ever created to 2^32 (the maximum size of an unsigned integer, which is the datatype of a RID). For more information about the extensible structure of SIDs, see [MS-AZOD] section 1.1.1.2.

To allow servers (in future implementations) to generate SIDs such that the RID is not an unsigned integer (for example, a 64-bit value), the SupportedFeatures value of 1 specifies to the client that the SamrRidToSid method is to be called to obtain the SID of a RID value returned from this protocol. In this scenario, the RID returned from the protocol is modeled as a "handle" to the account that SamrRidToSid uses to return the SID value.

The two reserved values (0x00000002 and 0x00000004) have no effect on the protocol; however, when these values are set, the Windows NET API ([MSDN-NMF]) on the client behaves as shown in the following table. These values are mutually exclusive with each other, though they can be combined using a logical OR with other bits.

<22> Section 2.2.10.1: Windows sets this buffer to the repeating pattern 0x20 0x00 on update.

<23> Section 2.2.10.1: Windows implementations of the protocol server set the Reserved5 field to arbitrary values.

<24> Section 2.2.10.2: Windows sets this value to 1 or 2, but does not use the value.

<25> Section 2.2.10.3: Windows sets this value to 0x31 and ignores it on read.

<26> Section 2.2.10.8: When the current domain functional level is DS_BEHAVIOR_WIN2003 or less, a Windows Server 2008 and later DC includes a KeyType of -140 in each of KERB_STORED_CREDENTIAL and KERB_STORED_CREDENTIAL_NEW, which is not needed and can be ignored; it is a dummy type in the supplemental credentials that is not present when the domain functional level is raised to DS_BEHAVIOR_WIN2008 or greater. The key data is the NT hash of the password.

<27> Section 3.1.1.5: Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2 do not support the msDS-ResultantPSO attribute.

<28> Section 3.1.1.6:  The sAMAccountName for computer accounts with the USER_WORKSTATION_TRUST_ACCOUNT flag that MUST end in a single dollar sign ($) and the objectClass of a new account that MUST match the sAMAccount type is supported by the operating systems specified in [MSFT-CVE-2021-42278], each with its related MSKB article download installed.

<29> Section 3.1.1.6: This modification is always allowed in Windows 2000 and in the following products that do NOT have [MSKB-3072595] installed: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<30> Section 3.1.1.6:  objectClass that MUST be of type computer or derived from the same if the userAccountControl attribute contains the UF_WORKSTATION_TRUST_ACCOUNT bit, is supported by the operating systems specified in [MSFT-CVE-2021-42278], each with its related MSKB article download installed.

<31> Section 3.1.1.8.3: On a DC configuration, Windows initiates urgent replication (described in [MS-ADTS] section 3.1.1.1.14, under event-driven replication) when this attribute value changes.

<32> Section 3.1.1.8.8: On a DC configuration, Windows initiates urgent replication (described in [MS-ADTS] section 3.1.1.1.14, under event-driven replication) when this attribute value is set to 0 or when this attribute value changes due to a password change request (as opposed to set) and userAccountControl contains the UF_NORMAL_ACCOUNT flag.

<33> Section 3.1.1.8.10: On a DC configuration, if the UF_SERVER_TRUST_ACCOUNT bit or the UF_WORKSTATION_TRUST_ACCOUNT bit changes on commit, an urgent replication is initiated. (Information about urgent replication is specified in [MS-ADTS] section 3.1.1.1.14.)

<34> Section 3.1.1.8.11.4: Windows uses the account's userPrincipalName as the DefaultSalt value. However, it does not use this value in any calculation.

<35> Section 3.1.1.8.11.4: Windows implementations of the protocol server include irrelevant bytes in the KERB_STORED_CREDENTIAL structure for a single KERB_KEY_DATA structure (20 bytes). The bytes appear directly prior to the start of DefaultSalt. They are not referenced by any offset value or necessary for interoperability. All bits in these bytes are 0.

<36> Section 3.1.1.8.11.6: Windows implementations of the protocol server include irrelevant bytes in the KERB_STORED_CREDENTIAL_NEW structure for a single KERB_KEY_DATA_NEW structure (24 bytes). The bytes appear directly prior to the start of DefaultSalt. They are not referenced by any offset value or necessary for interoperability. All bits in these bytes are 0.

<37> Section 3.1.1.8.11.7: Windows Server 2012 R2 and earlier do not set the NTLM-Strong-NTOWF property.

<38> Section 3.1.1.9.2.1: If the constraints in step 1 cannot be satisfied, the server returns an error code to the client and initiates an asynchronous call to IDL_DRSGetNCChanges to obtain a new rIDAllocationPool, if such an asynchronous call is not already active.

<39> Section 3.1.2: In Windows 2000 operating system Service Pack 4 (SP4), Windows Server 2003 operating system with Service Pack 1 (SP1), Windows Server 2003 R2, and Windows XP operating system Service Pack 2 (SP2), the Windows implementation of RPC does not satisfy this requirement. Consequently, a security check is enforced by the server of this protocol to ensure this constraint. Specifically, the server ensures that the SID of the client matches the SID of the client that opened the handle. If this condition is not met, a processing error is returned to the client.

<40> Section 3.1.2.1: Windows enforces this check on Windows 10 version 1607 and later, Windows Server 2016 and later, Windows 10 version 1511 with [MSKB-4013198] installed, Windows 10 version 1507 with [MSKB-4012606] installed, Windows 8.1 with [MSKB-4102219] installed, Windows 7 with [MSKB-4012218] installed, Windows Server 2012 R2 with [MSKB-4102219] installed, Windows Server 2012 with [MSKB-4012220] installed, and Windows Server 2008 R2 with [MSKB-4012218] installed. For more information, see [MSDOCS-RESTRICTRMTSAM].

<41> Section 3.1.4.2: The following tables list the Windows versions in which various accounts were introduced. All accounts continue to exist in subsequent versions of Windows according to the applicability lists at the beginning of this section.

Non-DC configuration, user accounts.

Non-DC configuration, alias accounts.

DC configuration, user accounts.

DC configuration, universal group accounts (only on root domain).

DC configuration, group accounts.

DC configuration, alias accounts.

<42> Section 3.1.4.2: In Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2, the initial membership of this group depends on the version of Windows running on the first DC of the domain and on the administrator's choice between "Pre-Windows 2000–compatible permissions mode" and "Windows 2000–only permissions mode".

Membership of the "Pre-Windows 2000 Compatible Access" group in Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2 is shown in the following table.

Membership of the "Pre-Windows 2000 Compatible Access" group in Windows Server 2008 and later is "Authenticated Users" (S-1-5-11).

<43> Section 3.1.5: Opnums reserved for local use apply to Windows as follows.

<44> Section 3.1.5.1.1: ServerName is ignored on receipt.

<45> Section 3.1.5.1.2: ServerName is ignored on receipt.

<46> Section 3.1.5.1.3: ServerName is ignored on receipt.

<47> Section 3.1.5.1.4: ServerName is ignored on receipt.

<48> Section 3.1.5.2.1: Windows does NOT validate the input, though the result of malformed information merely results in inconsistent output to the client.

<49> Section 3.1.5.2.1: Windows estimates the number of entries to return by dividing PreferedMaximumLength by the number of bytes of a maximum-sized entry.

<50> Section 3.1.5.2.2: Windows does not validate the input, though the result of malformed information merely results in inconsistent output to the client.

<51> Section 3.1.5.2.2: Windows estimates the number of entries to return by dividing PreferedMaximumLength by the number of bytes of a maximum-sized entry.

<52> Section 3.1.5.3: Non-DC configurations do not cache implementation-specific enumeration state on the domain handle; DC configurations do.

<53> Section 3.1.5.3.1: This value is estimated and is not accurate. Windows clients do not rely on the accuracy of this value.

<54> Section 3.1.5.3.1: On a non-DC configuration, Index is a per-element monotonically increasing number. If Index (the message parameter) is 0, the start value is 0; otherwise, the start value is one greater than Index (the message parameter).

On a DC, this value is an implementation-specific value that satisfies the requirement shown earlier.

<55> Section 3.1.5.4.4: The test for an explicit DENY ACE is NOT performed in Windows 2000. This test is also NOT performed in the following products that do not have [MSKB-3072595] installed: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<56> Section 3.1.5.4.4: This behavior is NOT performed in Windows 2000, and is also NOT performed in the following products that do not have [MSKB-3072595] installed: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. In these cases, the server behaves as if CallerPrimaryGroup is NOT equal to DOMAIN_GROUP_RID_COMPUTERS.

<57> Section 3.1.5.5.1.1: On non-DC configurations, the exact value is returned. On DC configurations, Windows estimates this count with no guarantees as to accuracy.

<58> Section 3.1.5.5.1.1: On non-DC configurations, the exact value is returned. On DC configurations, Windows estimates this count with no guarantees as to accuracy.

<59> Section 3.1.5.5.1.1: On non-DC configurations, the exact value is returned. On DC configurations, Windows estimates this count with no guarantees as to accuracy.

<60> Section 3.1.5.7.1: Applicable Windows Server releases return error STATUS_DS_BUSY (0xc00002a5).

<61> Section 3.1.5.7.2: Applicable Windows Server releases return error STATUS_DS_BUSY (0xc00002a5).

<62> Section 3.1.5.7.3: Applicable Windows Server releases return error STATUS_DS_BUSY (0xc00002a5).

<63> Section 3.1.5.7.3:  Applies only to versions updated with [MSKB-5034203], [MSKB-5034204], [MSKB-5034763], [MSKB-5034765], [MSKB-5034766], [MSKB-5034767], [MSKB-5034768], [MSKB-5034770], [MSKB-5034774], [MSKB-5034795], [MSKB-5034809], [MSKB-5034819], [MSKB-5034830], [MSKB-5034831], or [MSKB-5034833], and to later versions.

<64> Section 3.1.5.8.3: Servers running Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, and Windows Server 2008 do not check whether the domain prefixes of objectSid attributes from objects in M and G match.

<65> Section 3.1.5.10.2: Windows implementations of the protocol server ignore the ServerName parameter.

<66> Section 3.1.5.10.3: Windows implementations of the protocol server ignore the ServerName parameter.

<67> Section 3.1.5.10.4:  This parameter MAY be ignored by the server.

<68> Section 3.1.5.12.1.1: If USER_CHANGE_PASSWORD is not granted to World on receipt, Windows adds the following (deny) ACEs to the ntSecurityDescriptor value.

If USER_CHANGE_PASSWORD is granted to Self or World on receipt, Windows removes the above two ACEs (if present) and adds the following two ACEs, if not already present.

<69> Section 3.1.5.13.4: Windows clients set this value to be the null-terminated NETBIOS name of the server.

<70> Section 3.1.5.13.6: Windows 2000 Server and later enforce that the UserId parameter is 0x1F4.

<71> Section 3.1.5.13.6: Windows does not decrypt the value but stores the encrypted value directly in an implementation-specific store.

<72> Section 3.1.5.13.7.1: Windows Server 2003, Windows Server 2003 R2, and Windows Server 2008 test the PasswordLastSet conditions (constraints 5 and 6) immediately after testing the LockoutTime conditions (constraints 1 and 2).

<73> Section 3.1.5.13.7.2: In Windows 2000 Server and later, if there is a custom password filter installed, and that password filter fails to validate the password, Windows implementations of the protocol server set ValidationStatus to SamValidatePasswordFilterError.

<74> Section 3.1.5.13.7.3: In Windows 2000 Server and later, if there is a custom password filter installed, and that password filter fails to validate the password, Windows implementations of the protocol server set ValidationStatus to SamValidatePasswordFilterError.

<75> Section 3.1.5.13.8:  ComputerAccountReuseAllowList and supporting method SamrValidateComputerAccountReuseAttempt are supported in Windows Server 2012 R2 and later as specified in [MSKB-5020276], each with its related KB article download installed.

<76> Section 3.1.5.13.8:  The following Windows servers return this flag and perform these validations with the September 12^th, 2023, updates installed: Windows Server 2022 with [MSKB-5030216] and later, Windows Server 2019 with [MSKB-5030214], Windows Server 2016 with [MSKB-5030213], and Windows Server 2012 R2 with [MSKB-5030269]. For more information, see [MSKB-5020276].

<77> Section 3.1.5.13.8: The following Windows servers return this flag and perform these validations with the September 12^th, 2023, updates installed: Windows Server 2022 with [MSKB-5030216] and later, Windows Server 2019 with [MSKB-5030214], Windows Server 2016 with [MSKB-5030213], and Windows Server 2012 R2 with [MSKB-5030269]. For more information, see [MSKB-5020276].

<78> Section 3.1.5.13.9:  SamrAccountIsDelegatedManagedServiceAccount is available in Windows 11, version 24H2 operating system and later, and in Windows Server 2025 and later.

<79> Section 3.1.5.14.1: Windows uses the sAMAccountName attribute unless the sAMAccountName attribute contains characters that are not allowed for an RDN (RDN syntax is specified in [MS-ADTS] section 3.1.1.1.4), in which case the objectSid is used (in string form). If the sAMAccountName is not a unique RDN for the given container, the server returns STATUS_USER_EXISTS to the client.

<80> Section 3.1.5.14.7: Windows clients do not set this field.

<81> Section 3.2.2.4: The AES cipher AEAD-AES-256-CBC-HMAC-SHA512 and supporting methods, structures, and processing details that enable AES wire encryption protections of sensitive data with this protocol are supported on the operating systems specified in [MSFT-CVE-2021-33757], each with its related KB article download installed.