Freigeben über


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.

Windows Client releases

Client role

Server role

Windows NT 3.1 operating system

Yes

Yes

Windows NT 3.5 operating system

Yes

Yes

Windows NT 3.51 operating system

Yes

Yes

Windows NT 4.0 operating system

Yes

Yes

Windows 2000 Professional operating system

Yes

Yes

Windows XP operating system

Yes

Yes

Windows Vista operating system

Yes

Yes

Windows 7 operating system

Yes

Yes

Windows 8 operating system

Yes

Yes

Windows 8.1 operating system

Yes

Yes

Windows 10 operating system

Yes

Yes

Windows 11 operating system

Yes

Yes

Windows Server releases

Client role

Server role

Windows NT 3.1

Yes

Yes

Windows NT 3.5

Yes

Yes

Windows NT 3.51

Yes

Yes

Windows NT 4.0

Yes

Yes

Windows 2000 Server operating system

Yes

Yes

Windows Server 2003 operating system

Yes

Yes

Windows Server 2008 operating system

Yes

Yes

Windows Server 2008 R2 operating system

Yes

Yes

Windows Server 2012 operating system

Yes

Yes

Windows Server 2012 R2 operating system

Yes

Yes

Windows Server 2016 operating system

Yes

Yes

Windows Server operating system

Yes

Yes

Windows Server 2019 operating system

Yes

Yes

Windows Server 2022 operating system

Yes

Yes

Windows Server 2025 operating system

Yes

Yes

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.

Opnum

Friendly name

Product

0

SamrConnect

Windows NT 3.1

1

SamrCloseHandle

Windows NT 3.1

2

SamrSetSecurityObject

Windows NT 3.1

3

SamrQuerySecurityObject

Windows NT 3.1

4

Reserved (not intended for network traffic)

-

5

SamrLookupDomainInSamServer

Windows NT 3.1

6

SamrEnumerateDomainsInSamServer

Windows NT 3.1

7

SamrOpenDomain

Windows NT 3.1

8

SamrQueryInformationDomain

Windows NT 3.1

9

SamrSetInformationDomain

Windows NT 3.1

10

SamrCreateGroupInDomain

Windows NT 3.1

11

SamrEnumerateGroupsInDomain

Windows NT 3.1

12

SamrCreateUserInDomain

Windows NT 3.1

13

SamrEnumerateUsersInDomain

Windows NT 3.1

14

SamrCreateAliasInDomain

Windows NT 3.1

15

SamrEnumerateAliasesInDomain

Windows NT 3.1

16

SamrGetAliasMembership

Windows NT 3.1

17

SamrLookupNamesInDomain

Windows NT 3.1

18

SamrLookupIdsInDomain

Windows NT 3.1

19

SamrOpenGroup

Windows NT 3.1

20

SamrQueryInformationGroup

Windows NT 3.1

21

SamrSetInformationGroup

Windows NT 3.1

22

SamrAddMemberToGroup

Windows NT 3.1

23

SamrDeleteGroup

Windows NT 3.1

24

SamrRemoveMemberFromGroup

Windows NT 3.1

25

SamrGetMembersInGroup

Windows NT 3.1

26

SamrSetMemberAttributesOfGroup

Windows NT 3.1

27

SamrOpenAlias

Windows NT 3.1

28

SamrQueryInformationAlias

Windows NT 3.1

29

SamrSetInformationAlias

Windows NT 3.1

30

SamrDeleteAlias

Windows NT 3.1

31

SamrAddMemberToAlias

Windows NT 3.1

32

SamrRemoveMemberFromAlias

Windows NT 3.1

33

SamrGetMembersInAlias

Windows NT 3.1

34

SamrOpenUser

Windows NT 3.1

35

SamrDeleteUser

Windows NT 3.1

36

SamrQueryInformationUser

Windows NT 3.1

37

SamrSetInformationUser

Windows NT 3.1

38

SamrChangePasswordUser

Windows NT 3.1

39

SamrGetGroupsForUser

Windows NT 3.1

40

SamrQueryDisplayInformation

Windows NT 3.1

41

SamrGetDisplayEnumerationIndex

