In Operations Manager, the Gateway server role is primary used for monitoring servers outside the Root Management Servers trusted Domain boundary. Another popular use of the Gateway role is for performance improvements by placing gateways in sites with poor network connectivity. Sometimes it is necessary to “chain” multiple gateways together to get monitor across multiple untrusted boundaries.
For Example, say you have a scenario that looks like the following:
Here we have a management group installed in the “My Company” network. The Admin has the requirement to monitoring the machines in the “DMZ” network. There is no direct connection between the “My Company” network and the “DMZ” network without first going through the “ExtraNet” network.
To minimize the chance of configuring things wrong, install 1 gateway at a time starting with the one reporting directly to an existing MS or the RMS, and moving “out.” Verify newly installed gateways are properly communicating, downloading MPs, etc before attempting to install the next one in the chain.
The actual install steps are identical for any gateway, whether reporting to an MS/RMS or chained to another gateway.
1. On the RMS, run the GatewayApprovalTool
a. /ManagementServerName:<FQDN of existing server (RMS, MS, or gateway) which the new gateway will report to> b. /GatewayName:<FQDN of the new gateway>
a. /ManagementServerName:<FQDN of existing server (RMS, MS, or gateway) which the new gateway will report to>
b. /GatewayName:<FQDN of the new gateway>
2. Install the gateway bits on the new machine
3. If needed, configure certificates to establish trust between the new gateway and the server it reports toHere is the tricky part: Configuring certificates between two gateways is no different than configuring certificates between an agent and a gateway, or a gateway and a MS or RMS. The same certificate settings are required, the same tools are used to request, install, and import the certs. A healthservice can only load and use a single auth certificate, so in the chained scenario the same certificate will be used by the gateway to authenticate to its parent and to any children. The parent and child(ren) must both trust the Certificate Authority which issued the gateway’s cert.
Here the RMS loads a cert from CA1 and is configured to trust CA1 as its root certificate authority. GW1 loads a cert issued from CA1 and trusts CA1. GW2 loads a cert issued from CA1 and trusts CA1.
Here the RMS loads a cert from CA1 and is configured to trust CA1 as its root certificate authority. GW1 loads a cert issued from CA1 and trusts CA1 and CA2. GW2 loads a cert issued from CA2 and trusts CA1.
Here the RMS loads a cert from CA1 and is configured to trust CA1 as its root certificate authority. GW1 loads a cert issued from CA1 and CA2 and trusts CA1 and CA2. GW2 loads a cert issued from CA2 and trusts CA2. This is not possible because GW1 cannot load more than one certificate in it’s health service communication channel.
Q1. In the supported complex configuration, doesn’t GW2 also need to trust CA2?A1. No, since GW1 presents a cert from CA1, and this is the only cert GW2 needs to trust. GW2 never needs to verify the trust of a CA2 certificate (HealthService only check settings of the cert it loads, not that it comes from a trusted CA) so it doesn’t NEED to have that CA trust cert. A machine only needs to trust the incoming certificate from parent or child, it does not need to trust the one it has loaded.
Hope this helps! I will update FAQs as I get more questions.
Technical content was provided and tested by Lincoln Atkinson. Thanks Lincoln!!
Rob Kuehfus | System Center Operations Manager | Setup and Deployment Program Manager
This is supplied "as -is" with no support. In addition, my thoughts and opinions often change, and as a weblog is intended to provide a semi-permanent point in time snapshot you should not consider out of date posts to reflect my current thoughts and opinions.
So, it's basically business-as-usual then.
All GW's need a certificate and for it to be valid they have to trust the CA. The only thing that really differs from deploying a "regular" gateway compared to a chained gateway is that when approving the chained one, use the first one as ManagementServer.
Am I right? Assigning certificates works exactly the same as with non-chained gateways in the simple scenario. And if you still need to have the Root CA-certificate for CA1 on GW2, why bother with CA2 at all? Am I missing a bigger picture?
You are correct. That’s what i also was thinking. You don't need CA2. Just Make one root CA certificate and use this for all you GWs , the only thing you have to do next is to generate the correct client cert with the correct fqdn on based this root ca and import this one on the correct GW.
But nerveless the article is still useful.
How about if CA2 is in DMZ. I have configured as detailed in this blog, but still GW2 is showing not monitored.