Configuring Firewall Access Between CCS and RMS
Article ID: 151912
Updated On:
Products
Issue/Introduction
Error during asset import:"The RPC server is unavailable. Context Information: WMI failure::Unable to perform windows 2008 asset import due to invalid OS Type"
The RPC server is unavailable. Context Information: WMI failure::Unable to perform windows 2008 asset import due to invalid OS Type
Cause
CCS talks to its Data Providers during Data-Import Jobs. A Data Provider is an RMS deployment, and CCS talks to it using RPC-on-IP (aka "ncacn_ip_tcp"). These RPC communications are usually blocked by firewalls; the following document explains how to unblock them and then minimize the resulting surface area.
Resolution
Background
When a program like RMS is offering services on an RPC interface, it registers itself with its host's RPC endpoint mapper. The RPC endpoint mapper picks a random port for the service. For IP services, this will be a port in the "ephemeral" range -- 1024 through 65535. Older versions of Windows further restricted the range to 1024 through 5000, but newer versions use higher port numbers. Windows Vista and Windows 2008 use ports 49152 through 65535.
Each time the application registers its RPC service, a different random ephemeral port is assigned. This means that in order for a firewall to allow access, the entire ephemeral port range must be opened.
The firewall must also open the RPC endpoint mapper's port, 135. The RPC endpoint mapper keeps track of which RPC services are available on which ports. When a client connects and does not know which ephemeral port its service is listening on (because the ports are assigned randomly), the client asks the RPC endpoint mapper, using port 135. The RPC endpoint mapper answers, and the client-server conversation then moves to the appropriate ephemeral port.
Shrink the RPC port range
One way to reduce this exposed surfaced area is to move and shrink the range of ephemeral ports that the RPC endpoint mapper assigns to RPC services. You can move the range to 5001-5040, for example. Then you’d configure your firewall to allow inbound connections on ports 135 (as before) and on ports 5001-5040. This Microsoft KB explains how to do all this, and how to lock down the ports afterward to allow only specific subnets to get in: http://support.microsoft.com/kb/908472. You don't need to reconfigure RMS or CCS when making this change; because they use the RPC endpoint mapper, they'll automatically be notified of the port numbers.
Pin RMS service to a single RPC port
Another way to reduce exposed surface area is to pin RMS's RPC service to a specific port -- say, port 8282. Having done so, you would then configure your firewall to allow ports 135 and 8282 and that's all. That's better than keeping the entire ephemeral port range open. RMS uses the following registry key, set in every machine where RMS is deployed, to pin its RPC service to a certain port:
STRING HKEY_LOCAL_MACHINE\Software\BindView\Infrastructure\RMS System\server\BVProcessManager\RpcEndPoint = "8282"
(That registry value will not already exist.) This key is supported by all RMS versions. CCS does not need to be reconfigured if this key is used, because CCS asks the RPC endpoint mapper which port the RMS RPC service is on. You must restart the BVProcessManager service on the RMS machine after setting or changing this key. After restart, wait sixty seconds, run "NETSTAT -A", and verify that the port is now open and 'LISTENING'.
(Before picking a port, do a quick survey on your network to verify that your port number is not already in use by other applications.)
Preconfigure CCS with the target RPC port
You can further reduce the surface area by eliminating the need for the RPC endpoint mapper (port 135). CCS only needs to talk to the RPC endpoint mapper if it doesn't know which port RMS's RPC service is listening on… so, if you configure all of your RMS deployments to use a specific port, you can tell CCS what that port is, and it will no longer need the RPC endpoint mapper. CCS uses the following registry key, on its Job Server, to do so:
STRING HKEY_LOCAL_MACHINE\SOFTWARE\BindView\BindView Policy Compliance Center\RPC\NetConnSvc\Client\Endpoint = "8282"
(That registry key path will not already exist.) If you do this, then CCS will no longer use or need the RPC endpoint mapper, and so port 135 can be blocked. Also note that it is a "one size fits all" setting, and so every Data Provider that CCS uses must be configured (as above) to use that port number. If you miss one, you'll get weird "service unavailable" RPC errors from any Data-Import Jobs directed at the Data Provider that you forgot to reconfigure.
Use firewall's deep packet inspection
If your firewall has deep-packet inspection for RPC traffic, then you can reduce the surface area even further. Provided your firewall is clever enough to support it, you can lock down the particular RPC interfaces that can be accessed to just RMS's:
{{0x8D4D0E96,0x7C8A,0x4400,{0x8A,0xC5,0x67,0x4D,0x0E,0x3E,0xC4,0x08}},{1,0}}
The servicing process is named BVProcessManager.exe, which your firewall may also allow you specify.
Note that RMS uses quite a few other ports in order to talk to its downstream components, particularly the bvControl-for-Windows and bvControl-for-Unix infrastructures. For that, many additional firewall settings are needed, but this is beyond the scope of this document. This document applies only to the communication between the CCS Job Server and its RMS Information Server deployments.
Feedback
