Hello everyone,
we want to monitor the registries of our servers. In a post a Paessler supporter provided a powershell script to accomplish that (https://kb.paessler.com/en/topic/68254-how-can-i-monitor-the-windows-registry-with-prtg). So far so good.
To our situation:
Our PRTG Probe Server (VM) is not joined in our domain due to security concerns. Nevertheless it is in the same network as some servers. So there is no further firewall in between. Sensors like Ping or WMI Service are running like a charm.
Configuration:
I copied the mentioned ps1 on the PRTG Server (Local Probe). The WinRM and remote registry service is running and the local firewall of Windows (Windows Server in this case) was opened for the communication (TCP Port 445, 5985). I did the same on a test server with the addition that I set read permission of our prtg service account for the registry with following Reg Key :"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg". I set the ExecutionPolicy to Unrestricted on both machines for testing. I even added them to trusted hosts ("Set-Item WSMan:\localhost\Client\TrustedHosts -Value <IP>").
Testing (Registry/Ps1):
For testing I tried to connect from the PRTG server to the registry of the test server via regedit.exe -> connect to networking registry. The test was successful. In the next step I tried it with the ps1 (powershell -f "WindowsRegistrySensor.ps1" -... -x64). Successful as well: "0:Registry key 'xy' holds '...' and matches pattern ...". --> The ps1 was executed as .\Administrator on the local probe. Just like the paessler support mentioned the script only works with 64bit Powershell. When executed with powershell x86 it is not able to read / connect to the registry.
Testing (With PRTG):
Now I created an EXE/Script sensor for the local Probe in PRTG with the ps1 and the correct parameters. I tried both security contexts:
- "Use security context of the PRTF probe service" (SYSTEM): --> Script error: "System error: Couldn't connect to remote registry. The error was: Exeption when executing "OpenRemoteBaseKey" with 2 argument(s): "An attempt was made to perform an unauthorized operation." (Code: PE022)"
-"Use credentials of Windows parent device": --> Error: "Access has been denied. To solve this problem, check your Windows system credentials in the device settings. (Code: PE095)"
From this I conclude: When using the "SYSTEM" user of the PRTG probe the script is running but has no access to the registry of the server I would like to monitor. Logical, because the prtg computer (with his SYSTEM context) has no access to the registry on the server i would like to monitor (Reg Key). And I can't set the PRTG probe to have permission to this registry key because the server is not recognized (not in domain). But why does it work as local administrator of the PRTG Server with powershell x64?
When using the credentials of the parent device that has access to the registry the ps1 does not seams to be able to run. I got the same error message when I forgot to turn down our application control which blocks unsigned powershell scripts. In this case PRTG works like "execute as". And because the PRTG probe is not in the domain it doesn't know the domain service account and can't execute powershell.
I have read about "runas /netonly" to get some magic happen with non domain / domain execution. But I can't pull that off with PRTG.
I also tried to create a local computer account whith the same credentials as the service account in our domain.
Does anyone has a suggestion? I know it is pretty uncommon to have the PRTG server (probe) not joined to the domain.
Is there a configuration on the PRTG probe which I missed? Like "allow parent device account" to run ps1 or something like that.
I would be happy for any advice. And excuse me if there are some English mistakes.
Note:
The ps1 is only able to run with powershell x64. I read that PRTG only runs powershell scripts with 32 Bit. As a workaround I used the Psx64.exe from PRTG Tools Family (https://mycloudrevolution.com/de/2016/03/21/veeam-prtg-sensor-reloaded/). But I think my problem occurs ecen before that.