none
OS Deployment: Certificate entry stays in the registry of a captured image.

    Question

  • At this moment I have two separate domains, ORANGE.LOCAL and RED.LOCAL. Both of these domains are in Native Mode. They both need to have the same image for testing, so I capture a image in de ORANGE domain and I want to use the same in the RED domain.
    This is where my "problem" starts... I thouhgt that with capturing a image the SCCM Client settings get totally cleared. But when I know try to deploy the image in the RED domain, the SCCM client can't verify the policies. (In the PolicyAgent.Log I get the message: "Signature verification failed for PolicyAssignmentID"). When I now look in to the registry in the CCM\Security entries I found out that it contains the values of the ORANGE domain...
    So I figured out that when I put an action in the Task Sequence that deletes de AllowedRootCAHashCode registry value it works again, bacause the client will find the correct value then itself. 

    What I would like to know is, if this is default behouviour of a SCCM client in Native Mode?

    Saturday, April 18, 2009 9:29 AM

Answers

  • Thanks for your patience.  The conclusion is that the whole Security key should be removed (which would also remove the AllowedRootCAHashCode value) after the "Prepare ConfigMgr Client for Capture" step in the capture task sequence.

    When they tested this, the captured image was deployed to a client in another native mode site that used a different root CA, and the client was successfully managed and configured with the native mode settings for its own site.


    One suggested method to delete the Security registry key:

    1.  Create a package with two reg files: one to delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security for x86, and one to delete HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\CCM\Security for x64.  For example, these might be called del_security_key_x86.reg and del_security_key_x64.reg.

    2.  Add two "Run Command Line" actions after "Prepare ConfigMgr Client for Capture" step in the capture task sequence. Each "Run Command Line" action invokes regedit.exe to merge one of the two reg files (for x86 and x64 systems), which will delete the Security registry key. Add a condition option to each action so that it runs only when the corresponding Security registry key exists.

    Example exported XML:

     <group name="Remove Security Reg Entries" description="">
              <step type="SMS_TaskSequence_RunCommandLineAction" name="Run Command Line" description="" continueOnError="true" runIn="WinPEandFullOS" successCodeList="0 3010">
                <condition>
                  <expression type="SMS_TaskSequence_RegistryConditionExpression">
                    <variable name="KeyPath">HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security</variable>
                    <variable name="Operator">exists</variable>
                    <variable name="Type">REG_SZ</variable>
                  </expression>
                </condition>
                <action>smsswd.exe /run:5230014F regedit.exe /s del_security_key_x86.reg</action>
                <defaultVarList>
                  <variable name="CommandLine" property="CommandLine" hidden="true">regedit.exe /s del_security_key_x86.reg</variable>
                  <variable name="SMSTSDisableWow64Redirection" property="DisableWow64Redirection">false</variable>
                  <variable name="PackageID" property="PackageID" hidden="true">5230014F</variable>
                  <variable name="_SMSTSRunCommandLineAsUser" property="RunAsUser">false</variable>
                  <variable name="SuccessCodes" property="SuccessCodes" hidden="true">0 3010</variable>
                </defaultVarList>
              </step>
              <step type="SMS_TaskSequence_RunCommandLineAction" name="Run Command Line" description="" continueOnError="true" runIn="WinPEandFullOS" successCodeList="0 3010">
                <condition>
                  <expression type="SMS_TaskSequence_RegistryConditionExpression">
                    <variable name="KeyPath">HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\CCM\Security</variable>
                    <variable name="Operator">exists</variable>
                    <variable name="Type">REG_SZ</variable>
                  </expression>
                </condition>
                <action>smsswd.exe /run:5230014F regedit.exe /s del_security_key_x64.reg</action>
                <defaultVarList>
                  <variable name="CommandLine" property="CommandLine" hidden="true">regedit.exe /s del_security_key_x64.reg</variable>
                  <variable name="SMSTSDisableWow64Redirection" property="DisableWow64Redirection">false</variable>
                  <variable name="PackageID" property="PackageID" hidden="true">5230014F</variable>
                  <variable name="_SMSTSRunCommandLineAsUser" property="RunAsUser">false</variable>
                  <variable name="SuccessCodes" property="SuccessCodes" hidden="true">0 3010</variable>
                </defaultVarList>
              </step>
            </group>





    - Carol

     

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Friday, May 29, 2009 7:13 PM

