5.1 Security Considerations for Implementers

Security considerations for both unauthenticated RPC and Secure RPC, as used in this protocol, are as specified in [MS-RPCE] sections 5.1 and 5.2.

When the Netlogon Remote Protocol secure channel was originally implemented, only certain security-sensitive RPC call arguments, such as passwords, were encrypted. This mechanism involved passing extra parameters, known as authenticators, as RPC call arguments; these are used for authenticating the RPC calls. Later, support was added to sign and encrypt the entire RPC message with the help of a new Netlogon Remote Protocol security package. However, the encryption and validation of individual security-sensitive parameters, and the use of authenticators that are passed as RPC-call arguments for authenticating the calls, were preserved in the existing RPC calls, even though these were redundant at that point.

On receiving the DsrDeregisterDnsHostRecords call, the server controls access to this method. Because DsrDeregisterDnsHostRecords deletes DNS records for any specific DC, the client needs administrative privileges (such as those Administrator, Local System, Account Operator, or System Operator accounts have) for the call to succeed.

One of the new RPC calls that was added later, NetrLogonSamLogonEx, does not use authenticators. Instead, it encrypts the entire RPC message when encryption is requested. NetrLogonSamLogonEx is currently the only RPC call that is made over a secure channel that does not use authenticators. The presence of authenticators is determined by the Netlogon Remote Protocol call that was made.

To prevent remote denial of service (DoS) attacks, it is recommended that the server delete the stored ServerChallenge, client name, and client challenge used for the NetrServerReqChallenge method after a couple of minutes.

To prevent information disclosure, it is important for the server to control access to the DsrGetForestTrustInformation method to authenticated users.

To prevent information disclosure, it is important for the client to be a registered user of the corporate forest for the local computer account RID and limited to only those clients (such as local system or members of the local administrators group) that need the RID for a trust account for the NetrLogonGetTrustRid call to succeed.

On receiving the NetrLogonComputeServerDigest call, the server controls access to this method. Because NetrLogonComputeServerDigest is an administrative method, the client needs to have administrative privileges (such as those the local administrator's group, local system, or local service have) for the call to succeed.

On receiving the NetrLogonComputeClientDigest call, the server controls access to this method. Because NetrLogonComputeClientDigest is an administrative method, the client needs to have administrative privileges (such as those the local administrator's group, local system, or local service have) for the call to succeed.

On receiving the NetrLogonSetServiceBits call, the server controls access to this method. Because NetrLogonSetServiceBits is an administrative method, the client needs to have administrative privileges (such as those the local administrators group, local system, or local service have) for the call to succeed.

On receiving the NetrLogonGetTimeServiceParentDomain call, the server controls access to this method to determine whether the caller can access the parent domain. To prevent information disclosure, the client needs administrative privileges (such as those the local administrator's group, local system, or local service have) for the call to succeed.

The server controls access to the NetrLogonControl2Ex method to determine whether the caller is allowed to manage the Netlogon service (the caller requires administrative privileges such as those the local administrators group, local system, or local service have).