Core Reference: Authentication and Data Encryption for Windows Computers in Operations Manager 2007Link to the script: http://gallery.technet.microsoft.com/MOMCertImport-c3e7093b
Note: While the below does work, it isn’t the Windows Server and System Center Product Groups official solution so if you can’t get it to work or have problems, please use the steps in the above reference. That said, at the end of the day all MOMCertImport seems to do is import one used registry value.
Even though I tend to focus on platforms/OS related stuff, I’ve long since come to the realization that I can’t exclude tools such as System Center suite to help maintain and run a datacenter with high availability. As such, I am constantly looking for how to leverage System Center to accomplish my platforms needs. With things tending to be a little less hectic around the holidays I was able to spend some time solving some of those problems.
Not surprisingly the lab machines are frequently rebuilt. In addition, having become utterly dependent on System Center for making sure the lab is relatively stable on a day to day basis and configured according to best practices. This includes the use of both System Center Configuration Manager and System Center Operations Manager to deploy patches, deploy the monitoring agents, some other basic utilities, as well as basic monitoring. The challenge in this lab are that there are 2 forests that do not have a trust. While deploying the System Center Configuration Manager Client across the two un-trusted forests is a relatively easy exercise, getting the SCOM agents deployed to systems in the “remote” forest and talking to the Management Server has been a very painful exercise.
As many are aware, MOMCertImport is the officially provided tool to do this and there is plenty of content out there on how to use it. The beef was that this process seems to have some rough edges and was very cumbersome every time a lab machine was flattened and redeployed. The following are the sources of frustration every time there was rebuild:
With those questions in mind it was time to start digging to understand what was going on when MOMCertImport is run. This is what I found:
First, in just trying to dig up the instructions (for the umpteenth time) as well as troubleshooting the automation for importing the code below, the following were useful references as I proceeded:
Being cautious with information, I looked to validate what I found. I started investigating where I always do when it comes to trying to figure out what is happening on a system, good ol’ Process Monitor. After setting the filter on Process Monitor as follows, here is what MOMCertImport.exe did:
The results were as follows:
Note: I looked to see if any files were changed (filter on Operation “CreateFile” and “WriteFile”) and there were not any changes outside of MOMCertImport re-importing the certificate into to the store.
With remained was that MomCertImport created/changed two registry values:
The above blog entries focused on the ChannelCertificateSerialNumber registry value. However, since there was a minor divergence between what was found in those reference and what Process Monitor uncovered, and I don’t know why MOMCertImport sets 2 keys but will work with only one, I decided to just copy the behavior of MOMCertImport.
Looking more closely at the registry values unveiled the following:
This also solved all the problems I outlined above:
Furthermore, I found that MOMCertImport does no validation to determine if the certificate being imported meets the requirements of the SCOM agent. In the automation below, it heavily leverages the content in the Troubleshooting OpsMgr 2007 and OpsMgr 2012 certificate issues with PowerShell article to institute validation before attempting to import the certificate.
Note: There are a plethora of copies of articles out there how to do create/validate the certificates. A large variance in the values for KeyUsage were found. While I was able to get this to work with a KeyUsage value of 0xA0, as per the reference PowerShell troubleshooting script, the PG’s content on TechNet states 0xF0: How to Obtain a Certificate Using Windows Server 2008 Enterprise CA in Operations Manager 2007. I don’t know if this is a supported scenario, thus if using the PG reference, the “Computer” certificate template will need to be updated. Also, I could use a smaller “KeyLength” than specified in the PG article, thus it seems the agent doesn’t care about the KeyLength.
There were several things that were necessary to automate:
The first step towards doing this was to ensure that the above 3 tasks could be repeated on a per machine basis consistently. To that end a PowerShell script seemed to be the best approach. As can be seen from the comments on some of the previous blog posts, this blog platform doesn’t handle code and code formatting very well, plus the script is over 750 lines. As such, the resulting script is uploaded on Technet’s ScriptCenter. Go here to download it: MOMCertImport.
The second step in the automation is to consistently get all the appropriate lab machines to run the scripted tasks. Enter SCCM.
That’s it! Now just deploy the Application.
Note: Initially I tried signing the script. However it appears that when importing the script into the Detection Method SCCM does some reformatting. As can be seen from the screenshot the script length is 658 lines whereas the script uploaded to TechNet ScriptCenter is 757 lines. This reformatting breaks the signature.
If you did create a custom certificate type with a known template name and made it an auto-enrolling template then surely you could just pluck the certificate with that template out of the certificate store and use the values on that cert. This would simplify
things considerable wouldn't it?
That is a perfectly valid approach as well. At the end of the day, what matters is the certificate is configured as per the SCOM guidance. I just chose to use the auto-enrolled default certificate because it was already on the machine and didn't require the additional step of creating a template. The provided script supports CA templates and non-CA templates to accommodate all scenarios. The larger focus here was automating the configuration of the agent end to end, not the strategies to get the certificate on to the machine. The portion of the script related to acquiring the certificate also serves as a sample for others to use in order to integrate with whatever security policies are relevant in their organization. Note: In the above article I referenced other Microsoft topics regarding certificate creation and validation. The article on validation is significant since creating/acquiring the correct certificates is a pain point for many admins and MOMCertImport does not validate that the certificate it is directed to import is complaint with the documented configuration. Troubleshooting these scenarios, especially for people without significant exposure to certificates in general can be difficult. Hence, with the larger picture of completely automating the process in mind, validation is an important step in ensuring that the final configuration will work.