Remote Registry Permission Perplexity

This topic contains 0 replies, has 1 voice, and was last updated by Profile photo of Forums Archives Forums Archives 5 years, 4 months ago.

  • Author
    Posts
  • #5308

    by n3rdbiker at 2012-11-27 08:38:00

    I am trying to edit the remote registry to change permissions on two keys of a list of systems. Some of these systems will be on, some off, some I won't even have permissions to some of the systems... I have tried to prep for this as much as possible... when I run the script on my local system, everything is sunshine and rainbows....remote systems...hail fire and brimstone (well slight exaggeration)... please help in any way that you can. – will be sending to ~300 systems.

    function gisPerms {
    [CmdletBinding()]
    param(
    [Parameter(Mandatory=$True,
    ValueFromPipeline=$True)]
    [string[]]$computerName
    )
    # function takes a machine hostname as a parameter, locahost will not work
    # function can also be piped a list of machines
    Process {
    # Test to see if machine response on the network, if the machine does
    # not respond the script writes the machine name out to an error log
    # file and terminates.
    if(!(Test-Connection $computerName -Count 1 -Quiet)){
    $computerName | out-file -Append 'c:\scriptology\gisfix_failure.txt'
    }
    else
    {
    # error trap to capture any errors which occur while running
    # HKLM/Software/esri and HKCR/CLSID will have authenticated users added with full-control
    try{
    # create objects representing the remote registry keys

    $RemoteKeyLM = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $computerName)
    $RemoteKeyCR = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::ClassesRoot, $computerName)
    $regKeyLM = $RemoteKeyLM.OpenSubKey("SOFTWARE\esri",$true)
    $regKeyCR = $RemoteKeyCR.OpenSubKey("CLSID",$true)
    $AclLM = $regKeyLM.GetAccessControl()
    $AclCR = $regKeyCR.GetAccessControl()

    $AclLM.SetAccessRuleProtection($true, $true)
    $AclCR.SetAccessRuleProtection($true, $true)

    # Define the security roles, which will be applied to the registry objects
    # 's-1-5-11' is the SID which represents "Authenticated Users"

    [System.Security.Principal.SecurityIdentifier]$ident = "S-1-5-11";
    $rights = [Enum]::Parse([Security.AccessControl.RegistryRights], "FullControl");
    $allow = [Enum]::Parse([Security.AccessControl.AccessControlType], "Allow");
    $rule = New-Object Security.AccessControl.RegistryAccessRule $ident,$rights,$allow;

    $AclLM.SetAccessRuleProtection($true, $true)
    $AclCR.SetAccessRuleProtection($true, $true)

    $AclLM.AddAccessRule($rule)
    $AclCR.AddAccessRule($rule)

    $regKeyLM.setAccessControl($AclLM)
    $regKeyCR.setAccessControl($AclCR)

    # Close the open remote registry connection
    $regKeyLM.Close()
    $regKeyCR.Close()

    # Write system name to the success file
    $computerName | Out-File -Append 'c:\scriptology\gisfix_success.txt'

    }catch{
    # script execution failed / write system name out to failure file as well as the
    # error message identifying the failure
    $computerName | Out-File -Append 'c:\scriptology\gisfix_failure.txt'
    $_ | Out-File -Append 'c:\scriptology\gisfix_failure.txt'
    }
    }
    }
    }

    by DonJ at 2012-11-27 08:45:37

    Well... can you elaborate on the hellfire and brimstones? I don't have a lab handy in which to test your script myself, but if you can point to a problem (maybe share error messages), I can try and help you figure it out.

    I'll offer one thing right-off: Try/Catch can't trap errors; it can only trap full-on exceptions, and PowerShell doesn't barf exceptions by default. At the top of your script, set $ErrorActionPreference='Stop' to turn errors into exceptions. Normally, you wouldn't do that – you'd use a cmdlet's -ErrorAction parameter instead – but since you aren't using actual cmdlets, you kinda have to take this all-or-nothing approach.

    Also note that the Remote Registry Service has to be running for this to work, and on newer computers it'll be off by default.

    by n3rdbiker at 2012-11-27 09:14:21

    Sure thing. Here is a small sampling from the results of trying on 10 systems. I understand that some of the systems I don't have permissions to. I can live with that. On the idea of the Remote Registry Server... I can remotely connect to the registry from my system and then make changes? Does this indicate one way or the other that the service is active?

    Thank you for your help Don.

    by n3rdbiker at 2012-11-27 09:15:38

    System1
    Exception calling "OpenRemoteBaseKey" with "2" argument(s): "The network path was not found.
    "
    At C:\scriptology\testScript.ps1:13 char:17
    + $RemoteKeyLM = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey( ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : IOException

    System2
    Exception calling "OpenRemoteBaseKey" with "2" argument(s): "The network path was not found.
    "
    At C:\scriptology\testScript.ps1:13 char:17
    + $RemoteKeyLM = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey( ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : IOException

    System3
    System4
    Exception calling "OpenSubKey" with "2" argument(s): "Requested registry access is not allowed."
    At C:\scriptology\gis.ps1:49 char:17
    + $regKeyLM = $RemoteKeyLM.OpenSubKey("SOFTWARE\esri",$true)
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : SecurityException

    System5
    Exception calling "OpenRemoteBaseKey" with "2" argument(s): "Attempted to perform an unauthorized operation."
    At C:\scriptology\gis.ps1:48 char:17
    + $RemoteKeyCR = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey( ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : UnauthorizedAccessException

    System6
    Exception calling "OpenRemoteBaseKey" with "2" argument(s): "Attempted to perform an unauthorized operation."
    At C:\scriptology\gis.ps1:48 char:17
    + $RemoteKeyCR = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey( ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : UnauthorizedAccessException

    by DonJ at 2012-11-27 09:44:36

    So, you're getting "can't talk to the computer and/or Remote Registry Service," "You don't have permission," and "You don't have permission." Not much you can do about any of those ;).

    by n3rdbiker at 2012-11-28 05:55:34

    Sir I will have to run on a bigger sampling — is it possible that the registries aren't allowing the remote connections / and perhaps there is a method or an invokation I am missing? – I know that on some of these machines, I am an admin.

    by n3rdbiker at 2012-11-28 06:06:31

    I have ran on a system which I had confirmed admin rights — hope this helps move me out of the rut... I also ran in debug mode so I can tell you where in the script the failure happened.
    – The failure happened here: $AclLM = $regKeyLM.GetAccessControl() and the error produced was:
    NEW SYSTEM WITH CONFIRMED ADMIN ACCESS
    Exception calling "GetAccessControl" with "0" argument(s): "The supplied handle is invalid. This can happen when trying to set an ACL on an
    anonymous kernel object."
    At C:\scriptology\gis.ps1:51 char:17
    + $AclLM = $regKeyLM.GetAccessControl()
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentException

    by DonJ at 2012-11-28 07:36:49

    Ah.

    A quick Google of that error led me to http://powershellcommunity.org/Forums/t ... fault.aspx, which says those .NET Framework classes don't support remotely writing registry ACLs.

    I also found http://arnoutboer.nl/weblog/?p=310, which the comments seem to indicate worked, although with some additional code. Might have a look there.

    Sorry I can't be more definitive for you – you're outside the shell and down in the Framework, which isn't my real area of expertise. My normal recommendation would be to (a) put PSH v2 or v3 on these machines and (b) use Remoting to do all this, but I realize that isn't possible for some folks. It's something you should consider, though, as it's Microsoft's "way forward" for remote administration.

You must be logged in to reply to this topic.