Export (0) Print
Expand All

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 released service packs:

  • Windows NT 3.1 operating system

  • Windows NT 3.5 operating system

  • Windows NT 3.51 operating system

  • Windows NT 4.0 operating system

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Server 2003 R2 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 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 1.3.2: There is no supported configuration in which this method is called from Windows clients. See section 2.2.3.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 in order 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 subsequent versions of Windows according to the applicability list 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

63

Reserved (not intended for network traffic)

-

64

SamrConnect5

Windows XP

65

SamrRidToSid

Windows XP

66

SamrSetDSRMPassword

Windows 2000 SP2 and Windows XP

67

SamrValidatePassword

Windows Server 2003

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.4.16 for a description of the information levels).

SamrQueryDisplayInformation

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

SamrQueryDisplayInformation2

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

SamrGetDisplayEnumerationIndex

Windows clients call this method for information levels less than or equal to DomainDisplayMachine (see section 2.2.8.12 for a description of the 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.7.28 for a description of the information levels).

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

<7> Section 2.1: Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2003 R2 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 SP2, Windows 7, Windows Server 2008 with SP2, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 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 SP1, Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. 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, Windows Server 2008 with SP2, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 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: The Windows-based client uses transport security to encrypt the message for SamrValidatePassword.

<13> Section 2.2.3.15: There is no supported configuration in which Windows servers of this protocol (for example, a DC) return nonzero values for the SupportedFeatures field. However, Windows clients running Windows XP, Windows Vista, Windows 7, Windows 8, and Windows 8.1 are implemented to behave as specified earlier. 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 domainSID 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 may 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).

<14> Section 2.2.7.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.7.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.7.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.7.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.7.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.10.1: Windows sets this buffer to the repeating pattern 0x20 0x00 on update.

<20> Section 2.2.10.1: Windows servers set the Reserved5 field to arbitrary values.

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

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

<23> Section 2.2.10.8: When the current domain functional level is DS_BEHAVIOR_WIN2003 or less, a Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 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.

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

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

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

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

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

<29> Section 3.1.1.8.11.4: Windows servers 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.

<30> Section 3.1.1.8.11.6: Windows servers 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.

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

<32> Section 3.1.2: In Windows 2000 SP4, Windows Server 2003 with SP1, Windows Server 2003 R2, and Windows XP 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.

<33> 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 list 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

Network Configuration Operators

Windows XP

Performance Monitor Users

Windows Server 2003

Performance Log Users

Windows Server 2003

Distributed COM Users

Windows Server 2003 with SP1

IIS_IUSRS

Windows Vista

Cryptographic Operators

Windows Vista

Event Log Readers

Windows Vista

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

Cryptographic Operators

Windows Vista

Allowed RODC Password Replication Group

Windows Vista

Denied RODC Password Replication Group

Windows Vista

Event Log Readers

Windows Vista

Certificate Service DCOM Access

Windows Vista SP1 and Windows Server 2008

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

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, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

Operating system version

Membership of "Pre-Windows 2000 Compatible Access" group

Windows Server 2008

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

Windows Server 2008 R2

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

Windows Server 2012

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

Windows Server 2012 R2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<49> Section 3.1.5.7.1: Windows servers return error STATUS_DS_BUSY (0xc00002a5).

<50> Section 3.1.5.7.2: Windows servers return error STATUS_DS_BUSY (0xc00002a5).

<51> Section 3.1.5.7.3: Windows servers return error STATUS_DS_BUSY (0xc00002a5).

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

<53> Section 3.1.5.10.2: Windows servers ignore the ServerName parameter.

<54> Section 3.1.5.10.3: Windows servers ignore the ServerName parameter.

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

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

<57> Section 3.1.5.13.6: Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 enforce that the UserId parameter is 0x1F4.

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

<59> Section 3.1.5.13.7.2: Starting with Windows 2000 Server, if there is a custom password filter installed, and that password filter fails to validate the password, Windows server sets ValidationStatus to SamValidatePasswordFilterError.

<60> Section 3.1.5.13.7.3: Starting with Windows 2000 Server, if there is a custom password filter installed, and that password filter fails to validate the password, Windows server sets ValidationStatus to SamValidatePasswordFilterError.

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

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

 
Show:
© 2014 Microsoft