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.
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.
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...