CSA blocking SCCM 2007 Agent Install and Remote Tools (remote registry)

joelcoovert · ‎01-06-2009

We upgraded SMS 2003 to SCCM 2007 and CSA isn't liking it very much. We have two main issues, both going to the same root cause, remote registry access.

1. SCCM Client Install

-initiating an install from the managment console generates a series of messages about remote registry access similar to this one:

The process '<remote application>' (as user system\Administrator) attempted to access the registry key '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Lsa\SspiCache\digest.dll' and value ''. The attempted access was an open (operation = OPEN/KEY). The operation would have been denied.

Numerous registry keys are accessed. I have managed to tune out all other aspects of the agent installation.

2. Remote Control/RDP from outside the firewall

-The new agent does remote control differently than in SMS 2003. If no user is logged in, it attempts RDP. It also generates remote registry logs similar to the following:

TESTMODE: The process '<remote application>' (as user domain\user) attempted to access the registry key '\REGISTRY\MACHINE' and value ''. The attempted access was an open (operation = OPEN/KEY). The operation would have been denied.

This only happens if the person attempting to utilize the remote tools is connected by VPN. When physically at the main campus it works fine.

The one difference I have noticed is that the agent install logs indicate the local administrator account of the machine, and the remote tools logs capture the domain user account of the person attempting to utilze the remote tools. For obvious reasons, I do not want to open up full registry access to <remote application> but need at least partial access to solve these issues.

The only thought I have at this point is to create a set of registry keys based on the logs and allow them as an exception to the deny rule.

Suggestions anyone?

Joel

tsteger1 · ‎01-06-2009

I use a User State and\or a set of registry keys to allow similar operations.

The registry set may work for the SCCM Client Install that accesses a well defined area of the registry.

You can also create a DAC rule that will only allow access when certain conditions are met.

The User State may work best for the RDP outside the firewall since the keys accessed are broad and it is logging the domain\username.

Tom

joelcoovert · ‎01-06-2009

Looking at the logs, both scenarios appear to hit fairly well defined registry sections.

I will look into the User State solution for the RDP. There are other operations performed by the SCCM console that access the registry.

Thanks for the suggestion!

Joel

tsteger1 · ‎01-06-2009

You are welcome and please let us know how it goes.

Tom

joelcoovert · ‎01-07-2009

It does not look like a User State will work in either case, as this appears to depend on the locally logged on user. It is the policies on the target machine that are causing the denials.

For the agent install, it needs to be able to install itself regardless of a locally logged on user.

The remote tools check for the presence of a logged on user and if found, prompt the user to allow remote control of the machine. If no user is logged on, the tool offers the use of RDP. Thus, there may/may not be a locally logged on user. While I could create a User State for the IT folks utilizing these tools, it would not apply to the target machine where the policies are blocking remote registry access.

At this point I have spent the day and most of my evening trying to identify the registry keys targeted by the install agent and remote tools. I keep finding new ones and suspect wildcards may be needed. I am hoping to find a way to grant the needed access without creating a larger opening than necessary.

Joel

tsteger1 · ‎01-08-2009

Joel, perhaps a system state is better suited for this.

Do you have the "Installation Applications - Windows" policy associated with your group(s)?

You could use these to classify the install and have it dynamically added to the system state:

"Installation - Application Detection - Install detected"

If it isn't detected as an install, you may need to tweak the rules a bit to see it.

Once it classifies it as an install, you can create the exception to allow it to run unimpeded.

Tom

joelcoovert · ‎01-09-2009

Yes we do. But this would only address the agent installation issue, not the use of the remote tools.

I did find one of our groups that I can place the host into and achieve the intended results. I have disabled the current rule that I created with the new registry set and am further evaluating the associated policies and rules to ensure utilizing this group will not have any other undesired results.

Joel