Virtual Service Accounts

Version 11.4.3 (build 11.4.3235) and Version 12.0.0 (build 12.0.1016)

Usage of virtual service accounts was completely removed from the application control service. As part of that change, ArelliaACSvc.exe is now running as NT AUTHORITY\SYSTEM instead of as a virtual service account.

Version 11.4.2

Starting with version 11.4.2, the Thycotic Application Control service (ACS), running the program ArelliaACSvc.exe, is configured to run using a virtual service account named NT SERVICE\ArelliaACSvc instead of the built-in NT AUTHORITY\SYSTEM (LocalSystem) account.

Before upgrading to version 11.4.2 or newer from version 11.4.1 & older, review this information completely and ensure that your runtime environment complies with the stated requirements. Failing to do so will result in the application control service failing to function properly.

Note that virtual service accounts really are "virtual," in that there isn't a user account being provisioned on the computer, and there is no associated password that needs to be managed. Virtual accounts were first introduced in Windows 7 SP1, and they exist to allow specific sets of privileges and rights to be granted to specific native NT services in a fine-grained tightly-controlled manner.

Starting with Windows 8.1, it became possible to run the LSASS.EXE system process as PPL (Protected Process Light). This process is responsible for authenticating credentials, creating logon sessions and storing password hashes that are used to perform remote authentication when accessing file shares on remote servers. Microsoft introduced this capability to reduce the attack surface of Windows by preventing credential-theft attacks from succeeding when performed against the LSASS.EXE system process.

Initially, this capability was optional and disabled by default, although it could be enabled via the registry. Later, Microsoft increased the security of the LSASS.EXE system process again by allowing the enablement of LSASS.EXE running as PPL to be controlled via an UEFI variable and for the setting to be protected by the Secure Boot mechanism.

With Windows 11 22H2, LSASS.EXE running as PPL is enabled by default on all new installations (e.g., not upgraded from a prior build of Windows 11 or an older version of Windows). It is expected that Microsoft will continue to increase the security of the LSASS.EXE system process in future builds of Windows 11 as well as in whatever new version of Windows ends up being delivered as a successor to Windows 11.

Prior to version 11.4.2, all versions of the agent were entirely dependent on being able to obtain a copy of the process access token of the LSASS.EXE system process for the Thycotic Application Control service to be able to run properly. When the LSASS.EXE system process runs as PPL, it is no longer possible for the process token to be accessed by any other process running on the system, including services running as NT AUTHORITY\SYSTEM. The reason for the token copying to be performed had to do with the level of privilege required to perform token elevation operations. The Windows SCM (Service Control Manager), running in the SERVICES.EXE system process, has less privileges than the LSASS.EXE system process. It is not possible for the SCM to create a native NT service process running as NT AUTHORITY\SYSTEM that runs with more privileges than itself, even though the SCM itself runs as NT AUTHORITY\SYSTEM, too. The SCM can also start a service running under either the NT AUTHORITY\NETWORK SERVICE or NT AUTHORITY\LOCAL SERVICE accounts, too, but both of those accounts have less privileges than the SCM’s own process which runs as NT AUTHORITY\SYSTEM.

The intersection of those limitations of the SCM and native NT services running as NT AUTHORITY\SYSTEM and the LSASS.EXE system process running as PPL made it necessary to make a change in how the Thycotic Application Control service (ACS) is configured, along with corresponding code changes, and is the reason for usage of a virtual service account to be adopted. When the SCM starts a native NT service process running as a virtual service account, the LSA privileges assigned directly to the virtual service account as well as any privileges assigned to local groups in which it has membership are all included in the service process’s access token. This permits a native NT service to be started such that it runs with greater privileges than the SCM runs with. When the virtual service account NT SERVICE\ArelliaACSvc is properly configured with the LSA privileges and logon rights that are required, it can start up and run properly with the capability of performing token elevation operations.

Under no circumstances should manual modifications be made to the Thycotic Application Control service’s configuration. The service is created and configured by the agent installer. After installation, any manual modification of the service configuration has the potential to break the service and necessitate an uninstall and reinstall of the agent to repair the service. The Thycotic Application Control service (ACS) is now configured to fail to start if the virtual service account NT SERVICE\ArelliaACSvc is lacking any of the required LSA privileges and/or logon rights.

Other agent-related services, such as the core agent service Thycotic Agent, are still configured to run as NT AUTHORITY\SYSTEM, as are all agent-related scheduled tasks running under the Windows Task Scheduler; all of them are completely unaffected by the virtual service account configuration requirements.

The following LSA privileges are granted to the virtual service account NT SERVICE\ArelliaACSvc by the installer:

  • Act as part of the operating system

  • Adjust memory quotas for a process

  • Backup files and directories

  • Bypass traverse checking

  • Create a token object

  • Create global objects

  • Create permanent shared objects

  • Create symbolic links

  • Debug programs

  • Impersonate a client after authentication

  • Increase a process working set

  • Increase scheduling priority

  • Load and unload device drivers

  • Manage auditing and security log

  • Obtain an impersonation token for another user in the same session

  • Perform volume maintenance tasks

  • Profile single process

  • Profile system performance

  • Restore files and directories

  • Take ownership of files or other objects

Every one of these LSA privileges are required and are essential to the proper operation of the Thycotic Application Control service (ArelliaACSvc.exe) now and in the future. If any of them are not granted to the virtual service account, the service will not start.

Additionally, the LSA logon right Log on as a service is required. On a new installation of Windows, the built-in group NT SERVICE\ALL SERVICES is granted Log on as a service, and all virtual service accounts automatically have membership in that group. This permits services configured to use a virtual service account to log on in service mode as the service is started. However, there are various security lock down or “hardening” recommendations that are frequently implemented which require that the Log on as a service logon right be revoked from NT SERVICE\ALL SERVICES and results in each virtual service account having to be explicitly granted the Log on as a service logon right.

It is very common for GPOs (Group Policy Objects) to be utilized in an enterprise Active Directory environment to push out security settings to endpoint computers where the agent gets installed. If one or more GPOs result in required LSA privileges and/or logon rights being revoked from the Thycotic Application Control service (ACS), then the service will fail to start. It will be necessary to modify one or more GPOs to make them comply with the virtual service account configuration requirements. One of the most common issues which occurs with trying to configure a GPO to meet these requirements is the inability to validate the virtual service account name NT SERVICE\ArelliaACSvc. If the agent is not currently installed on the computer where GPEDIT.MSC is being used to modify the GPO, then the service does not exist in the SCM’s configuration, and the virtual service account name cannot be resolved to a SID and thus is not able to be validated. One simple workaround for this issue is to create a dummy service named ArelliaACSvc on the computer where GPEDIT.MSC is being used, then modify the GPO, save the GPO, and finally, delete the dummy service.

The following commands can be used from an elevated CMD.EXE console window:

sc create ArelliaACSvc type= own start= demand binPath= C:\Windows\System32\nosuch.exe

sc sidtype ArelliaACSvc unrestricted

<In the GPO, add the "NT SERVICE\ArelliaACSvc" to the LSA privilege & logon right policy settings as described above>

sc delete ArelliaACSvc