Further improvements to OneAgent security for Windows and Linux

We're happy to announce that with the releases of  OneAgent version 1.191 and version 1.193, we'll be further improving the security of OneAgent installation and monitoring.

If you’ve watched the evolution of OneAgent closely in our release notes and blog posts, you’ll know that we’re highly focused on security. Because OneAgent operates on your critical hosts where the services that comprise your business applications are located, Dynatrace must ensure the highest possible security in monitoring the operating systems and services that run on these hosts.

Non-privileged mode will be the default for OneAgent on Linux

Starting with OneAgent 1.193, all new installations on supported Linux platforms will be performed with non-privileged mode enabled.

Non-privileged mode is one of the ways that OneAgent can be deployed and run. It leverages Linux kernel system capabilities. This mode of deployment and operation is designed to fall back to elevated privileges when older versions of the Linux kernel are detected, so you don’t have to worry about the potential failure of such a deployment. This means that we will deploy OneAgent in the most secure mode available, while also ensuring correct operation in instances where kernel requirements aren’t met.

For details on how you can manage privileged versus non-privileged modes for OneAgent deployment, see customizing installation parameters.

Note: The option to install OneAgent in non-privileged mode has been GA since OneAgent version 1.175.

Since its original release, we’ve improved this solution further. In adherence to our philosophy of automating all good decisions and promoting good practices for our customers, and because it’s clear that many customers are unaware of the value of this option, we’ve decided to set it as the default.

Why are we announcing this change ahead of time?

We’re convinced that the majority of our customers will want to go with the new defaults. However, if you’re are not convinced about the default implementation of non-privileged mode for all new deployments of OneAgent, you can still opt out.

Local user account not required for OneAgent for Windows

When we released non-privileged mode for Linux, many of you asked, “What about Windows?”

So we sat down with seasoned Windows administrators and asked them about security concerns related to the creation of a local account for running OneAgent processes on Windows. As a result of these conversations, we realized that the path towards security doesn’t require limiting the permissions of the local account (as is the case for Linux kernel system capabilities), but rather it requires the complete removal of the local account.

As with non-privileged mode, the Windows solution will be rolled out in several stages. Starting with OneAgent 1.191, the USER parameter of the OneAgent installer will accept the following values:

• dtuser: This parameter instructs the OneAgent installer to create a local user account for user “dtuser”. This parameter value has been supported since before the OneAgent 1.191 release.
• no_create: This parameter has been available since OneAgent version 1.145, released in June 2018. It disables the creation of the local user account for OneAgent, but effectively disables the extension (previously known as a “plugin”) module and all the extensions at the same time. The remaining OneAgent modules—monitoring of operating system resources, detection of processes, monitoring of the network, automatic injection of deep code monitoring modules, and all the capabilities of the deep code modules for collecting data and performing PurePath monitoring—are unaffected by this parameter. The no_create parameter value was used as a temporary workaround for those customers who needed full-stack OneAgent code to be operational but were concerned about the security aspects of creating a local user account.
• LocalSystem: This parameter value makes OneAgent leverage the LocalSystem system account. When used, this account makes the OneAgent extension module run with LocalSystem permissions. Effectively, no local user account is created because LocalSystem is a built-in system account provided directly by Windows. As a result, all OneAgent modules, including all extensions, are fully functional. This is the recommended setting to use for all OneAgent Windows installations starting with OneAgent version 1.191.
• LocalService: This parameter makes OneAgent leverage the LocalService system account. While this reduced set of privileges is enough for most of the extensions to operate, there are some that won’t be able to produce data effectively (namely, extensions that collect Performance Monitor counters). If you’re unsure about which extensions you might use, it’s best to use the LocalSystem  parameter value instead.

As a result of this change, you can roll out OneAgent on Windows, including the extension module, without the need to create a local user account.

Update for OneAgent version 1.195: Going forward, the default setting for the USER parameter is LocalSystem. Consequently if this parameter isn’t provided to the installer, OneAgent will run under the LocalSystem account.

What’s next?

Going forward, we’re considering further improvements to OneAgent security. Our goal is to make sure that the ongoing deployment and execution of OneAgent on Windows is as automatic and safe as possible. It’s likely that we’ll remove the USER parameter completely and make the use of the LocalService and/or LocalSystem accounts for the extension module.

Until then, we strongly encourage you to deploy OneAgent on Windows using the USER=LocalSystem parameter.

As always, we welcome your feedback and comments. Please share your thoughts via Dynatrace Community, or from within the Dynatrace web UI—just start a chat with a Dynatrace ONE representative. We’d love to hear from you.