다음을 통해 공유

MOMCertImport – Is it all it’s cracked up to be?

  • 아티클

Context

Core Reference:  Authentication and Data Encryption for Windows Computers in Operations Manager 2007
Link to the script:  https://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:

  1. Both of the forests have Certificate Authorities and use auto-enrollment for all systems in the forest.  Why can’t it just use the certificate that the machine automatically picked up on domain join?
  2. Why is in necessary to create a custom template that had the exact same OIDs as the “Computer Template” that auto-enrollment used?
  3. Why is it necessary to create a certificate with the Private Key marked as exportable and ship it around to get it installed?  Not only a hassle, but also has potential security and manageability implications.
  4. Why is certificate enrollment such a cumbersome process?
  5. Why is it necessary to have to have two certificates on each machine thus confusing every other application (and me when troubleshooting) on the systems that didn’t know how to handle two certificates with identical OIDs, subjects, etc?
  6. In all fairness, a couple of the above challenges can be bypassed using the “/SubjectName” switch, however on a machine with multiple certificates with the same subject name MOMCertImport doesn’t always select the certificate that supports all the requirements for the SCOM agent.
    Note:  This wasn’t tested rigorously, but it seems to select the certificate with the SubjectName that was imported into the local machine store first.

Discovery

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:

image

The results were as follows:

image

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:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings
    • ChannelCertificateHash (REG_SZ)
    • ChannelCertificateSerialNumber (REG_BINARY)

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.

Analysis

Looking more closely at the registry values unveiled the following:

  • ChannelCertificateHash – This is the “Thumbprint” of the certificate.
  • ChannelCertificateSerialNumber – This is the “Serial Number” of the certificate.  As the references above illuminated, this is a REG_BINARY value and has the byte values stored in the reverse order they are stored in the certificate.

This also solved all the problems I outlined above:

  1. The certificates the computer gained through auto-enrollment can be used for the SCOM Agent.
  2. No custom template needs to be created.
  3. There is no need to have the Private Key be exportable or manually copy it around the environment.
  4. This can be simplified by using pre-existing certificate enrollment automation.  Reference “Configure Certificate Autoenrollment” to enable
  5. This can all be done with one certificate.
  6. The Serial Number is what stored in the registry allowing for very precise selection of the certificate.

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.

Automation

There were several things that were necessary to automate:

  • Validating existing configurations via SCCM.  Is there a certificate configured, installed, and valid for the SCOM Agent.  This IS SCCM’s detection method for the Application to configure the certificate.
  • Select a valid certificate from the local store and configure the SCOM Agent to use it.
  • Validating one or more certificates.

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.

Creating the Application Deployment Type

Configuring Programs Properties

  • Installation Program - powershell -ExecutionPolicy Unrestricted -File .\MOMCertImport.ps1 –InstallBestFitFromLocalStore
  • Uninstall Program - powershell -ExecutionPolicy Unrestricted -File .\MOMCertImport.ps1 –Remove

Programs

Configuring Detection Method

  • Set the Script Type to PowerShell
  • Paste in the text of script above

Detection Method

Configuring Dependencies

  • Obviously, configuring the certificate for the SCOM agent does no good if the agent isn’t installed.  Configure the deployment of the SCOM agent as a dependency of this Deployment Type.

Dependencies

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.

client policy 

Updates:

  • 1/18/2014 – Fixed a bug in the Enhanced Key Usage Extension check.  It was passing everything if $EnableDiagnostics switch was used.
  • 1/18/2014 – Added the ability to request a certificate from Microsoft Enterprise and Standalone CAs (untested against non-Microsoft CAs, but give it a try and let me know how it goes).
  • 1/18/2014 - Now the file is so large it won’t cut and paste into the SCCM script validation.  However, if the “Open” option is selected and the script is loaded from a file it works fine.  This can also be solved by deleting the help content, the constants at the start, and everything in the #region Certificate/Request Install, as well as the labels in the “Main” switch statement for CreateCertificateRequest and GetCertificateResponse.  Yes, there is now some broken code in Main that references the certificate request functios, but it works.
  • 1/18/2014 – This script WILL work against the SCOM server, but since the SCOM agent shouldn’t/can’t be installed on the SCOM server, the dependencies will prevent the script from running and will set the deployment state to “Not Applicable”.

Comments

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    March 27, 2014
    Context Even though I exclusively work on the infrastructure side, I operate under the theory that if

  • Anonymous
    June 23, 2014
    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?