RPC Interface Restriction
Applies To: Windows Server 2003 with SP1
What does RPC Interface Restriction do?
A number of changes have been made in the Remote Procedure Call (RPC) service for Windows Server 2003 with Service Pack 1 that help make RPC interfaces secure by default and reduce the attack surface of Windows Server 2003. The most significant change is the addition of the
RestrictRemoteClients registry key. This key enables you to modify the behavior of all RPC interfaces on the system and can be used to eliminate remote anonymous access to RPC interfaces on the system, with some exceptions. Additional changes include the
EnableAuthEpResolution registry key and three new interface registration flags.
Who does this feature apply to?
This feature applies to RPC application developers. System administrators should also be familiar with this change to RPC.
What new functionality is added to this feature in Windows Server 2003 Service Pack 1?
RestrictRemoteClients Registry Key
When an interface is registered using RpcServerRegisterIf, RPC allows the server application to restrict access to the interface, typically through a security callback. The
RestrictRemoteClients registry key forces RPC to perform additional security checks for all interfaces, even if the interface has no registered security callback.
RPC clients that use the named pipe protocol sequence (ncacn_np) are exempt from all restrictions discussed in this section. The named pipe protocol sequence cannot be restricted due to several significant backwards compatibility issues.
RestrictRemoteClients registry key can have one of three DWORD values that can also be controlled programmatically in rpcdce.h. If the key is not present, it is equivalent to setting the DWORD=0 value (RPC_RESTRICT_REMOTE_CLIENT_NONE) for server SKUs and DWORD=1 value (RPC_RESTRICT_REMOTE_CLIENT_AUTH) for client SKUs.
The following table provides a reference to the
RestrictRemoteClients registry key:
Configurable through User Interface
Yes. This key can be configured using the Group Policy Object Editor.
0 (Default for server SKUs)
This value is the default value in Windows Server 2003 Service Pack 1 for Server SKUs. It causes the system to bypass the RPC interface restriction. This corresponds to the value RPC_RESTRICT_REMOTE_CLIENT_NONE in rpcdce.h. It is entirely the responsibility of the server application to impose appropriate RPC restrictions. This setting is equivalent to the behavior in previous versions of Windows.
This value is the default value in Windows XP Service Pack 2 and client SKUs built from the SRSP1 code base. It restricts access to all RPC interfaces. All remote anonymous calls are rejected by the RPC runtime except calls coming in through named pipes (ncacn_np). This corresponds to the value RPC_RESTRICT_REMOTE_CLIENT_DEFAULT in rpcdce.h. If an interface registers a security callback and provides the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag, then this restriction does not apply to that interface.
All remote anonymous calls are rejected by the RPC runtime with no exemptions. This corresponds to the value RPC_RESTRICT_REMOTE_CLIENT_HIGH in rpcdce.h. When this value is set, a system cannot receive remote anonymous calls using RPC.
Why is this change important? What threats does it help mitigate?
It is much more difficult to attack an interface if you require calls to perform authentication, even a relatively low level of authentication. Enabling
RestrictRemoteClients can be a particularly useful mitigation against worms that rely on exploitable buffer overruns that can be invoked remotely through anonymous connections.
What works differently?
If your RPC application expects to receive calls from remote anonymous RPC clients, using this feature might not allow your application to run correctly. As a result, applications that use DCOM might not work correctly if this value is set.
Because secure RPC calls over connectionless protocols such as User Datagram Protocol (UDP) and Internetwork Packet Exchange (IPX) (
ncadg_ipx) use a lower level of security than calls over connection-oriented protocols, these calls are always considered nonsecure for the purposes of this policy. As a result, RPC calls over connectionless protocols will fail if this key is enabled in Windows Server 2003 with Service Pack 1.
To allow RPC client calls using connectionless protocols, keep the
RestrictRemoteClients value set to 0 (RPC_RESTRICT_REMOTE_CLIENT_NONE), the default setting for Windows Server 2003 with Service Pack 1.
How do I resolve these issues?
There are the following options that may allow you to use
RestrictRemoteClients on your server:
Require your RPC clients to use RPC security when contacting your server application. This is the best method to mitigate security threats.
Exempt your interface from requiring authentication by setting the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag during interface registration. This configures RPC to allow anonymous connections to only your application’s interface.
EnableAuthEpResolution Registry Key
An RPC interface that is remotely and anonymously accessible and is registered by default on Windows Server 2003 presents a significant attack surface. RPC itself must register such an interface to provide endpoint resolution for calls using dynamic endpoints.
If you enable the
RestrictRemoteClients flag, the RPC Endpoint Mapper interface will not be accessible anonymously. This is a significant security improvement, but it changes the task of resolving an endpoint. Currently, an RPC client that attempts to make a call using a dynamic endpoint will first query the RPC Endpoint Mapper on the server to determine what endpoint it should connect to. This query is performed anonymously, even if the RPC client call itself is performed using RPC security. Anonymous calls to the RPC Endpoint Mapper interface will fail on Windows Server 2003 with Service Pack 1 if the
RestrictRemoteClients key is set to 1 or higher . This makes it necessary to modify the RPC client runtime to perform an authenticated query to the Endpoint Mapper. If the
EnableAuthEpResolution key is set, the RPC client runtime will use NTLM to authenticate to the endpoint mapper. This authenticated query will take place only if the actual RPC client call uses RPC authentication.
Why is this change important?
This change enables an RPC client to make a call to an RPC server that has registered a dynamic endpoint on a system running Windows Server 2003 with Service Pack 1 with
RestrictRemoteClients enabled. The client computer must set this registry key so that it will perform an authenticated query to the RPC Endpoint Mapper.
What works differently?
This registry key is used to enable the specific scenario described in the previous section. When this key is turned on, all RPC Endpoint Mapper queries that are performed on behalf of authenticated calls are performed using NTLM authentication.
This setting can also be specified using the Group Policy Object Editor to configure the Group Policy object located in Computer Configuration\Administrative Templates\System\Remote Procedure Call\RPC Endpoint Mapper Client Authentication.
New RPC Interface Registration Flags
Three new interface registration flags have been created to make it easier for an application developer to secure an RPC interface.
When this flag is registered, the RPC runtime invokes the registered security callback for all calls, regardless of the call security settings. Without this flag, RPC rejects all unauthenticated calls before they reach the security callback. This flag works only when a security callback is registered.
A security callback is registered for an interface in order to restrict access to that interface. The typical security callback impersonates the client to determine whether the client has sufficient rights to make a call to the interface. If a particular client identity passes a security callback once, it usually passes the same security callback every time.
The RPC runtime takes advantage of this pattern by remembering when an individual client identity passes a security callback and skips the security callback for subsequent calls by that client to the same interface. This feature is called security callback caching and has existed since the Microsoft Windows 2000 family of operating systems. For Windows Server 2003 with Service Pack 1, you can use the RPC_IF_SEC_NO_CACHE flag to disable security callback caching for a given interface. This is useful if the security check might change, possibly rejecting a client identity that was previously permitted.
When an interface is registered with this flag, RPC rejects calls made by remote RPC clients. In addition, local calls over all
ncadg_* protocol sequences and all
ncacn_* protocol sequences (except for named pipes, using
ncacn_np) are also rejected. If a call is made on
ncacn_np, RPC allows the call only if it does not come from SRV, which filters out all remote calls.
Ncalrpccalls are always allowed through.
Why is this change important?
This change provides RPC application developers with additional security tools to help secure their RPC interface.
What works differently?
These flags will not change any existing Windows Server 2003–based application or cause it not to run correctly. The use of these new flags is at the discretion of the application developer.
What settings are added or changed in Windows Server 2003 Service Pack 1?
|Setting name||Location||Default value||Possible values|
HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\ Microsoft\Windows NT\RPC
(Group Policy object)
Computer Configuration\ Administrative Templates\System\Remote Procedure Call\Restrictions for Unauthenticated RPC Clients
0 – None
1 – XP SP2 and SRSP1 client SKUs Default
2 – High
HKEY_LOCAL_MACHINE\ SOFTWARE\Policies \Microsoft\Windows NT\RPC
(Group Policy object)
Computer Configuration\ Administrative Templates\System\Remote Procedure Call\RPC Endpoint Mapper Client Authentication
0 – Disabled
1 – Enabled
Do I need to change my code to work with Windows Server 2003 Service Pack 1?
You may need to change your code to work with Windows Server 2003 Service Pack 1 if you decide to enable
RestrictRemoteClients. For more information about application changes that might be required, see the previous sections on