5.1 Security Considerations for Implementers

  • Article

For security considerations for both authenticated RPC and unauthenticated RPC calls used in this protocol, see section 2.1.3 and [MS-RPCE].

The client can fail over to unauthenticated RPC calls when authenticated RPC calls fail for backward compatibility. The unauthenticated RPC call is not as secure as an authenticated RPC call; the client audits or supports this automatic failover only when it is explicitly specified.<39> For every RPC call, the client executes the following sequence of steps:

  • Execute an authenticated RPC call.

    • If the call does not succeed and fallback is allowed:

      • Execute an unauthenticated RPC call.

        • If the call does not succeed, return a failure to the caller.

    • Otherwise, return a failure to the caller.

The server is the only role that can impersonate RPC calls. However, the impersonation level ([MS-RPCE] section 2.2.1.1.9) allowed by the client affects the server's ability to perform impersonation. If the incoming RPC is an authenticated RPC call, the server can use the authenticated identity of the client as the server principal name for performing mutual authentication, and then use the server's identity on the nested call.<40> Preferably, the client would use the RPC_C_IMPL_LEVEL_IDENTIFY impersonation level ([MS-RPCE] section 2.2.1.1.9) when making the RPC call. Use of the RPC_C_IMPL_LEVEL_IMPERSONATE or RPC_C_IMPL_LEVEL_DELEGATE levels can represent a security risk and are to be avoided unless necessary.