Windows NT 3.1

42

Reserved (not intended for network traffic)

 -

43

Reserved (not intended for network traffic)

 -

44

SamrGetUserDomainPasswordInformation

Windows NT 3.1

45

SamrRemoveMemberFromForeignDomain

Windows NT 3.1

46

SamrQueryInformationDomain2

Windows NT 3.5

47

SamrQueryInformationUser2

Windows NT 3.5

48

SamrQueryDisplayInformation2

Windows NT 3.5

49

SamrGetDisplayEnumerationIndex2

Windows NT 3.5

50

SamrCreateUser2InDomain

Windows NT 3.5

51

SamrQueryDisplayInformation3

Windows NT 3.5

52

SamrAddMultipleMembersToAlias

Windows NT 3.51

53

SamrRemoveMultipleMembersFromAlias

Windows NT 3.51

54

SamrOemChangePasswordUser2

Windows NT 3.51

55

SamrUnicodeChangePasswordUser2

Windows NT 3.51

56

SamrGetDomainPasswordInformation

Windows NT 3.51

57

SamrConnect2

Windows NT 3.51

58

SamrSetInformationUser2

Windows NT 3.51

59

Reserved (not intended for network traffic)

 -

60

Reserved (not intended for network traffic)

 -

61

Reserved (not intended for network traffic)

 -

62

SamrConnect4

Windows 2000 operating system

63

Reserved (not intended for network traffic)

-

64

SamrConnect5

Windows XP and Windows Server 2003

65

SamrRidToSid

Windows XP and Windows Server 2003

66

SamrSetDSRMPassword

Windows 2000 Server SP2 and Windows XP

67

SamrValidatePassword

Windows Server 2003 and Windows Vista

68

Reserved (not intended for network traffic)

 -

69

Reserved (not intended for network traffic)

 -

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

Deprecated method

Condition

SamrQueryInformationDomain

Windows clients call this method for information levels less than or equal to DomainStateInformation (see section 2.2.3.16 for Domain information levels).

SamrQueryDisplayInformation

Windows clients call this method for information levels less than or equal to DomainDisplayMachine (see section 2.2.8.12 for OEM information levels).

SamrQueryDisplayInformation2

Windows clients call this method for information levels less than or equal to DomainDisplayGroup (see section 2.2.8.12 for information levels).

SamrGetDisplayEnumerationIndex

Windows clients call this method for information levels less than or equal to DomainDisplayMachine (see section 2.2.8.12 for information levels).

SamrQueryInformationUser

Windows clients call this method under all conditions; even though SamrQueryInformationUser2 is available to be called, it is not called from any Windows clients.

SamrSetInformationUser

Windows clients call this method for information levels other than UserInternal4InformationNew and UserInternal5InformationNew (see section 2.2.6.28 for user information levels).

<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 14th, 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 12th, 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.

Value

Description

0x00000002

All fields that return a RID value return the value 0 instead of the RID value returned from the SAM Remote Protocol (Client-to-Server).

0x00000004

All method calls that accept information levels that return a RID fail with a Windows error code of ERROR_NOT_SUPPORTED (defined in [MS-ERREF] section 2.2).

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

Name

Revision introduced

Administrator

Windows NT 3.1

Guest

Windows NT 3.1

Non-DC configuration, alias accounts.

Name

Revision introduced

Administrators

Windows NT 3.1

Users

Windows NT 3.1

Guests

Windows NT 3.1

Power Users

Windows NT 3.1

Print Operators

Windows NT 3.1

Backup Operators

Windows NT 3.1

Replicator

Windows NT 3.1

Remote Desktop Users

Windows XP

Windows Server 2003

Network Configuration Operators

Windows XP

Windows Server 2003

Performance Monitor Users

Windows Server 2003

Windows Vista

Performance Log Users

Windows Server 2003

Windows Vista

Distributed COM Users

Windows Server 2003 with SP1

Windows Vista

IIS_IUSRS

Windows Vista

Windows Server 2008

Cryptographic Operators

Windows Vista

Windows Server 2008

Event Log Readers

Windows Vista

Windows Server 2008

DC configuration, user accounts.

Name

Revision introduced

