[MS-NRPC]: Netlogon Remote Protocol

Article
07/19/2023

This topic lists Errata found in [MS-NRPC] since it was last published. Since this topic is updated frequently, we recommend that you subscribe to this RSS feed to receive update notifications.

Errata are subject to the same terms as the Open Specifications documentation referenced.

RSS

To view a PDF file of the errata for the previous versions of this document, see the following ERRATA Archives:

October 16, 2015 - Download

June 30, 2015 - Download

July 18, 2016 - Download

September 23, 2019 - Download

August 24, 2020 – Download

April 7, 2021 - Download

June 24, 2021 - Download

April 29, 2022 - Download

Errata below are for Protocol Document Version V40.0 2022/04/29.

Errata Published*	Description
2023/07/18	Please see the diff document for details of the changes. Section 2.2.1.3.14 NETLOGON_CAPABILITIES: Added case (2) RequestedFlags. Changed from: The NETLOGON_CAPABILITIES union SHOULD<33> carry the supported Netlogon capabilities. typedef [switch_type(DWORD)] union _NETLOGON_CAPABILITIES { [case(1)] ULONG ServerCapabilities; } NETLOGON_CAPABILITIES, PNETLOGON_CAPABILITIES; ServerCapabilities: A 32-bit set of bit flags that identify the server's capabilities (section 3.5.4.4.10). <33> Section 2.2.1.3.14: The NETLOGON_CAPABILITIES union is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Changed to: The NETLOGON_CAPABILITIES union SHOULD<33> carry the supported Netlogon capabilities. typedef [switch_type(DWORD)] union _NETLOGON_CAPABILITIES { [case(1)] ULONG ServerCapabilities; [case(2)] ULONG RequestedFlags; } NETLOGON_CAPABILITIES, PNETLOGON_CAPABILITIES; ServerCapabilities: A 32-bit set of bit flags that identify the server's capabilities (section 3.5.4.4.10). RequestedFlags: A 32-bit set of bit flags that identify the client capabilities that server received during negotiation (section 3.5.4.4.10). <33> Section 2.2.1.3.14: The NETLOGON_CAPABILITIES union is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003. Section 3 Protocol Details: Added common error processing rule F expected response STATUS_INVALID_LEVEL for unsupported RPC tags seen for any Netlogon RPC requests. Section 3.1.1 Abstract Data Model: Added RequestedFlags to the abstract variables of the session key operations. Changed from: NegotiateFlags: A 32-bit set of bit flags that identify the negotiated capabilities between the client and the server. ServerStoredCredential: A NETLOGON_CREDENTIAL structure containing the credential that is created by the server and received by the client and that is used during computation and verification of the Netlogon authenticator. Changed to: NegotiateFlags: A 32-bit set of bit flags that identify the negotiated capabilities between the client and the server. RequestedFlags: A 32-bit set of bit flags that identify the client capabilities sent by client to server in negotiation request. ServerStoredCredential: A NETLOGON_CREDENTIAL structure containing the credential that is created by the server and received by the client and that is used during computation and verification of the Netlogon authenticator. Section 3.1.4.1 Session-Key Negotiation: Updated Client-Server processing to include Negotiaged flags and Requested flags. Changed from: 11. The client calls the NetrLogonGetCapabilities method (section 3.4.5.2.10). 12. The server SHOULD return the negotiated flags for the current exchange. 13. The client SHOULD compare the received ServerCapabilities (section 3.5.4.4.10) with the negotiated NegotiateFlags (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted. 14. The client sets the ServerSessionInfo.LastAuthenticationTry (indexed by server name) to the current time. This prevents authentication retries from occurring for 45 seconds unless a new transport notification is received. <71> Section 3.1.4.1: Returning the negotiated flags for the current exchange is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. <72> Section 3.1.4.1: Comparing the received ServerCapabilities with the negotiated NegotiateFlags is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Changed to: 11. The client calls the NetrLogonGetCapabilities method to get Negotiaged flags by setting QueryLevel to 1 (section 3.4.5.2.10). 12. The server SHOULD<73> return the negotiated flags for the current exchange. 13. The client SHOULD<74> compare the received ServerCapabilities (section 3.5.4.4.10) with the negotiated NegotiateFlags (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted. 14. The client calls the NetrLogonGetCapabilities method to get Requested flags by setting QueryLevel to 2 (section 3.4.5.2.10). 15. The server SHOULD<75> return the client capabilities received during a negotiation request from client. 16. The client SHOULD<76> compare the received Requested flags(section 3.5.4.4.10) with the flags it has actually sent during negotiation (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted. 17. The client sets the ServerSessionInfo.LastAuthenticationTry (indexed by server name) to the current time. This prevents authentication retries from occurring for 45 seconds unless a new transport notification is received. <72> Section 3.1.4.1: Returning the negotiated flags or received client flags for the current exchange is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003. <73> Section 3.1.4.1: Comparing the received ServerCapabilitiesCapabilities with the negotiated NegotiateFlags or RequestedFlags is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003. <74> Section 3.1.4.1: Returning the negotiated flags or received client flags for the current exchange is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003. <75> Section 3.1.4.1: Comparing the received Capabilities with the negotiated NegotiateFlags or RequestedFlags is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003. Section 3.4.1 Abstract Data Model: Updated Client-Server processing to include NegotiateFlags and RequestedFlags. Changed from: • ConnectionStatus: See section 3.1.1 for ClientStoredCredential details. • LastAuthenticationTry: A FILETIME ([MS-DTYP] section 2.3.3) indicating the time when the last authentication attempt was made. The time stamp is used to determine if at least 45 seconds have passed since the last authentication attempt. Changed to: • ConnectionStatus: See section 3.1.1 for ClientStoredCredential details. • LastAuthenticationTry: A FILETIME ([MS-DTYP] section 2.3.3) indicating the time when the last authentication attempt was made. The time stamp is used to determine if at least 45 seconds have passed since the last authentication attempt. • RequestedFlags: See section 3.1.1 for RequestedFlags details Section 3.4.5.2.10 Calling NetrLogonGetCapabilities: Updated processing for the comparison of received Capabilities with negotiated flags. Changed from: After the method returns, the client MUST verify the ReturnAuthenticator (section 3.1.4.5) and compare the received Capabilities with the negotiated flags of the current secure channel. If the negotiated flags do not match, then the client SHOULD<106> re-establish the secure channel with the DC. Upon receiving STATUS_NOT_IMPLEMENTED, the client MUST treat this as successful confirmation that the DC does not support AES [FIPS197].<107> <101> Section 3.4.5.2.10: NetrLogonGetCapabilities is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008 clients. <102> Section 3.4.5.2.10: Re-establishing the secure channel with the DC is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Changed to: After the method returns, the client MUST verify the ReturnAuthenticator (section 3.1.4.5) and compares the received Capabilities with the negotiated flags of the current secure channel. If the negotiated flags and the requested flags do not match, then the client SHOULD<106> re-establish the secure channel with the DC. On successful comparison of received Capabilities with negotiated flags, client also compares the capabilities sent in the negotiate request with the flags received by the server. If the negotiated flags and requested flags do not match, then the client SHOULD<107> re-establish the secure channel with the DC. Upon receiving STATUS_NOT_IMPLEMENTED, the client MUST treat this as successful confirmation that the DC does not support AES [FIPS197].<107> <105> Section 3.4.5.2.10: NetrLogonGetCapabilities is not supported by Windows NT, Windows 2000, Windows XP, and Windows Server 2003. <106> Section 3.4.5.2.10: Re-establishing the secure channel with the DC is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. <107> Section 3.4.5.2.10: Re-establishing the secure channel with the DC is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Section 3.5.4 Message Processing Events and Sequencing Rules: Added requested flags to NetrLogonGetCapabilities description. Changed from: NetrLogonGetCapabilities The NetrLogonGetCapabilities method returns server capabilities. Opnum: 21 Changed to: NetrLogonGetCapabilities The NetrLogonGetCapabilities method returns server capabilities or requested flags based on input QueryLevel parameter. Opnum: 21 Section 3.5.4.4.10 NetrLogonGetCapabilities (Opnum 21): Changed ServerCapabilities to Capabilities to include client capabilities received. Added to QueryLevel case 2 (Hex) to return client capabilities. Updated validation steps. Changed from: The NetrLogonGetCapabilities method is used by clients to confirm the server capabilities after a secure channel has been established.<190> . . . QueryLevel: Specifies the level of information to return from the domain controller being queried. A value of 0x00000001 causes return of a NETLOGON_CAPABILITIES structure that contains server capabilities. ServerCapabilities: A pointer to a 32-bit set of bit flags that identify the server's capabilities.<191> <190> Section 3.5.4.4.10: The NetrLogonGetCapabilities method is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. . . . <194> Section 3.5.4.4.10: The ServerCapabilities parameter is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008. These operating systems supported a dummy buffer type: . . . <195> Section 3.5.4.4.10: Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 do no processing for this call, and always return 0xC0000002 (STATUS_NOT_IMPLEMENTED). Changed to: The NetrLogonGetCapabilities method is used by clients to confirm the server capabilities after a secure channel has been established.<194> . . . QueryLevel: Specifies the level of information to return from the domain controller being queried. A value of 0x00000001 causes return of a NETLOGON_CAPABILITIES structure that contains server capabilities. A value of 0x00000002 causes the return of a NETLOGON_CAPABILITIES structure that contains client capabilities received by server when a negotiation request is made from the client. Capabilities: A pointer to a 32-bit set of bit flags that identify the server's capabilities or client’s capabilities received by server during negotiation.<195> <194> Section 3.5.4.4.10: The NetrLogonGetCapabilities method is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003. . . . <195> Section 3.5.4.4.10: The ServerCapabilities parameter is not supported by Windows NT, Windows 2000, Windows XP, and Windows Server 2003. These operating systems supported a dummy buffer type: [out, switch_is(QueryLevel)] PNETLOGON_DUMMY1 Buffer Buffer: A pointer to a byte buffer. <196> Section 3.5.4.4.10: Windows NT, Windows 2000, Windows XP, and Windows Server 2003 do no processing for this call, and always return 0xC0000002 (STATUS_NOT_IMPLEMENTED). Section 6 Appendix A: Full IDL: Added to NETLOGON_CAPABILITIES case (2) RequestedFlags and changed NetrLogonGetCapabilities (opnum 21) ServerCapabilities to Capabilities. Changed from: typedef [switch_type(DWORD)] union _NETLOGON_CAPABILITIES { [case(1)] ULONG ServerCapabilities; } NETLOGON_CAPABILITIES, PNETLOGON_CAPABILITIES; NTSTATUS NetrLogonGetCapabilities( [in, string] LOGONSRV_HANDLE ServerName, [in, string, unique] wchar_t ComputerName, [in] PNETLOGON_AUTHENTICATOR Authenticator, [in, out] PNETLOGON_AUTHENTICATOR ReturnAuthenticator, [in] DWORD QueryLevel, [out, switch_is(QueryLevel)] PNETLOGON_CAPABILITIES ServerCapabilities Changed to: typedef [switch_type(DWORD)] union _NETLOGON_CAPABILITIES { [case(1)] ULONG ServerCapabilities; [case(2)] ULONG RequestedFlags; } NETLOGON_CAPABILITIES, PNETLOGON_CAPABILITIES; NTSTATUS NetrLogonGetCapabilities( [in, string] LOGONSRV_HANDLE ServerName, [in, string, unique] wchar_t ComputerName, [in] PNETLOGON_AUTHENTICATOR Authenticator, [in, out] PNETLOGON_AUTHENTICATOR ReturnAuthenticator, [in] DWORD QueryLevel, [out, switch_is(QueryLevel)] PNETLOGON_CAPABILITIES Capabilities
2022/11/08	In section 3.1.1 Abstract Data Model: SealSecureChannel removed duplicate and adjusted to the encryption setting MUST be TRUE. Removed statement with note <69> about storing and retrieving the SealSecureChannel variable. Changed from: TrustPasswordVersion: ... SealSecureChannel: ... StrongKeySupport: ... The Netlogon client and server variables are as follows: LocatedDCsCache: ... SealSecureChannel: A Boolean setting that indicates whether the RPC message has to be encrypted or just integrity-protected ([C706] section 13.2.5). When TRUE, the message will be encrypted; otherwise, it will be integrity-protected. Implementations SHOULD<69> persistently store and retrieve the SealSecureChannel variable. VulnerableChannelAllowList: A setting expressed in Security Descriptor Definition Language (SDDL) ([MS-DTYP] section 2.5.1) of Netlogon client allowed to not use secure bindings, see section 3.1.4.6.<70> Changed to: TrustPasswordVersion: ... StrongKeySupport: ... The Netlogon client and server variables are as follows: LocatedDCsCache: ... SealSecureChannel: A Boolean setting that indicates whether the RPC message has to be encrypted or just integrity-protected ([C706] section 13.2.5). This setting MUST be TRUE. VulnerableChannelAllowList: A setting expressed in Security Descriptor Definition Language (SDDL) ([MS-DTYP] section 2.5.1) of Netlogon client allowed to not use secure bindings, see section 3.1.4.6.<69> In section 3.1.4.6 Calling Methods Requiring Session-Key Establishment: Step 1: Replaced if…TRUE... with: Clients MUST request the Privacy authentication level. Step 4: Added RPC Integrity to the MUST deny request list. Updated product note. Changed from: The client and server follow this sequence of steps.<75> 1. The client SHOULD<76> bind to the RPC server using TCP/IP. The client and server MUST utilize a secure bind. If a secure bind is used, the client instructs the RPC runtime to use the Netlogon SSP ([MS-RPCE] section 2.2.1.1.7) for privacy/integrity of the RPC messages. If the SealSecureChannel setting is TRUE, the client requests the Privacy authentication level from the RPC runtime. If the SealSecureChannel setting is FALSE, then the authentication level requested is Integrity. 2. … 3. … 4. If secure bind is not used, the server MUST deny the request unless client is in the VulnerableChannelAllowList setting.<77> <75> Section 3.1.4.6: Windows XP and later clients will request secure RPC. Windows Server 2008 R2 operating system and later will enforce that clients are using RPC Integrity and Confidentiality to secure the connection. For more information, see [MSFT-CVE-2020-1472]. Changed to: The client and server follow this sequence of steps.<74> 1. The client SHOULD<75> bind to the RPC server using TCP/IP. The client and server MUST utilize a secure bind. If a secure bind is used, the client instructs the RPC runtime to use the Netlogon SSP ([MS-RPCE] section 2.2.1.1.7) for privacy/integrity of the RPC messages. Clients MUST request the Privacy authentication level. 2. … 3. … 4. If secure bind is not used or the client is using RPC Integrity instead of RPC Privacy, the server MUST deny the request unless client is in the VulnerableChannelAllowList setting.<76> <74> Section 3.1.4.6: Windows XP and later clients will request secure RPC. Windows Server 2008 and later will enforce that clients are using RPC Confidentiality to secure the connection. For more information, see [MSFT-CVE-2020-1472] and [MSFT-CVE-2022-38023]. In section 3.4.1 Abstract Data Model: RequireSignOrSeal: Added that this setting MUST be TRUE. Changed from: RequireSignOrSeal: Indicates whether the client SHOULD<87> continue session-key negotiation when the server did not specify support for Secure RPC as described in the negotiable option Y of section 3.1.4.2. Changed to: RequireSignOrSeal: Indicates whether the client SHOULD<87> continue session-key negotiation when the server did not specify support for Secure RPC as described in the negotiable option Y of section 3.1.4.2. This setting MUST be TRUE. In section 3.4.3 Initialization: Changed RequireSignOrSeal from SHOULD to MUST be initialized to TRUE. Changed from: RequireSignOrSeal SHOULD<92> be initialized to TRUE. Changed to: RequireSignOrSeal MUST<92> be initialized to TRUE. In section 3.5.1 Abstract Data Model: SignSecureChannel: Added This setting is deprecated, as SealSecureChannel MUST be TRUE. Changed from: SignSecureChannel: A Boolean variable that determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates. Changed to: SignSecureChannel: A Boolean variable that determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates. This setting is deprecated, as SealSecureChannel MUST be TRUE. In Section 3.5.3 Initialization: RejectMD5Clients, SealSecureChannel, and SignSecureChannel set to TRUE. Changed from: RejectMD5Clients SHOULD be initialized in an implementation-specific way and set to FALSE. SealSecureChannel SHOULD be TRUE. SignSecureChannel SHOULD be initialized in an implementation-specific way and set to TRUE. Any changes made to the SignSecureChannel registry keys are reflected in the ADM elements when a PolicyChange event is received (section 3.1.6). Changed to: RejectMD5Clients SHOULD be initialized in an implementation-specific way and set to TRUE. SealSecureChannel MUST be TRUE. SignSecureChannel SHOULD be initialized in an implementation-specific way and set to TRUE. Any changes made to the SignSecureChannel registry keys are reflected in the ADM elements when a PolicyChange event is received (section 3.1.6). This setting is deprecated, as SealSecureChannel MUST be true.
2022/09/20	In section 1.3.1 Pass-Through Authentication: Added little endian usage statement. Changed from: … The secure channel is achieved by encrypting the communication traffic with a session key computed using a secret key (called a server's machine account password) shared by the server and the DC. Changed to: … The secure channel is achieved by encrypting the communication traffic with a session key computed using a secret key (called a server's machine account password) shared by the server and the DC. Unless otherwise specified, MS-NRPC uses little endian for byte ordering before encryption. In section 2.2.1.3.7 NL_TRUST_PASSWORD: Added product note about little endian usage for big endian users. Changed from: . . . The NL_TRUST_PASSWORD structure is encrypted using the negotiated encryption algorithm before it is sent over the wire. Changed to: . . . The NL_TRUST_PASSWORD structure is encrypted using the negotiated encryption algorithm before it is sent over the wire.<24> <24> Section 2.2.1.3.7: Windows domain controller expects little-endian byte ordering for the encryption input. If your processor is in big endian, then both the wide-character buffer and length fields in the NL_TRUST_PASSWORD structure MUST be converted to little endian before encryption. After encryption, byte swapping to reverse the order will be needed. In section 3.4.5.2.5 Calling NetrServerPasswordSet2: Added product note about little endian usage for big endian users. Changed from: Encrypt the ClearNewPassword parameter using the negotiated encryption algorithm (determined by bits C, O, or W, respectively, in the NegotiateFlags member of the ServerSessionInfo table entry for PrimaryName) and the session key established as the encryption key. Changed to: Encrypt <98> the ClearNewPassword parameter using the negotiated encryption algorithm (determined by bits C, O, or W, respectively, in the NegotiateFlags member of the ServerSessionInfo table entry for PrimaryName) and the session key established as the encryption key. <98> Section 3.4.5.2.5: Windows domain controller expects little-endian byte ordering for the encryption input. If your processor is in big endian, then both the wide-character buffer and length fields in the NL_TRUST_PASSWORD structure MUST be converted to little endian before encryption. After encryption, byte swapping to reverse the order will be needed. In section 3.5.4.4.5 NetrServerPasswordSet2 (Opnum 30): Added product note about little endian usage for big endian users. Changed from: ClearNewPassword: A pointer to an NL_TRUST_PASSWORD structure, as specified in section 2.2.1.3.7, that contains the new password encrypted as specified in Calling NetrServerPasswordSet2 (section 3.4.5.2.5). Changed to: ClearNewPassword: A pointer to an NL_TRUST_PASSWORD structure, as specified in section 2.2.1.3.7, that contains the new password encrypted<178> as specified in Calling NetrServerPasswordSet2 (section 3.4.5.2.5). <178> Section 3.5.4.4.5: Windows domain controller expects little-endian byte ordering for the encryption input. If your processor is in big endian, then both the wide-character buffer and length fields in the NL_TRUST_PASSWORD structure MUST be converted to little endian before encryption. After encryption, byte swapping to reverse the order will be needed.

Errata Published*

Description

2023/07/18

Please see the diff document for details of the changes.

Section 2.2.1.3.14 NETLOGON_CAPABILITIES: Added case (2) RequestedFlags.

Changed from:

The NETLOGON_CAPABILITIES union SHOULD<33> carry the supported Netlogon capabilities.

typedef

[switch_type(DWORD)]

union _NETLOGON_CAPABILITIES {

[case(1)]

ULONG ServerCapabilities;

} NETLOGON_CAPABILITIES,

*PNETLOGON_CAPABILITIES;

ServerCapabilities: A 32-bit set of bit flags that identify the server's capabilities (section 3.5.4.4.10).

<33> Section 2.2.1.3.14: The NETLOGON_CAPABILITIES union is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

Changed to:

The NETLOGON_CAPABILITIES union SHOULD<33> carry the supported Netlogon capabilities.

typedef

[switch_type(DWORD)]

union _NETLOGON_CAPABILITIES {

[case(1)]

ULONG ServerCapabilities;

[case(2)]

ULONG RequestedFlags;

} NETLOGON_CAPABILITIES,

*PNETLOGON_CAPABILITIES;

ServerCapabilities: A 32-bit set of bit flags that identify the server's capabilities (section 3.5.4.4.10).

RequestedFlags: A 32-bit set of bit flags that identify the client capabilities that server received during negotiation (section 3.5.4.4.10).

<33> Section 2.2.1.3.14: The NETLOGON_CAPABILITIES union is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003.

Section 3 Protocol Details: Added common error processing rule F expected response STATUS_INVALID_LEVEL for unsupported RPC tags seen for any Netlogon RPC requests.

Section 3.1.1 Abstract Data Model: Added RequestedFlags to the abstract variables of the session key operations.

Changed from:

NegotiateFlags: A 32-bit set of bit flags that identify the negotiated capabilities between the client and the server.

ServerStoredCredential: A NETLOGON_CREDENTIAL structure containing the credential that is created by the server and received by the client and that is used during computation and verification of the Netlogon authenticator.

Changed to:

NegotiateFlags: A 32-bit set of bit flags that identify the negotiated capabilities between the client and the server.

RequestedFlags: A 32-bit set of bit flags that identify the client capabilities sent by client to server in negotiation request.

Section 3.1.4.1 Session-Key Negotiation: Updated Client-Server processing to include Negotiaged flags and Requested flags.

Changed from:

11. The client calls the NetrLogonGetCapabilities method (section 3.4.5.2.10).

12. The server SHOULD return the negotiated flags for the current exchange.

13. The client SHOULD compare the received ServerCapabilities (section 3.5.4.4.10) with the negotiated NegotiateFlags (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted.

14. The client sets the ServerSessionInfo.LastAuthenticationTry (indexed by server name) to the current time. This prevents authentication retries from occurring for 45 seconds unless a new transport notification is received.

<71> Section 3.1.4.1: Returning the negotiated flags for the current exchange is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

<72> Section 3.1.4.1: Comparing the received ServerCapabilities with the negotiated NegotiateFlags is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

Changed to:

11. The client calls the NetrLogonGetCapabilities method to get Negotiaged flags by setting QueryLevel to 1 (section 3.4.5.2.10).

12. The server SHOULD<73> return the negotiated flags for the current exchange.

13. The client SHOULD<74> compare the received ServerCapabilities (section 3.5.4.4.10) with the negotiated NegotiateFlags (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted.

14. The client calls the NetrLogonGetCapabilities method to get Requested flags by setting QueryLevel to 2 (section 3.4.5.2.10).

15. The server SHOULD<75> return the client capabilities received during a negotiation request from client.

16. The client SHOULD<76> compare the received Requested flags(section 3.5.4.4.10) with the flags it has actually sent during negotiation (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted.

17. The client sets the ServerSessionInfo.LastAuthenticationTry (indexed by server name) to the current time. This prevents authentication retries from occurring for 45 seconds unless a new transport notification is received.

<72> Section 3.1.4.1: Returning the negotiated flags or received client flags for the current exchange is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003.

<73> Section 3.1.4.1: Comparing the received ServerCapabilitiesCapabilities with the negotiated NegotiateFlags or RequestedFlags is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003.

<74> Section 3.1.4.1: Returning the negotiated flags or received client flags for the current exchange is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003.

<75> Section 3.1.4.1: Comparing the received Capabilities with the negotiated NegotiateFlags or RequestedFlags is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003.

Section 3.4.1 Abstract Data Model: Updated Client-Server processing to include NegotiateFlags and RequestedFlags.

Changed from:

• ConnectionStatus: See section 3.1.1 for ClientStoredCredential details.

• LastAuthenticationTry: A FILETIME ([MS-DTYP] section 2.3.3) indicating the time when the last authentication attempt was made. The time stamp is used to determine if at least 45 seconds have passed since the last authentication attempt.

Changed to:

• ConnectionStatus: See section 3.1.1 for ClientStoredCredential details.

• RequestedFlags: See section 3.1.1 for RequestedFlags details

Section 3.4.5.2.10 Calling NetrLogonGetCapabilities: Updated processing for the comparison of received Capabilities with negotiated flags.

Changed from:

After the method returns, the client MUST verify the ReturnAuthenticator (section 3.1.4.5) and compare the received Capabilities with the negotiated flags of the current secure channel. If the negotiated flags do not match, then the client SHOULD<106> re-establish the secure channel with the DC.

Upon receiving STATUS_NOT_IMPLEMENTED, the client MUST treat this as successful confirmation that the DC does not support AES [FIPS197].<107>

<101> Section 3.4.5.2.10: NetrLogonGetCapabilities is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008 clients.

<102> Section 3.4.5.2.10: Re-establishing the secure channel with the DC is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

Changed to:

After the method returns, the client MUST verify the ReturnAuthenticator (section 3.1.4.5) and compares the received Capabilities with the negotiated flags of the current secure channel. If the negotiated flags and the requested flags do not match, then the client SHOULD<106> re-establish the secure channel with the DC.

On successful comparison of received Capabilities with negotiated flags, client also compares the capabilities sent in the negotiate request with the flags received by the server. If the negotiated flags and requested flags do not match, then the client SHOULD<107> re-establish the secure channel with the DC.

Upon receiving STATUS_NOT_IMPLEMENTED, the client MUST treat this as successful confirmation that the DC does not support AES [FIPS197].<107>

<105> Section 3.4.5.2.10: NetrLogonGetCapabilities is not supported by Windows NT, Windows 2000, Windows XP, and Windows Server 2003.

<106> Section 3.4.5.2.10: Re-establishing the secure channel with the DC is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

<107> Section 3.4.5.2.10: Re-establishing the secure channel with the DC is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

Section 3.5.4 Message Processing Events and Sequencing Rules: Added requested flags to NetrLogonGetCapabilities description.

Changed from:

NetrLogonGetCapabilities

The NetrLogonGetCapabilities method returns server capabilities.

Opnum: 21

Changed to:

NetrLogonGetCapabilities

The NetrLogonGetCapabilities method returns server capabilities or requested flags based on input QueryLevel parameter.

Opnum: 21

Section 3.5.4.4.10 NetrLogonGetCapabilities (Opnum 21): Changed ServerCapabilities to Capabilities to include client capabilities received.

Added to QueryLevel case 2 (Hex) to return client capabilities. Updated validation steps.

Changed from:

The NetrLogonGetCapabilities method is used by clients to confirm the server capabilities after a secure channel has been established.<190>

. . .

QueryLevel: Specifies the level of information to return from the domain controller being queried. A value of 0x00000001 causes return of a NETLOGON_CAPABILITIES structure that contains server capabilities.

ServerCapabilities: A pointer to a 32-bit set of bit flags that identify the server's capabilities.<191>

<190> Section 3.5.4.4.10: The NetrLogonGetCapabilities method is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

. . .

<194> Section 3.5.4.4.10: The ServerCapabilities parameter is not supported by Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008. These operating systems supported a dummy buffer type:

. . .

<195> Section 3.5.4.4.10: Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 do no processing for this call, and always return 0xC0000002 (STATUS_NOT_IMPLEMENTED).

Changed to:

The NetrLogonGetCapabilities method is used by clients to confirm the server capabilities after a secure channel has been established.<194>

. . .

A value of 0x00000002 causes the return of a NETLOGON_CAPABILITIES structure that contains client capabilities received by server when a negotiation request is made from the client.

Capabilities: A pointer to a 32-bit set of bit flags that identify the server's capabilities or client’s capabilities received by server during negotiation.<195>

<194> Section 3.5.4.4.10: The NetrLogonGetCapabilities method is not supported in Windows NT, Windows 2000, Windows XP, and Windows Server 2003.

. . .

<195> Section 3.5.4.4.10: The ServerCapabilities parameter is not supported by Windows NT, Windows 2000, Windows XP, and Windows Server 2003. These operating systems supported a dummy buffer type:

[out, switch_is(QueryLevel)] PNETLOGON_DUMMY1 Buffer

Buffer: A pointer to a byte buffer.

<196> Section 3.5.4.4.10: Windows NT, Windows 2000, Windows XP, and Windows Server 2003 do no processing for this call, and always return 0xC0000002 (STATUS_NOT_IMPLEMENTED).

Section 6 Appendix A: Full IDL: Added to NETLOGON_CAPABILITIES case (2) RequestedFlags and changed NetrLogonGetCapabilities (opnum 21) ServerCapabilities to Capabilities.

Changed from:

typedef

[switch_type(DWORD)]

union _NETLOGON_CAPABILITIES {

[case(1)]

ULONG ServerCapabilities;

} NETLOGON_CAPABILITIES,

*PNETLOGON_CAPABILITIES;

NTSTATUS

NetrLogonGetCapabilities(

[in, string] LOGONSRV_HANDLE ServerName,

[in, string, unique] wchar_t* ComputerName,

[in] PNETLOGON_AUTHENTICATOR Authenticator,

[in, out] PNETLOGON_AUTHENTICATOR ReturnAuthenticator,

[in] DWORD QueryLevel,

[out, switch_is(QueryLevel)] PNETLOGON_CAPABILITIES ServerCapabilities

Changed to:

typedef

[switch_type(DWORD)]

union _NETLOGON_CAPABILITIES {

[case(1)]

ULONG ServerCapabilities;

[case(2)]

ULONG RequestedFlags;

} NETLOGON_CAPABILITIES,

*PNETLOGON_CAPABILITIES;

NTSTATUS

NetrLogonGetCapabilities(

[in, string] LOGONSRV_HANDLE ServerName,

[in, string, unique] wchar_t* ComputerName,

[in] PNETLOGON_AUTHENTICATOR Authenticator,

[in, out] PNETLOGON_AUTHENTICATOR ReturnAuthenticator,

[in] DWORD QueryLevel,

[out, switch_is(QueryLevel)] PNETLOGON_CAPABILITIES Capabilities

2022/11/08

In section 3.1.1 Abstract Data Model: SealSecureChannel removed duplicate and adjusted to the encryption setting MUST be TRUE. Removed statement with note <69> about storing and retrieving the SealSecureChannel variable.

Changed from:

TrustPasswordVersion: ...

SealSecureChannel: ...

StrongKeySupport: ...

The Netlogon client and server variables are as follows:

LocatedDCsCache: ...

SealSecureChannel: A Boolean setting that indicates whether the RPC message has to be encrypted or just integrity-protected ([C706] section 13.2.5). When TRUE, the message will be encrypted; otherwise, it will be integrity-protected.

Implementations SHOULD<69> persistently store and retrieve the SealSecureChannel variable.

VulnerableChannelAllowList: A setting expressed in Security Descriptor Definition Language (SDDL) ([MS-DTYP] section 2.5.1) of Netlogon client allowed to not use secure bindings, see section 3.1.4.6.<70>

Changed to:

TrustPasswordVersion: ...

StrongKeySupport: ...

The Netlogon client and server variables are as follows:

LocatedDCsCache: ...

SealSecureChannel: A Boolean setting that indicates whether the RPC message has to be encrypted or just integrity-protected ([C706] section 13.2.5). This setting MUST be TRUE.

In section 3.1.4.6 Calling Methods Requiring Session-Key Establishment: Step 1: Replaced if…TRUE... with: Clients MUST request the Privacy authentication level. Step 4: Added RPC Integrity to the MUST deny request list. Updated product note.

Changed from:

The client and server follow this sequence of steps.<75>

1. The client SHOULD<76> bind to the RPC server using TCP/IP.

The client and server MUST utilize a secure bind. If a secure bind is used, the client instructs the RPC runtime to use the Netlogon SSP ([MS-RPCE] section 2.2.1.1.7) for privacy/integrity of the RPC messages. If the SealSecureChannel setting is TRUE, the client requests the Privacy authentication level from the RPC runtime. If the SealSecureChannel setting is FALSE, then the authentication level requested is Integrity.

2. …

3. …

4. If secure bind is not used, the server MUST deny the request unless client is in the VulnerableChannelAllowList setting.<77>

<75> Section 3.1.4.6: Windows XP and later clients will request secure RPC. Windows Server 2008 R2 operating system and later will enforce that clients are using RPC Integrity and Confidentiality to secure the connection. For more information, see [MSFT-CVE-2020-1472].

Changed to:

The client and server follow this sequence of steps.<74>

1. The client SHOULD<75> bind to the RPC server using TCP/IP.

2. …

3. …

4. If secure bind is not used or the client is using RPC Integrity instead of RPC Privacy, the server MUST deny the request unless client is in the VulnerableChannelAllowList setting.<76>

<74> Section 3.1.4.6: Windows XP and later clients will request secure RPC. Windows Server 2008 and later will enforce that clients are using RPC Confidentiality to secure the connection. For more information, see [MSFT-CVE-2020-1472] and [MSFT-CVE-2022-38023].

In section 3.4.1 Abstract Data Model: RequireSignOrSeal: Added that this setting MUST be TRUE.

Changed from:

RequireSignOrSeal: Indicates whether the client SHOULD<87> continue session-key negotiation when the server did not specify support for Secure RPC as described in the negotiable option Y of section 3.1.4.2.

Changed to:

In section 3.4.3 Initialization: Changed RequireSignOrSeal from SHOULD to MUST be initialized to TRUE.

Changed from:

RequireSignOrSeal SHOULD<92> be initialized to TRUE.

Changed to:

RequireSignOrSeal MUST<92> be initialized to TRUE.

In section 3.5.1 Abstract Data Model: SignSecureChannel: Added This setting is deprecated, as SealSecureChannel MUST be TRUE.

Changed from:

SignSecureChannel: A Boolean variable that determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates.

Changed to:

SignSecureChannel: A Boolean variable that determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates. This setting is deprecated, as SealSecureChannel MUST be TRUE.

In Section 3.5.3 Initialization: RejectMD5Clients, SealSecureChannel, and SignSecureChannel set to TRUE.

Changed from:

RejectMD5Clients SHOULD be initialized in an implementation-specific way and set to FALSE.

SealSecureChannel SHOULD be TRUE.

SignSecureChannel SHOULD be initialized in an implementation-specific way and set to TRUE. Any changes made to the SignSecureChannel registry keys are reflected in the ADM elements when a PolicyChange event is received (section 3.1.6).

Changed to:

RejectMD5Clients SHOULD be initialized in an implementation-specific way and set to TRUE.

SealSecureChannel MUST be TRUE.

2022/09/20

In section 1.3.1 Pass-Through Authentication: Added little endian usage statement.

Changed from:

… The secure channel is achieved by encrypting the communication traffic with a session key computed using a secret key (called a server's machine account password) shared by the server and the DC.

Changed to:

… The secure channel is achieved by encrypting the communication traffic with a session key computed using a secret key (called a server's machine account password) shared by the server and the DC. Unless otherwise specified, MS-NRPC uses little endian for byte ordering before encryption.

In section 2.2.1.3.7 NL_TRUST_PASSWORD: Added product note about little endian usage for big endian users.

Changed from:

. . . The NL_TRUST_PASSWORD structure is encrypted using the negotiated encryption algorithm before it is sent over the wire.

Changed to:

. . . The NL_TRUST_PASSWORD structure is encrypted using the negotiated encryption algorithm before it is sent over the wire.<24>

<24> Section 2.2.1.3.7: Windows domain controller expects little-endian byte ordering for the encryption input. If your processor is in big endian, then both the wide-character buffer and length fields in the NL_TRUST_PASSWORD structure MUST be converted to little endian before encryption. After encryption, byte swapping to reverse the order will be needed.

In section 3.4.5.2.5 Calling NetrServerPasswordSet2: Added product note about little endian usage for big endian users.

Changed from:

Encrypt the ClearNewPassword parameter using the negotiated encryption algorithm (determined by bits C, O, or W, respectively, in the NegotiateFlags member of the ServerSessionInfo table entry for PrimaryName) and the session key established as the encryption key.

Changed to:

Encrypt <98> the ClearNewPassword parameter using the negotiated encryption algorithm (determined by bits C, O, or W, respectively, in the NegotiateFlags member of the ServerSessionInfo table entry for PrimaryName) and the session key established as the encryption key.

<98> Section 3.4.5.2.5: Windows domain controller expects little-endian byte ordering for the encryption input. If your processor is in big endian, then both the wide-character buffer and length fields in the NL_TRUST_PASSWORD structure MUST be converted to little endian before encryption. After encryption, byte swapping to reverse the order will be needed.

In section 3.5.4.4.5 NetrServerPasswordSet2 (Opnum 30): Added product note about little endian usage for big endian users.

Changed from:

ClearNewPassword: A pointer to an NL_TRUST_PASSWORD structure, as specified in section 2.2.1.3.7, that contains the new password encrypted as specified in Calling NetrServerPasswordSet2 (section 3.4.5.2.5).

Changed to:

ClearNewPassword: A pointer to an NL_TRUST_PASSWORD structure, as specified in section 2.2.1.3.7, that contains the new password encrypted<178> as specified in Calling NetrServerPasswordSet2 (section 3.4.5.2.5).

<178> Section 3.5.4.4.5: Windows domain controller expects little-endian byte ordering for the encryption input. If your processor is in big endian, then both the wide-character buffer and length fields in the NL_TRUST_PASSWORD structure MUST be converted to little endian before encryption. After encryption, byte swapping to reverse the order will be needed.

[MS-NRPC]: Netlogon Remote Protocol

Additional resources