Help CenterBefore ThreatLocker Version 6.4, if an application had Elevation enabled, the application was run under a simulated user called threatlocker_uac. Beginning in ThreatLocker Version 6.4 if a program is run with Elevation, it now runs the application under that same local user, just with elevated privileges. This means that if the user is running an application such as QuickBooks, and there are mapped drives and network shares that they need to access, when that application is Elevated, it will be Elevated under their normal user account and they will still be able to access these mapped drives and network shares. Whereas in earlier versions, when Elevated under the simulated account of threatlocker_uac, the access to these shares could have been blocked.
Take PowerShell for example. The local user, George, is not a local administrator. However, he needed to run PowerShell as an administrator. You can see in the blue 'Elevation' icon in the above policy indicating that PowerShell has Elevation enabled. When George tried to run PowerShell as an administrator, he received the following popup informing him that the application had been elevated.
When running the whoami command, you can see that the user is test1\george. Elevation is elevating his logged-in domain account which means he will still have access to his network shares. And when running the net localgroup administrators command, you can also see that George is not listed as an administrator. This demonstrates that the local domain user is still George, and he is, in fact, not a local administrator.
Before 6.4, when PowerShell was elevated, these are the results when a local user, George, was elevated. You can see that the program actually elevated under the threatlocker_uac user, not the local user.
