~ Irfan Rabbani | Senior Support Escalation Engineer
This article is the third in a series of posts on how to monitor System Center 2012 R2 Operations Manager clients that are not members of your Active Directory domain. The series is broken out into three parts:
Part 3: Installing and configuring a gateway
In part 1 we implemented a certificate authority, then in part 2 we went through acquiring and configuring the necessary certificates and how to approve the untrusted clients. Now in part 3 we’ll be looking at the installation and configuration of the gateway server. Note that use a gateway server is optional. Everything necessary to monitor an untrusted client is included in parts 1 and 2, however a gateway can be beneficial in larger environments. Here’s a little detail to explain why.
Why use a gateway
Operations Manager requires that mutual authentication be performed between agents and management servers prior to the exchange of information between them. To secure the authentication process between the two, the process is encrypted. When the agent and the management server reside in the same Active Directory domain or in Active Directory domains that have established trust relationships, they make use of Kerberos V5 authentication mechanisms provided by Active Directory. When the agents and management servers do not lie within the same trust boundary, other mechanisms must be used to satisfy the secure mutual authentication requirement.
In Operations Manager, this is accomplished through the use of certificates issued for each computer. If there are many agent-monitored computers, this results in high administrative overhead for managing all those certificates. In addition, if there is a firewall between the agents and management servers, multiple authorized endpoints must be defined and maintained in the firewall rules to allow communication between them.
To reduce this administrative overhead, Operations Manager has a server role called the gateway server. Gateway servers are located within the trust boundary of the agents and can participate in the mandatory mutual authentication. Because they lie within the same trust boundary as the agents, the Kerberos V5 protocol for Active Directory is used between the agents and the gateway server. Each agent then communicates only with the gateway servers that it is aware of. The gateway servers communicate with the management servers.
To support the mandatory secure mutual authentication between the gateway servers and the management servers, certificates must be issued and installed, but only for the gateway and management servers. This reduces the number of certificates required, and in the case of an intervening firewall it also reduces the number of authorized endpoints to be defined in the firewall rules. The following illustration shows the authentication relationships in a management group using a gateway server.
Step 1: Register the Operations Manager Gateway
NOTE As a best practice, never install the gateway role and configure it with its machine certificate before the gateway server role registration process. Why? Because you can end up having the Gateway Health service accidently approved as an agent if manual agent approval is configured to Always Approve in the Operations Manager console, as shown here:
1. Copy Microsoft.EnterpriseManagement.GatewayApprovalTool.exe (pick the AMD64 folder if you are going to run it on a 64-bit machine) and Microsoft.EnterpriseManagement.GatewayApprovalTool.exe.CONFIG from the Support Tools directory on your installation media to the installation folder of your OpsMgr installation. In my case that’s C:\Program Files\System Center 2012\Operations Manager\Setup.
2. Approve the gateway server by opening a Command Prompt and running the following command:
Microsoft.EnterpriseManagement.gatewayApprovalTool.exe /ManagementServerName=<managementserverFQDN> /GatewayName=<GatewayFQDN> /Action=Create
In the example below, the name of gateway server OM12GW and the name of the management server to which the gateway reports is named Om12MS.DRH.INT.
If the approval is successful, you will see the approval of server <GatewayFQDN> completed successfully.
The Microsoft.EnterpriseManagement.GatewayApprovalTool.exe command should only take about 15 seconds to run even on the slowest of servers, so if this takes significantly longer then you probably have an authentication issue somewhere. If you find yourself in this situation, here are some things to check:
1. Make sure that the user running Microsoft.EnterpriseManagement.GatewayApprovalTool.exe is doing it from one of the management servers, preferable the RMS in the case of Operations Manager 2007 R2, and from any management server in OpsMgr 2012 or OpsMgr 2012 R2.
2. Microsoft.EnterpriseManagement.GatewayApprovalTool.exe must be executed by a user account that has rights to the Operations Manager Database. Because of this I strongly recommend the use of the domain user account that is running your System Center Data Access Service, also known as the OMSDK service. If you are using a local system account to run the OMSDK service then use any account that has DB owner permissions on Operations Manager DB.
Step 2: Install the Operations Manager Gateway
Now we need to install the gateway by clicking the Gateway management server link in the setup splash screen. Below is a quick overview of the installation.
Give the management group a name. This can be found in the title bar of the console on the management server. Give the management server a name as well. The port number can be changed if desired. Only this one port needs to be open on the firewall which is the big advantage of using a gateway server!
Now we need to copy the MOMCertImport.exe tool to the gateway server and put it in the gateway installation path. We will use it later. In my case, this is C:\Program Files\System Center Operations Manager\Gateway.
Step 3: Run MOMCertImport.exe on the Gateway Server
To install our certificate, run the following command:
MOMCertImport.exe /SubjectName <gatewayServerName>
You should see a message similar to the one below.
You should also see an Event ID 20053 logged:
You’ll probably also see an Event ID 21007 similar to the one below:
OK, so at this point the gateway is registered in the Operations Manager DB and the role is installed, but it’s not communicating with my management server. Why?
This is because the gateway server is in workgroup or in domain that is different than Operations Manager management server domain and there is no trust, meaning we must configure the right certificate based authentication mechanism.
Wait a minute. What do you mean by ….Right…?
You can create different types of certificates with different intended purposes and import them in the gateway machine, but only the right certificate with the required authentication mechanism can work for gateway to agent or gateway to management server certificate based authentication.
From the gateway server (the one that is not in the domain) you don’t trust the Enterprise CA by default. That’s why you first have to get and install the Root CA certificate from the AD CS role.
Step 4: Import the Trusted Root Certificate
Here is where we begin configuring the required certificates. In order to configure certificates for this type of authentication we will need to do the following:
1. Import the trusted root certificate on the gateway server, the untrusted client computers and the management servers.
2. Create and install certificates (client, server) for the OpsMgr servers.
3. Create and install certificates (client, server) for the untrusted computers.
4. Export the certificate (client, server).
5. Allow manual agent installation.
6. Complete manual client agent installation.
7. Run MOMcertimport.exe on the computers where the certificates are imported.
9. Approve the agents once they successfully communicate with the management server via certificates.
IMPORTANT The trusted root certificate must be imported on all participating computers along with a computer specific certificate that will be used in certificate based authentication (e.g. agent and gateway, or gateway and management server, or agent and management server). Each computer will have one trusted root certificate and one machine specific certificate issued to the respective computer name.
By default, the trusted root certificate probably does not exist in our store. This can be verified by doing the following:
If the trusted root certificate is not here, the certificate from the Root CA needs to be added in this list.
To begin, open a web browser on the gateway server and go to the CA web service. My Certificate Authority server name is OM12DC1 so I go to the certsrv site on my Certificate Authority server which looks like this: http://OM12DC1/certsrv.
Add the certsrv website to Trusted Sites by going to Internet Options and under Security choose Trusted Sites click on Sites to add this site.
Since the certsrv website uses ActiveX, change the security settings of Trusted Sites so that ActiveX is allowed. In my case I go to http://OM12DC1/certsrv (or http://192.168.1.170/Certsrv since my CA server IP address is 192.168.1.170).
Here we need to request the CA chain:
If you don’t see these 2 popups, you need to enable ActiveX first.
Now import the Root Chain Certificate in the gateway server computer store.
The certificate is in the list now, meaning our gateway server will trust certificates issued by the Enterprise Root CA.
Now we need to request a computer certificate for our gateway server. This certificate will be used by the Health service on gateway server to communicate with other machines (e.g. management servers or other agents that use certificate based authentication).
Step 5: Request a Computer Certificate for the Gateway
Open a web browser on the gateway server and go to the CA web service. Select Request a certificate:
Select advanced certificate request:
Select Create and submit a request to this CA:
Select the template that we created earlier and fill in the Name and Friendly Name fields with the FQDN of the gateway server. Since mine is in a workgroup the NetBIOS name is sufficient.
NOTE If you are running a gateway server in a domain, be aware that you must chose the exact full name of the gateway server as it appears in System Properties.
Now the certificate is generated and we can install it.
But wait a minute…installed where???
We need to authenticate computers, and the certificate is imported in the user personal certificate store.
So now we need to open the Certificates MMC and export the certificate from user personal store “With private keys attached to certificate” and then import it into the computer personal certificate store.
Once complete, the certificate is now installed and you can verify that everything is installed correctly by opening the certificate and verifying that the certification path is OK.
Certificate Check List
You can use this checklist when importing certificates on a gateway server:
1. Make sure that the certificate is in the computer store, not the user store.
2. Check that the certification path is OK as per the screen shot below:
3. Always check that private keys are associated in the certificate.
4. Always make sure that the certificate Intended Purpose column shows that it’s for Server Authentication, Client Authentication. This is as we configured it in the template.
5. Always Run Momcertimport.exe (either 32-bit or 64-bit as appropriate) on the gateway, agent or management server where the certificate is installed.
This must be done on all servers where a computer specific certificate is imported in the MMC.
Also make sure that the exe you use is of the same version (32-bit vs 64-bit) and also make sure the file is from the same version of the OpsMgr server\agent you are running on the system:
1. Run a Command Prompt as an Administrator and navigate to the Operations Manager installation source folder.
2. Run MOMcertimport.exe and select the computer certificate you imported on this machine.
3. The certificate is now imported on this system.
4. Restart “OpsMgr Health Service” on the server.
If you get Event ID 21006, make sure the firewalls on the gateway and/or the management server are not blocking communication.
Lastly, don‘t forget to enable Agent Proxy for the gateway as it will act as a proxy for other systems connecting through the gateway server!
Step 6: Allow Manual Agent Installation
Before the first manual agent installation, the Operations Manager global setting must be changed from Reject new manual agent installations to Review new manual agent installation in pending management view in the Operations Manager console:
1. Open the Operations Manager console with administrator privileges.
2. Navigate to Administration –> Settings –> Server.
3. In the right-hand pane click Security.
4. On the General tab, select “Review new manual agent installation in pending management view” and click “OK” to finish.
Step 7: Manual OpsMgr 2012 Agent Installation
1. Logon to the server with administrator privileges.
2. From the Operations Manager installation media, double-click the SetupOM.exe file.
3. On the Start page, select Install Operations Manager 2012 Agent.
4. On the Welcome page click Next.
5. On the Destination Folder page leave the installation folder set to the default and click Next.
6. On the Management Group Configuration page leave the Specify Management Group information check box selected and click Next.
7. On the Management Group Configuration page, do the following:
– Type the Management Group Name
– Type the Management Server name. This can be the name of your gateway server if the agent uses one.
– Leave the default port of 5273.
– Click Next.
8. When the Agent Action Account page appears, leave it set to the default of Local System and then click Next.
9. On the Ready to Install page, review the settings and then click Install to display the Installing Systems Center Operations Manager Agent page.
10. When the Completing the Systems Center Operations Manager Agent Setup Wizard page appears, click Finish.
1. Make sure the agent can Telnet to its management server or its gateway server using port 5723 (whichever is chosen during installation setup for this agent).
2. If you cannot Telnet to port 5723, check firewalls on the management/gateway server as well as the agent computer. Usually this occurs when the Health service on the management server or gateway is not running or communication is blocked.
3. If Telnet is successful then follow the same steps mentioned above and import the chain root certificate in the computer store of the agent and also request a computer name based certificate for this respective agent as well.
4. Make sure this agent certificate includes all features such as Private keys, Server authentication, Client Authentication. It must have Successful Chain Cert as per the certificate properties.
5. Remember that you must execute momcertimport to register the machine name specific certificate on this agent followed by Health service restart.
How to Deploy a Gateway Server: https://technet.microsoft.com/en-us/library/hh456445.aspx
How to Chain Gateways: https://technet.microsoft.com/en-us/library/hh456427.aspx
Authentication and Data Encryption for Windows Computers: https://technet.microsoft.com/en-us/library/hh212810.aspx
Irfan Rabbani | Senior Support Escalation Engineer | Microsoft GBS Management and Security Division
System Center All Up: http://blogs.technet.com/b/systemcenter/
Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
Data Protection Manager Team blog: http://blogs.technet.com/dpm/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Microsoft Intune: http://blogs.technet.com/b/microsoftintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The RMS blog: http://blogs.technet.com/b/rms/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Surface Team blog: http://blogs.technet.com/b/surface/
The Application Proxy blog: http://blogs.technet.com/b/applicationproxyblog/
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
OpsMgr 2012 R2