When RES Workspace Manger 2012 is installed unattended and configured to connect to a Relay Server, and User Account Control (UAC) is enabled, the configuration is not stored. As a result the agent is unmanaged.
After extensive testing I found the solution to solve this issue.
PS: This applies for both SR2 and SR3 (release notes).
User Account Control (UAC)
When UAC is enabled (introduced since Windows Vista) a user has a token with only basic privileges, administrative privileges are filtered (removed). The administrative privileges are only available when a process is ran with elevated permissions. The user needs to confirm to run the process in elevated mode (and specify credentials) in a UAC prompt.
In the environment where I’m setting up RES Workspace Manager UAC is enabled with the default policy (notify only when programs try to make changes to the computer).
Windows Installer
Windows Installer is used to install RES Workspace Manager Agent (.msi extension). The user interface that’s shown to the user (of hidden when running unattended) runs in the users context with a filtered token (without administrative privileges). Since the installation makes changes to the computer, elevation is required and the user is prompted by UAC.
In a verbose log you’ll see the following line
MSI (s) (B0:04) [13:54:53:463]: MSI_LUA: Elevation required to install product, will prompt for credentials
followed by the following lines after the user confirmed.
MSI (s) (B0:04) [13:54:55:865]: MSI_LUA: Credential Request return = 0x0 MSI (s) (B0:04) [13:54:55:865]: MSI_LUA: Elevated credential consent provided. Install will run elevated
Custom Actions
Custom Actions are used in Windows Installer to launch executables that are on the local machine or installed by the installation. A Custom Action named ‘res.exe’ is used to configure the RES service with the specified datastore connection.
In a verbose log you’ll see the following line
MSI (s) (B0:04) [13:55:04:446]: Executing op: ActionStart(Name=res.exe,,) MSI (s) (B0:04) [13:55:04:446]: Executing op: CustomActionSchedule(Action=res.exe,ActionType=1618,Source=C:\Program Files\RES Software\Workspace Manager\svc\res.exe,Target=/msiparms=3||{18E874CB-DCEE-49F9-9EE4-D9133C58927D}||********||||NO||SAHPSXD6554;SAHPSXD6555;SAHPSXD6854;SAHPSXD6855||||YES||Hosted Private Machines||no||||||||||||||||||||,)
In the example above a list of Relay Servers is specified including the GUID and encryption password (********). However, as said in the introduction the configuration is not applied to the RES Workspace Manager service.
Impersonating the invoking user
By default Custom Actions impersonate the invoking user (having a filtered token, without administrative privileges). As a result a machine-state changing task can fail, which indeed is the case for the datastore configuration. The default behavior of a Custom Action can be changed using value in the ‘Type’ field. When the msidbCustomActionTypeNoImpersonate option flag is set the user is not impersonated, the action is executed by the user with elevated privileges (a non-filtered token).
To prove this theory I added two Custom Actions that call whoami to read the users privileges.
The result of the two custom actions clearly show the difference in the privileges of the user:
WhoAmI_default
Privilege Name Description State ============================= ==================================== ======== SeShutdownPrivilege Shut down the system Enabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled
WhoAmI_noimpersonate
Privilege Name Description State =============================== ========================================= ======== SeAssignPrimaryTokenPrivilege Replace a process level token Disabled SeLockMemoryPrivilege Lock pages in memory Enabled SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled SeTcbPrivilege Act as part of the operating system Enabled SeSecurityPrivilege Manage auditing and security log Enabled SeTakeOwnershipPrivilege Take ownership of files or other objects Disabled SeLoadDriverPrivilege Load and unload device drivers Disabled SeProfileSingleProcessPrivilege Profile single process Enabled SeIncreaseBasePriorityPrivilege Increase scheduling priority Enabled SeCreatePagefilePrivilege Create a pagefile Enabled SeCreatePermanentPrivilege Create permanent shared objects Enabled SeRestorePrivilege Restore files and directories Disabled SeShutdownPrivilege Shut down the system Disabled SeAuditPrivilege Generate security audits Enabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeImpersonatePrivilege Impersonate a client after authentication Enabled SeCreateGlobalPrivilege Create global objects Enabled
Patch RES Workspace Manager installation file
In the installation file provided by RES Software the option flag set for the Custom Action ‘res.exe’ is set to 1618 decimal (or 0x652). To enable the NoImpersonate option flag we need to add 2048 (or 0x800) resulting in 3666.
Now if the Custom Action ‘res.exe’ is executed (and UAC is enabled) the task is executed by the user with elevated permissions and changes can be made to the system.
Instead of changing the original MSI file you can also create a transform file (MST). You can download the transform file for the Workspace Manager 2012 SR3 agent here: RES-WM-2012-Agent-SR3.mst . Thanks to Remko Weijnen for the tip!
Configure Connection
After the MSI file was “patched” and executed the datastore configuration was applied successfully. The datastore configuration can be shown (and changed) by executing the following command line:
%ProgramFiles%\RES Software\Workspace Manager\svc\res.exe /config
.
A great article Ingmar, and thanks for bringing this to our attention!
We will take a look, and see if we can’t do something about it. It’s not right that we should expect you guys to patch an installer to get it doing what you need it to do!
Cheers, and keep up the good work. It is community contribution like this that make RES Software who we are!
Grant
Thanks for the kind words Grant, keep up the good work at RES!
I just got confirmed that this bug will be fixed in SR4 (expected to be released in Week 39/2013).
If you can’t wait for this release, or need to deploy SR3, you can use the provided solution from this article.
#262227#