Last update: 02. April 2025
___
When using JEA with virtual accounts, WinRM configuration is changed for security reasons. Sometimes, it may happen that WinRM service reverts to default on some devices, subsequently breaking the capability to access the device with the present JEA configuration. This is due to the “Network Service” lacking the required seTcbPrivilege permissions.
As there is little documentation concerning the relation between WinRM and JEA, we had to do some deep dive to get to the core of this issue and want to share our insights.
Default configuration for WinRM Service on both Windows Client and Server
The following tables show only an excerpt reduced to the relevant parameters for this article.
Default configuration for WinRM Service on both Windows Client and Server
|
Security context |
Network Service |
|
Service type |
Shared Process |
|
Required privileges* |
SeAssignPrimaryTokenPrivilege (‘Assign Primary Token’) |
* Required privileges is not to be mistaken for held privileges. WinRM Service checks if the account specified as security context holds the necessary privileges. Otherwise it will not start.
Actual WinRM configuration on our clients
|
Security context |
Local System |
|
Service type |
Own Process |
|
Required privileges |
SeAssignPrimaryTokenPrivilege (‘Assign Primary Token’) SeTcbPrivilege (‘Act as part of the operating system’) |
Problem
Periodically we see clients, we cannot reach via WinRM, anymore, producing below error message:
New-PSSession : [localhost] Connecting to remote server localhost failed with the following error message:
The WS-Management service cannot process the operation. An attempt to create a virtual account failed.
Ensure that WinRM service is running as Local System and that it has TCB privilege enabled. For more information, see the about_Remote_Troubleshooting Help topic.
See also screenshot below:
Screenshots of the services console show an interesting change.
Before Windows update we have the following situation:
Afterwards it changed:
Obviously the major Windows update reverts WinRM security context back to default. And the network service account obviously is missing the „SeTcbPrivilege“. This in turn prevents JEA being used with virtual accounts.
Solution: Reregister your SessionConfiguration
There really is only one proper solution to this topic if you rely on using JEA with virtual accounts:
Unregister-PSSessionConfiguration -Name “MyJeaSession”
Afterwards register your JEA Configuration again, like you normally would.
Register-PSSessionConfiguration will now take care of the necessary changes to the WinRM Service and everything will work again, like it did before.
Conclusion
While running WinRM in the context of Network Service offers less attack surface than it being configured to run as Local System, the change to the Service type isolates the service to run in its own dedicated process and thus reduces attack surface again.
This is basically the trade-in for using virtual accounts. However, given the fact that the capabilities of the user can be limited to the minimum, this allows to mitigate the risk.