System Center Configuration Manager Remote Control ACL issue

  • Context

I’m currently deploying the System Center Configuration Manager Agent 2012 SP1 over workstations that had previously the SCCM 2007 Client version 4.00.6487.2000

  • Symptoms

Helpdesk operators say that the remote control tool launches but that the client doesn’t see the window asking him to authorize or deny access to the helpdesk operator.

It looks like that all the process involved in the remote control are correctly launched on the client

gwmi win32_process | ? { $_.Commandline -match "CCM" } |  fl Commandline

The remote control window of the helpdesk operator doesn’t time out.

  • Analysis

Neither restarting the ConfigMgr services nor running the CCMEval task (Configuration Manager Health Evaluation) fixes the issue.
It’s time to digg in the numerous logs files of the ConfigMgr client:

Get-ChildItem C:\Windows\CCM\ -Include *.log -Recurse | Select-String -Pattern "SOFTWARE\\Microsoft\\SMS"

Using CMTrace.exe to read the logs, I can see that:
The log file under C:\windows\ccm\Logs\CmRcService.log contains the following errors:
Failed to open registry key Software\Microsoft\SMS\Client\Client Components\Remote Control\SessionStatus (0x80070005) for reading

Failed to open registry key ‘Software\Microsoft\SMS\Client\Client Components\Remote Control’. Permissions on the requested may be configured incorrectly.
Access is denied. (Error: 80070005; Source: Windows)

The log file under C:\windows\ccm\Logs\CcmExec.log contains the following additionnal info related to the issue
Failed to query size of Security (may not exist) (0x80070002)
Failed to get SID for ConfigMgr Remote Control Users (0x80070534)

  • Cause

If I compare a workstation that doesn’t have the issue and one that has, I can see that the registry permissions on HKLM\Software\SMS are not inherited from the parent. The BUILTIN\Users ACL is actually missing which causes the issue.

Here’s what I can see with PowerShell on workstation that has its registry permissions not set correctly:

$acl = (Get-ACL HKLM:\SOFTWARE\Microsoft\SMS)            
$acl.Access            
$acl.Sddl



The corresponding SDDL looks like: O:BAG:SYD:P(A;OICI;KA;;;SY)(A;OICI;KA;;;BA)

  • Solution

Although I don’t have time to fill-in a bug or to understand the root cause, I came up with the following quick fix.

if (Test-Path HKLM:\SOFTWARE\Microsoft\SMS) {            
    $acl = (Get-ACL HKLM:\SOFTWARE\Microsoft\SMS)            
            
    # SetAccessRuleProtection(bool isProtected, bool preserveInheritance)            
    # Allow inheritance            
    $acl.SetAccessRuleProtection($false,$false)            
                    
    # Enumerate all Access rules that are not inherited            
    # GetAccessRules(bool includeExplicit, bool includeInherited, type targetType)}            
    $acl.GetAccessRules($true,$false,[System.Security.Principal.NTAccount]) | ForEach-Object -Process {            
        # RemoveAccessRule(System.Security.AccessControl.RegistryAccessRule rule)            
        $acl.RemoveAccessRule($_) | Out-Null            
    }            
    # Set the ACL            
    try {            
        Set-Acl HKLM:\SOFTWARE\Microsoft\SMS -AclObject $acl -ErrorAction Stop            
    } catch {            
        Write-Warning -Message "Failed to restore inherited ACL from parent because $($_.Exception.Message)"            
    }                    
}

Note that the 2nd parameter of the .Net SetAccessRuleProtection Method (preserveInheritance), is ignored if the first (isProtected) is set to false. More on the following MSDN page.

As I have enabled the Powershell remoting I can also execute on a remote computer by simply passing the above code as a scriptblock to the Invoke-Command cmdlet.
Did I already say that Powershell rocks! 😎

Advertisements

8 thoughts on “System Center Configuration Manager Remote Control ACL issue

  1. Hi I’m working on the issue now, I have made a configuration baseline and remediation rule using your script. Ticket is logged with Microsoft. I noticed the reg is ‘Sms’ instead of ‘SMS’ so it looks like the msi may be not running a step that creates the initial reg key, then it runs another step where the lower case Sms is mentioned and thats how it creates a key without the right permissions. I’ve verified that it doesn’t carry the case of the reg key over from the wow6432node – must be in the msi.

    • Hi,
      I haven’t logged a ticket as I didn’t find a way to reproduce it.
      You’ve made a good assumption. I’m also curious to know what Microsoft says about this. Let me know if you’ve got something new about this issue.

      • Yeah I am having a hard time being able to replicate it. Tried vm and a few different machines (ghosting before migrating in hopes of being able to replicate) – I work at a uni so I’ve seen whole labs of computers with the issue but when I add a machine to the same collections etc the issue doesn’t happen.

        Will update when I have some good news.

      • Hello,

        Running into the same issue here, was wondering if jayconner ever received anything back from Microsoft in regards to this issue?

  2. Hi Emin and Ron,
    Unfortunately MS were unable to reproduce it and we ended up closing the case as we could use the workaround quite successfully.

    Last email from MS:
    Analysis and solution:

    The permissions are wrong on the permissions on HKLM:\SOFTWARE\Microsoft\SMS, as referring to https://p0w3rsh3ll.wordpress.com/2013/04/19/system-center-configuration-manager-remote-control-acl-issue/

    The BUILTIN\Users ACL is actually missing.

    We are using DCM to check and fix the registry permission.

    For the RCA, both of us can’t reproduce the issue.

    Based on the previous logs and code review, we have not confirmed the root cause for this.

  3. Thank you for the script , and that solve my workstation that have the remote tool problem same as described here.

    Question if I deploy this script to all workstations will it will solve only the workstations that have the remote tool issue , is it a good idea ?

    Thank you.

    • I can tell you what I do in my environment, I’ve got a script that detects and reports the issue and then have the remediation code that fixes this issue.

      That said, answering the question is up to you. You know your environment. Before deploying to all workstations, it may be safer to first assess how many workstations are affected by this issue. Then you could decide whether you should apply the fix to all workstations or a subset. Once you’ve the scope and before deploying the remediation code, you could use the detection code in an if/else statement and combine it with the code that fixes the issue. Then, you can test the whole code on to an even lower number of targets and finally apply it to any workstation.
      The code logic would look like this

      $boolean = Test-isSMSAclFixRequired
      if ($boolean) {
       Run-SMSAclFix
      } else {
       # fix not required
      }
      

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s