<1> Section 1.3.2: There is no supported configuration in which this method is called from Windows clients. See section 2.2.3.14 for details on the conditions under which this method is called from a client.

<2> Section 1.4: The data manipulated by the server of this protocol is used as a security principal database for authentication protocols such as NTLM [MS-NLMP] and Kerberos [MS-KILE].

<3> 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 exception to this rule is the SamrUnicodeChangePasswordUser2 method, which is the primary protocol that Windows clients use to change passwords and join computers to a domain (described in [MS-ADTS] section 7.4).

<4> 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 7.4).

<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, Windows Server 2003, and Windows Server 2008, with the exception of GroupReplicationInformation for SamrQueryInformationGroup. This information level is supported in Windows Server 2003 and Windows Server 2008.

<7> Section 1.7.4: Windows clients (that is, clients) do not currently use the information from the server that is contained in the Revision and SupportedFeatures fields of the SAMPR_REVISION_INFO_V1 structure. On the server, only the Revision field from the client is used. It is used to determine the types of error codes that the client understands, so that more descriptive error codes can be returned to more recent clients.

<8> Section 2.1: Windows NT, Windows 2000, and Windows Server 2003 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.

<9> Section 2.1: Windows 2000, Windows XP, and Windows Server 2003 process calls for all opnums over the RPC-over-named-pipes (NCACN_NP) protocol. Windows Vista and Windows Server 2008 behave in the same way, except that calls made to SamrValidatePassword using NCACN_NP are rejected with RPC_S_PROTSEQ_NOT_SUPPORTED.

<10> 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 and Windows Server 2008. The pipe access check happens before any other access check, and therefore overrides any other access.

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

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

<13> Section 2.1: The Windows-based client uses transport security to encrypt the message for SamrValidatePassword.

<14> Section 2.2.3.14: 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 and Windows Vista 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 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-SECO] section 2.3.

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

<15> 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 Windows file path without the drive letter (for example, \program files\billg), or a zero-length string.

<16> 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 (':').

<17> 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 must not be used by clients. 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. Windows clients do not use this field.

<19> 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 must not be used by clients. Windows clients do not use this field.

<20> Section 2.2.7.23: This structure is used only for the SamrUnicodeChangePasswordUser3 method. There are no Windows clients that call this method.

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

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

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

<24> Section 2.2.10.8: When the current domain functional level is DS_BEHAVIOR_WIN2003 or less, a Windows Server 2008 DC includes a key entry of type -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.

<25> Section 3.1.1.2: On a non-DC configuration, Windows transforms the characters to uppercase, per [UNICODE3.1], and then byte-compares the values.

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

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

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

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

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

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

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

<33> Section 3.1.2: In Windows 2000 SP4, Windows Server 2003 SP1, 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.

<34> Section 3.1.4.2: 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". In Windows 2000 Server, in the pre-Windows 2000–compatible permissions mode, "Everyone" (S-1-1-0) is a member, and in the Windows 2000–only permissions mode, the membership is empty. In Windows Server 2003, in the pre-Windows 2000–compatible permissions mode, "Everyone" (S-1-1-0) and "Anonymous" (S-1-5-7) are members, and in the Windows 2000–only permissions mode, "Authenticated Users" (S-1-5-11) are members.

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

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

<37> Section 3.1.5.1.1: Windows sets OutVersion to 1, OutRevisionInfo.Revision to 3, and the remaining fields to zero.

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

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

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

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

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

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

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

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

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

<47> Section 3.1.5.5.1.1: On non-DC configurations, the exact value is returned. On DC configurations, Windows estimates this count.

<48> Section 3.1.5.5.1.1: On non-DC configurations, the exact value is returned. On DC configurations, Windows estimates this count.

<49> Section 3.1.5.5.1.1: On non-DC configurations, the exact value is returned. On DC configurations, Windows estimates this count.

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

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

<52> Section 3.1.5.10.4: Clients connecting to servers that are running Windows 2000 Server or Windows NT Server must use SamrUnicodeChangePasswordUser2. Clients connecting to servers that are running Windows Server 2003 and later can also use SamrUnicodeChangePasswordUser3.

<53> Section 3.1.5.10.4: There are no Windows clients that call this method.

<54> Section 3.1.5.10.4: 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.

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.

<56> Section 3.1.5.13.2: Starting with Windows Vista and Windows Server 2008, SamrShutdownSamServer has been deprecated and always returns STATUS_NOT_SUPPORTED (0xC00000BB).

<57> Section 3.1.5.13.5: Windows clients set this value to be the NULL-terminated NETBIOS name of the server.

<58> Section 3.1.5.13.7: Windows 2000 Server, Windows Server 2003, and Windows Server 2008 enforce that the UserId parameter is 0x1F4.

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

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

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