What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Changing the PRTG Core Service Account

Votes:

0

Your Vote:

Up

Down

I recently moved our PRTG server from a local setup to a cloud setup. Because it now operates outside of our internal network, security best practices are now more of a concern. Specifically, I am trying to change the user account that is used by both PRTG services from LOCAL SYSTEM to something more limited.

The PRTG Probe Service accepted my new dedicated PRTG user account and starts up just fine. Check.

But the PRTG Core Service will not start when using this dedicated PRTG user account. I have ensured that this PRTG user account has full rights to all relevant directories (Program Files, ProgramData, Logs, etc), but clearly I am missing another step.

I am not able to find the process on how to modify the PRTG Core Service Account anywhere in the documentation. Can you please explain how to change the Service Account for the PRTG Core Service from LOCAL SYSTEM to a dedicated local account? Thank you for your help.

local-system-account log-on service-account

Created on Jan 14, 2017 4:33:52 PM by  Aaron (60) 1



9 Replies

Votes:

0

Your Vote:

Up

Down

Dear Aaron

The core service should be run via the Local System account to make sure it has all access rights required. An account for the core service for example needs access to the local registry.

Created on Jan 16, 2017 1:34:19 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

There are plenty of account types that have access to the registry without signing on as the full LOCAL SYSTEM account. I have many other resources on this system which I do not want a compromised (in theory) PRTG account to be able to access.

Surely you are aware of best practices regarding assigning designated local accounts for services which have exposed external ports. Can you please be more specific on what rights I need to grant to this service account so that it can be used for the PRTG Core Service Account?

Created on Jan 16, 2017 2:52:38 PM by  Aaron (60) 1



Votes:

0

Your Vote:

Up

Down

Dear Aaron

I am sorry, we don't have a list specifying all those rights. We develop for and test PRTG to be run with the local system account.

Created on Jan 16, 2017 5:00:38 PM by  Arne Seifert [Paessler Support]



Votes:

1

Your Vote:

Up

Down

This is not an acceptable answer. Running a service or application in the security context of the LSA gives the service almost unlimited privileges on a Windows system. The LSA’s powers are comparable to those of the root account on UNIX systems. If the PRTG installation were to be compromised, then the entire server would then be compromised. Do you really find this to be acceptable security design?

Created on Jan 16, 2017 5:35:23 PM by  Aaron (60) 1



Votes:

0

Your Vote:

Up

Down

Dear Aaron

PRTG uses the local system account for both the probe and the core service because it needs a wide range of access rights. PRTG needs to be able to open ports below 1024, access the registry, the file system, Windows API, WMI and so on. As long as PRTG has enough rights to function, it could also be misused if compromised.

A computer running PRTG should be physically protected from unauthorized access, see our note here:

We assume that all computers on which the PRTG core server with its local probe or any remote probes run are secure. It is every administrator's responsibility to make sure that only authorized persons can access these machines. For this reason we highly recommend that you use dedicated machines for your PRTG system parts.

Created on Jan 18, 2017 5:22:29 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Please consider the following common scenario:

1 remote PRTG server and 5 locations each with a PRTG probe on site. The five on-site probes need and can safely use the LSA because they are on an internal, secured private network. However they have a need to report back to the remote PRTG server. The PRTG server is necessarily remote because if it is on-premise and the internet circuit there goes down, there is no way for the PRTG to do alerting. Therefore a remote PRTG server is necessarily part of good design.

Considering this requirement, a remote PRTG server will then require firewall ports to be opened both for the probes to deliver data AND for the Enterprise Console / iPhone apps to view the status of the probes. Yes, the PRTG server is physically secured and yes the firewall source port can be restricted to the probe IP addresses. That is not a concern. But the firewall source port cannot be similarly restricted for iPhone / Enterprise Console apps connecting via HTTP/S because users of these systems are necessarily and always mobile.

So what is required here is that a web server is ALWAYS up and running for remote access and monitoring, but this web host is running under the Local System Account (LSA). No IT professional, anywhere, ever would find the practice of running a web server under a fully privileged account like LSA. But it is necessarily a requirement due to how PRTG has implemented remote iPhone/Console access to PRTG via HTTP/S. This is an ENORMOUS security risk that is wildly outside of what is considered best practice by any security conscious IT professional. Why do you find this to be acceptable? Considering that the PRTG core often holds many credentials to access remote systems, this particular use of LSA for an HTTP/S web server seems especially egregious and dangerous.

I do not find any of your replies thus far to be reasonable or acceptable responses. Please consult with your security team about this seemingly overlooked vulnerability in the PRTG design.

Created on Jan 18, 2017 5:45:33 PM by  Aaron (60) 1



Votes:

0

Your Vote:

Up

Down

Dear Aaron

As the core server / web server is operated by the same service, it does need the local system account. If you need additional security, please use a proxy server for the access, or a VPN. Right now, these are the only options.

Created on Jan 19, 2017 3:38:01 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Will PRTG be splitting off the web server and core server into two separate service accounts in the future? I understand if the core needs to run under the LSA, but any and all web servers should never run as LSA.

Created on Jan 19, 2017 5:16:30 PM by  Aaron (60) 1



Votes:

0

Your Vote:

Up

Down

Dear Aaron

A separate web server would have many advantages. In the foreseeable future, the webserver is operated by the PRTG coreservice. We don't want to talk about our road map as it could create expectations when an improvement is available.

Created on Jan 20, 2017 3:37:36 PM by  Arne Seifert [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.