All replies

  • Take a look at Carol Bailey's blog post about reassigning clients aross hierarchies http://blogs.technet.com/configmgrteam/archive/2009/04/09/reassigning-a-configuration-manager-client-across-hierarchies.aspx

    I don't know whether this the default behaviour when the reimaging the computer using OSD. I would suspect that the "Setup Windows and ConfigMgr" action would take care of clearing out stuff from the other site, but I don't know for sure :-)
    Best regards Kristian F. Thomsen
    Saturday, April 18, 2009 10:10 AM
  • Thanks for your quick reply!

    That's exactly what I thought too, but for me it worked out different... I am going to have three domains with one image and if this is default behaviour I have to build the workarround of deleting the registry value in my Task Sequences. And if the problem is in my image, then I would like to know how it happened, so I can prefend this the next time.

    Saturday, April 18, 2009 3:38 PM
  • This value is tied to the site server signing certificate and the root CA that this certificate chains to.  Is one or both of these changed from the reference computer to the target computer(s)?  I wouldn't expect the different domains to make any difference here.


    - Carol

     

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Tuesday, April 21, 2009 9:29 PM
  • I didn't expect the different domains to make any difference either... I Captured the image in the ORANGE domain and I deploy the image in the ORANGE and RED domain. But when I deploy the image in the RED domain the values of the site server signing certificate and the root CA are still of the ORANGE domain... This is the part where I am wondering whether this is default behaviour or that something went wrong with Capturing the image.
    Thursday, April 23, 2009 12:00 PM
  • So, to clarify - are you saying that the client computer from which you did the capture (in the ORANGE domain) was assigned to the same site as both of the computers you deployed and all computers use the same root CA - but the deployed client in the RED domain failed whereas the deployed client in the ORANGE domain worked?  Or do you have multiple sites involved here?

    I'm not an OSD expert, so I don't know if this value (and others in this registry security key) should be cleared prior to the capture - but I can try to find out.  I would have guessed yes, because it's related to certificates and I thought all certificate information had to cleared from the reference computer prior to capture.  I do know we don't support editing the AllowedRootCAHashCode value, but I don't know if what you're doing by capturing it constitutes an "edit".  We support deleting this value (as you're doing with the task sequence), and letting the client recreate it during install by specifying the site server signing certificate, or letting the client recreate it if it downloads the site server signing certificate from AD or the management point. 

    If you can confirm the setup (single site and single root CA), I'll investigate this if I can find help from the OSD side.


    - Carol

     

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Thursday, April 23, 2009 3:52 PM
  • Thanks for your quick respons. I will try to clarify it by summing it all up.
    - Both domains (ORANGE & RED) are single sites.
    - There is no connection between the two domains.
    - Both domains have their own CA.
    - Image is captured in ORANGE domain.
    - Deployment of the image works in the ORANGE domain.
    - Deployment of the image works in the RED domain, BUT it still contains the values of the site server signing certificate and the root CA of the ORANGE domain.
    ---> SCCM client in RED domain can't verify it's policies, because of the wrong certificate values in the registry

    ---> Workarround I use: I create a Task Sequence step that deletes de AllowedRootCAHashCode registry value, during installation

    It would be great if you could find it out!
    Thursday, April 23, 2009 7:06 PM
  • "Both domains have their own CA"  So does this mean you have 2 issuing CAs that chain to the same root CA?  Or do you have 2 root CAs?
    Thursday, April 23, 2009 8:13 PM
  • It means that I have 2 Root CAs.
    Thursday, April 23, 2009 8:28 PM
  • OK - that's the important bit here, not the two different domains.  Yes, I would expect this to fail. 

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


    Issuing a New Site Server Signing Certificate from a Different Root Certification Authority or After Renewing the Root Certificate
    If you configure the Configuration Manager site to use a new site server signing certificate that chains to a different root certificate (either by using a different certification authority or by using the same certification authority but with a new root certificate that has a new key pair), clients will not accept the new site server signing certificate when they receive policies signed with the new certificate. This behavior provides security prevention against clients accepting a new site server signing certificate from a compromised management point. In this scenario, clients will not attempt to download the new site server signing certificate and will reject the policy they have downloaded, sending an error to the management point to alert the administrator to the fact that policy authorization failed. In this scenario, clients are unmanaged and the administrator must take remedial action.

    If you have changed the root certificate and need to install a new site server signing certificate, you must first delete the copy of the current site server signing certificate on Configuration Manager clients that is stored in the registry, by running a script on clients (for example, by running a task sequence in Configuration Manager or by using Group Policy). The client copy of the site server signing certificate is stored in the following registry key for 32-bit operating systems: HKLM\SOFTWARE\Microsoft\CCM\Security. It is stored in the following registry key for 64-bit registry systems: HKLM\SOFTWARE\Wow6432Node\Microsoft\CCM\Security



    - Carol

     

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Thursday, April 23, 2009 8:51 PM
  • That's exactly what I used for my workarround, BUT now I am still wondering what happens with the default Build and Capture Task Sequence from SCCM. Because I thought that all the SCCM Client settings get cleared during the step Preparing ConfigMgr Client for Capture. For that I would include clearing certificate information as well...

    Can you clarify that part for me?
    Friday, April 24, 2009 7:03 AM
  • Well, looking at the documentation for "Prepare ConfigMgr Client for Capture" (http://technet.microsoft.com/en-us/library/bb633049.aspx) it doesn't say anything about removing a copy of the site server signing certificate or the AllowedRootCAHashCode value, but I also can't find anywhere that warns you might have to remove it for this scenario. 

    There probably is an argument that the AllowedRootCAHashCode value is not a client setting - it's not specific to a client, or domain, or forest, or even hierarchy.  Because the PKI certificates for native mode are external to Configuration Manager, these registry entries are probably a grey area for whether they are considered related to the Configuration Manager client or not.  Additionally, most companies would have a single PKI and so wouldn't run into this issue, although they would if they deployed the image after the root CA certificate was renewed with a new key pair.  However, if everything else is cleaned, I would expect this value to be as well.  

    I'll raise this with the product group to confirm whether this is the expected behavior or not.  I suspect the answer will be to add an additional step to the documentation to delete this value or install the client with a copy of the new site server signing certificate - if applicable.  If that's their decision, I can help to make sure the docs get updated for this so that other customers are forewarned.


    - Carol


    This posting is provided “AS IS” with no warranties and confers no rights

    Monday, April 27, 2009 4:35 PM
  • It would be great if you could raise this with the product group to confirm whether this is default behavior or not.
    Monday, April 27, 2009 5:19 PM
  • Carol did you already hear from the product group whether this is expected behavior or not??
    Thursday, May 07, 2009 7:10 PM
  • Not forgotten - they are still investigating.  The delay might be partly my problem, because it occurred to me that this might be bigger than not clearing just the AllowedRootCAHashCode value.  If this value isn't cleared, I'm guessing there's a good chance the other registry values in this part of the registry are also not cleared.  This could then be a problem if deploying the client into an environment where AD isn't extended because the client will retain these values and they might not be suitable for the new site.

    Is this something that you could verify yourself?  These values are retrieved by an AD client if the site is publishing, so you would need to test a specific setting by deploying the client into a site that isn't publishing to AD and check whether the registry entry has been retained (eg the Select First Certificate data value).  If this doesn't make sense, let me know.



    - Carol

     

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Thursday, May 07, 2009 8:58 PM
  • That's not something that I could verify, because I only have environments where the AD is extended. What I do know is that, in my situation, the values in HKLM\SOFTWARE\Microsoft\CCM\Security are from the domain where the image was created. I hope that this information helps a bit...

    Friday, May 08, 2009 6:23 AM
  • Just to let you know that this is still flagged for investigation.  Because of the testing environment required, it's not a quick check and they probably will not get to this until end of the month.
    Monday, May 18, 2009 4:55 PM
  • Thank you for this update.
    Tuesday, May 19, 2009 6:01 PM
  • Thanks for your patience.  The conclusion is that the whole Security key should be removed (which would also remove the AllowedRootCAHashCode value) after the "Prepare ConfigMgr Client for Capture" step in the capture task sequence.

    When they tested this, the captured image was deployed to a client in another native mode site that used a different root CA, and the client was successfully managed and configured with the native mode settings for its own site.


    One suggested method to delete the Security registry key:

    1.  Create a package with two reg files: one to delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security for x86, and one to delete HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\CCM\Security for x64.  For example, these might be called del_security_key_x86.reg and del_security_key_x64.reg.

    2.  Add two "Run Command Line" actions after "Prepare ConfigMgr Client for Capture" step in the capture task sequence. Each "Run Command Line" action invokes regedit.exe to merge one of the two reg files (for x86 and x64 systems), which will delete the Security registry key. Add a condition option to each action so that it runs only when the corresponding Security registry key exists.

    Example exported XML:

     <group name="Remove Security Reg Entries" description="">
              <step type="SMS_TaskSequence_RunCommandLineAction" name="Run Command Line" description="" continueOnError="true" runIn="WinPEandFullOS" successCodeList="0 3010">
                <condition>
                  <expression type="SMS_TaskSequence_RegistryConditionExpression">
                    <variable name="KeyPath">HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security</variable>
                    <variable name="Operator">exists</variable>
                    <variable name="Type">REG_SZ</variable>
                  </expression>
                </condition>
                <action>smsswd.exe /run:5230014F regedit.exe /s del_security_key_x86.reg</action>
                <defaultVarList>
                  <variable name="CommandLine" property="CommandLine" hidden="true">regedit.exe /s del_security_key_x86.reg</variable>
                  <variable name="SMSTSDisableWow64Redirection" property="DisableWow64Redirection">false</variable>
                  <variable name="PackageID" property="PackageID" hidden="true">5230014F</variable>
                  <variable name="_SMSTSRunCommandLineAsUser" property="RunAsUser">false</variable>
                  <variable name="SuccessCodes" property="SuccessCodes" hidden="true">0 3010</variable>
                </defaultVarList>
              </step>
              <step type="SMS_TaskSequence_RunCommandLineAction" name="Run Command Line" description="" continueOnError="true" runIn="WinPEandFullOS" successCodeList="0 3010">
                <condition>
                  <expression type="SMS_TaskSequence_RegistryConditionExpression">
                    <variable name="KeyPath">HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\CCM\Security</variable>
                    <variable name="Operator">exists</variable>
                    <variable name="Type">REG_SZ</variable>
                  </expression>
                </condition>
                <action>smsswd.exe /run:5230014F regedit.exe /s del_security_key_x64.reg</action>
                <defaultVarList>
                  <variable name="CommandLine" property="CommandLine" hidden="true">regedit.exe /s del_security_key_x64.reg</variable>
                  <variable name="SMSTSDisableWow64Redirection" property="DisableWow64Redirection">false</variable>
                  <variable name="PackageID" property="PackageID" hidden="true">5230014F</variable>
                  <variable name="_SMSTSRunCommandLineAsUser" property="RunAsUser">false</variable>
                  <variable name="SuccessCodes" property="SuccessCodes" hidden="true">0 3010</variable>
                </defaultVarList>
              </step>
            </group>





    - Carol

     

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Friday, May 29, 2009 7:13 PM
  • Thank you for testing and finding this solution! It works!

    But does this mean that this is needed for everyone that wants to deploy an image to a client in another native mode site (that uses a different root CA)?
    Saturday, May 30, 2009 7:20 PM
  • Yes.  If you are taking an image from a native mode client, it's recommended to always delete this Security key because the existing settings might prevent the image from functioning correctly in a new environment.  However, in practice, you are probably only going to see a problem when you use another root CA (or the root CA certificate is renewed with a new key) as you did.  This is because the other settings are likely to be refreshed after the client is installed and retrieves its site settings from Active Directory Domain Services.


    - Carol

     

     

    This posting is provided “AS IS” with no warranties and confers no rights

    Sunday, May 31, 2009 2:43 PM
  • Ok! Thank you for all your help with this situation Carol!
    Sunday, May 31, 2009 3:52 PM