Using Public Certificates With SCOM Part 1

From time to time with SCOM, you will need to enable monitoring of servers and clients that are outside of the normal boundaries of your Active Directory environment. These servers and clients may be in your DMZ as workgroup machines, or maybe you have a number of completely different Active Directory domains and forests that have no relation with each other yet need to be centrally monitored by your SCOM implementation.

If you have a large number of servers and clients in an untrusted domain to the SCOM domain, then you would most definitely want to install a SCOM gateway server into that domain and have this as the central point of contact with your main SCOM RMS and MS servers.

The SCOM Gateway Server uses certificate authentication to authenticate with the SCOM RMS / MS servers and certificate configuration has to only be carried out once between the SCOM RMS /MS and SCOM Gateway devices. The SCOM Gateway Server would then distribute the SCOM agents to each client in the untrusted domain / workgroup and pass the monitoring information over to the RMS and MS in the trusted domain.

See the link below for some additional information on SCOM Gateway Servers and their configuration from MS Technet:

http://technet.microsoft.com/en-us/library/bb432149.aspx

No matter whether you decide to use a SCOM Gateway Server or just install the SCOM agents manually onto your DMZ based servers and clients, you will need to configure Certificate Authentication with either an internal Certificate Authority (such as an Active Directory CA) or if that isn't an option (or you're brave enough to attempt it!), then you could also use a 3rd Party Certificate Authority such as Thawte or Veritas as an example.

This short series of blog posts have come about from the necessity of a particular project I was working on recently that had procedures in place to only use Public Certificates on all of their servers. I managed to get Public Certificates working with this client's DMZ machines using information from a number of different blog posts, forums and also some thrown in knowledge of my own based around public certificates. I felt that although the information is available if you look on the internet, I couldn't find one single source of information that took me from step to step with this process, so therefore I decided to blog about it myself to save someone else the hassle!!

Update:
If you are using an internal Certificate Authority for issuing your certificates to your SCOM environment, read my blog posts on internal CA's with SCOM here for more information.

Here's a High Level Overview of the process to get your SCOM environment monitoring your untrusted DMZ, Domain or Workgroup machines when a SCOM Gateway Server is not being used:

• Allow Port 5723 from your untrusted DMZ/Domain to the SCOM RMS and MS Servers
• Enable Manual Agent Installation from the SCOM Administration Wunderbar
• Manually install the SCOM Agent onto each untrusted server and client that you want SCOM to monitor
• Create a Certificate Template .INF file that will assist with the Certificate Request to the Public CA
• Use 'CertReq.exe' to create the Certificate Request on the SCOM RMS/MS and untrusted servers
• Forward the Certificate Request to the Public Certificate Authority
• Use 'CertReq.exe' to approve and install the newly issued Certifcate from the Public CA on the SCOM RMS/MS and untrusted servers
• Use the 'MOMCertImport.exe' utility on all servers (SCOM and untrusted) with the '/subjectname' switch to tell SCOM which certificate to use for authentication
• Restart the 'Health Service' on the SCOM and untrusted servers
• Approve the Manual Agent Installation from the SCOM Console Wunderbar

In part 2 and part 3 of this series, I will go into more granular detail on this process with some screenshots included too!