Administrator

Windows NT 3.1

Guest

Windows NT 3.1

krbtgt

Windows 2000

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

Name

Revision introduced

Schema Admins

Windows 2000

Enterprise Admins

Windows 2000

Enterprise Read-only Domain Controllers

Windows Server 2008

DC configuration, group accounts.

Name

Revision introduced

Domain Admins

Windows NT 3.1

Domain Users

Windows NT 3.1

Domain Guests

Windows NT 3.1

Domain Computers

Windows NT 3.1

Domain Controllers

Windows NT 3.1

Group Policy Creator Owners

Windows 2000 Server

Windows XP

 Read-only Domain Controllers

Windows Server 2008

DC configuration, alias accounts.

Name

Revision introduced

Administrators

Windows NT 3.1

Users

Windows NT 3.1

Guests

Windows NT 3.1

Account Operators

Windows NT 3.1

System Operators

Windows NT 3.1

Print Operators

Windows NT 3.1

Backup Operators

Windows NT 3.1

Replicator

Windows NT 3.1

Cert Publishers

Windows 2000

RAS and IAS Servers

Windows 2000

Pre-Windows 2000 Compatible Access

Windows 2000

Remote Desktop Users

Windows Server 2003

Network Configuration Operators

Windows Server 2003

Incoming Forest Trust Builders

Windows Server 2003

Performance Monitor Users

Windows Server 2003

Performance Log Users

Windows Server 2003

Windows Authorization Access Group

Windows Server 2003

Terminal Server License Servers

Windows Server 2003

Distributed COM Users

Windows Server 2003 with SP1

IIS_IUSRS

Windows Vista

Windows Server 2008

Cryptographic Operators

Windows Vista

Windows Server 2008

Allowed RODC Password Replication Group

Windows Vista

Windows Server 2008

Denied RODC Password Replication Group

Windows Vista

Windows Server 2008

Event Log Readers

Windows Vista

Windows Server 2008

Certificate Service DCOM Access

Windows Vista SP1

Windows Server 2008

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

Operating system version

"Pre-Windows 2000-compatible permissions mode"

"Windows 2000-only permissions mode"

Windows 2000 Server

"Everyone" (S-1-1-0)

No members

Windows Server 2003

"Everyone" (S-1-1-0)

"Anonymous" (S-1-5-7)

"Authenticated Users" (S-1-5-11)

Windows Server 2003 R2

"Everyone" (S-1-1-0)

"Anonymous" (S-1-5-7)

"Authenticated Users" (S-1-5-11)

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.

Opnum

Description

4

Not used by Windows.

42

Just returns STATUS_NOT_IMPLEMENTED. It is never used.

43

Just returns STATUS_NOT_IMPLEMENTED. It is never used.

59

Used only locally by Windows, never remotely.

60

Used only locally by Windows, never remotely.

61

Not used by Windows.

63

Not used by Windows.

68

Used only locally by Windows, never remotely.

69

Used only locally by Windows, never remotely.

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

Field name

Value

Ace Type

ACCESS_DENIED_OBJECT_ACE_TYPE

SID

PRINCIPAL_SELF_SID

Access Mask

ACTRL_DS_CONTROL_ACCESS

ObjectGuid

ab721a53-1e2f-11d0-9819-00aa0040529b

            

Field name

Value

Ace Type

ACCESS_DENIED_OBJECT_ACE_TYPE

SID

World

Access Mask

ACTRL_DS_CONTROL_ACCESS

ObjectGuid

ab721a53-1e2f-11d0-9819-00aa0040529b

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.

Field name

Value

Ace Type

ACCESS_ALLOWED_OBJECT_ACE_TYPE

SID

Self

Access Mask

ACTRL_DS_CONTROL_ACCESS

ObjectGuid

ab721a53-1e2f-11d0-9819-00aa0040529b

            

Field name

Value

Ace Type

ACCESS_ALLOWED_OBJECT_ACE_TYPE

SID

World

Access Mask

ACTRL_DS_CONTROL_ACCESS

ObjectGuid

ab721a53-1e2f-11d0-9819-00aa0040529b

<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 12th, 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 12th, 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.