Monitoring SCOM Agents in Workgroups or DMZ Environments - Part 1
In this article, I explain how SCOM can monitor agents outside of the Active Directory forest, in Workgroups or in DMZ environments.
Many of our clients who have SCOM implemented in their organization keep asking us "how can we monitor agents outside of the Active Directory forest, in Workgroups or in DMZ's?" Our answer is almost always: "SCOM is very versatile and allows for the configuration of many monitoring scenarios, untrusted environments included".
Basically, it all comes down to three recommended core steps:
- Step 1: Create the SCOM certificate template.
- Step 2: Install the SCOM Gateway component.
- Step 3: Issue certificates to all involved parties including Management Servers, Gateways and Monitored Agents.
In this part of the article, I'll walk you through the first step: Create the SCOM certificate template.
First and foremost, why do we even need a certificate when clearly one isn't needed when monitoring agents inside the forest? Most current products that value security as well as all of the System Center server products, SCOM included, use Mutual Authentication to verify both communicating parties: The server and the Client – In our case, the Management Server or Gateway and the monitored SCOM Agent. There are a lot of ways the servers and clients can mutually authenticate each other without any risk of third parties hijacking the communication session but when SCOM is concerned, Mutual Authentication is supported in two ways: Kerberos or Server and Client Certificates. When SCOM Agents are in the same Active Directory forest as the SCOM Management Server, Kerberos is available and is used by default without us having to configure anything else. But in some cases, we need to monitor agents who aren't part of the domain and in these cases, Kerberos cannot be used. This is exactly why we need the Gateway component and Certificates for both clients and servers.
Creating the SCOM Certificate Template
The SCOM certificate template is basically a modified IPsec template that allows both server and client authentication (You got it! Mutual Authentication). To create the template, you need to make sure you have an Enterprise CA installed and configured. If you don't have one, you can always install one from Server Manager and add the required Server Role. Open the 'Certification Authority' MMC snap-in, right-click on the 'Certificate Templates' node and click on 'Manage Certificate Templates'. Search for the 'IPsec (Offline request)' template and duplicate it.
Now all we have to do is modify some properties:
- Change the name into something that makes sense like "SCOM Certificate".
- Make sure to enable the 'Allow private key to be exported' option. This will allow us to issue certificate requests on behalf of the workstations and servers in the workgroup and then export the issued key pair.
- Open the 'CSP Selection' dialog and enable only the required cryptographic service providers:
- Move to the Extensions property page and open the 'Application Policies' dialog. This part is what actually makes this certificate template support mutual authentication. Remove all existing values and add only 'Client Authentication' and 'Server Authentication'.
- Just before saving everything, make sure you grant the relevant users Read and Enroll permissions to the new template. Users who need this permission are the ones who are going to perform the actual requests. If you're not too sure, just grant the permissions to the 'Authenticated Users' group.
- Click 'OK' to finish editing the new template and save all our changes.
- Just before you close the 'Certification Authority' MMC snap-in, add the template we've just created to the 'Certificate Templates' node.
That's it! In the next part of the article, we'll cover how to install the SCOM Gateway server as an intermediary so we only have to issue certificates to the external clients. We'll also talk about how to actually request a certificate based on the template we've created.
Be patient :-)comments powered by Disqus