VMware Horizon Community
Lieven
Hot Shot
Hot Shot

Writable Volumes and Local Administrator rights

When using Writable Volumes in combination with User Installed Applications, the end-users must have local administrator privileges on Target Computers to install such applications.

In a VMware Horizon View linked clone environment, how can I dynamically add a user to the local administrators group before the logon process starts?

Reply
0 Kudos
11 Replies
Ray_handels
Virtuoso
Virtuoso

You mean the actual user logging in?

We eventually decided to create a group were all admin users are placed in, then use User Rights Assignment GPO to add this group to the administrators.

And to prevent the administrative user to "hack" into another computer we closed all unnesecary ports on all other VM's in the VLAN. Also make sure to set the policy for the firewall so that a user can't change it, even if he is an administrator.

Because there is no way of knowing what user logs onto which machine there is no way of adding the user to the local admins group before login.

Adding afterwards is useless because permissions will only be applied after relog (which will cause the machine to refresh)  but my guess is you already kewn that Smiley Happy Smiley Happy.

Reply
0 Kudos
Lieven
Hot Shot
Hot Shot

Yes, I mean the actual user logging in.

We also use an AD group where all admin users are placed in and use the restricted groups GPO to add this AD group to the local administrators group.

That in itself of course works well, but it is a security risk because everybody that is a member of this AD group (i.e. everybody who can use a writable disk) will then be an administrator on all VDIs.

We could limit this security risk this by using the startup.bat in the writable volume to add this AD group to teh local administrators group, but this woudl mean that the user woudl still have access to all VDIs that have writable volumes attached to it.

Closing ports is a good idea, but it's not always that easy to implement in an organization. The question is also which ports need to be closed exactly and what can be the negative impact of this on other applications and existing ways of working.

I was looking into the svservice.log file that the Appvolume Agent writes in to, and I think the username is logged in this file before the writable volume is attached, so therefore also before the user is logged on. If I can extract that username, I can then use this in the startup.bat script on the writable template and launch a command to add that username to the local administrators group of that particular VDI only.

I still need to verify and test this out!

It's a pitty that VMware does not give any guidance on how to best solve this. They only say that the user has to be admin of the VDI. It would be good to get some guidance from the VMware App Volumes specialists on how to handle this.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

It's a pitty that VMware does not give any guidance on how to best solve this. They only say that the user has to be admin of the VDI. It would be good to get some guidance from the VMware App Volumes specialists on how to handle this.


Couldn't agree more with you. It would be very nice if someone could help us clear out if it is indeed possible to change this or use any kind of batch file or script to add it.

If you find a solution I would love to know how you did it. The thing is that when attaching the writable volume the user is allready logging in (for as far as I'm aware) because Appvolumes sends the reconfigure command to the virtual machine while logging in, not before logging in. You allready pressed CTRL + Alt + DEL before Appvolumes starts reconfiguring. Regarding ports, we only use the ports that need to be used for VMWare itself. There is no virusscanning agent on the machine and no need for remote management ports.. So were pretty clear on that one but I do agree with you that it isn't the best off all options.


I'm not 100% sure how Windows copes with users being added to the administrators group during logon. My guess would be that it would require a relog of that specific user due to security regulations. When adding a user through GPO's it also requires the policy to be fully applied before logging in, otherwise permissions will not be effective.


Still, these are the discussions I would love to have with the people who actually know what happens exactly.. We are just guessing away here and making a buttload of assumptions Smiley Happy


Also (just as a sidenote). It is not required to have administrative priviliges to use the writable volume (we tested this). It is only required to actually install applications in the writable volume (which off course is the entire reason you are using the writable volume so yeah duhhh.. Smiley Happy)

Reply
0 Kudos
ErickBUSC
Contributor
Contributor

You may want to take a look at the Reg keys from pages 39-40 of the User Guide:

https://www.vmware.com/pdf/app-volumes-29-users-guide.pdf

There is one key that might help you out (at least in regards to the writable volumes being attached after logon).

I just discovered it and haven't fully tested it but I thought I'd pass it on.

Key:

HKLM\SYSTEM\CurrentControlSet\services\svservice\Parameters\    -  (REG_DWORD) WaitForFirstVolumeOnly = 0

Description from guide:

"Defined in seconds, only hold logon for the first volume. Once the first volume is complete, the rest will be handled in the background, and the logon process is allowed to proceed. To wait for all volumes to load before releasing the logon process set this value to 0. If undefined, default is 1"

EDIT:

I'd like to add that I have also used the reg key from this post (also shown in the User Guide). Both reg keys seem to help with my profile problems. Although waiting for volumes to attach might increase logon times, at least -in theory- the user has a profile that is not broken.

Writable Volumes Troubleshooting

Disclaimer: I am currently only piloting a handful of VMs and working out the bugs with App Volumes before I go large scale so I don't have any idea on how this will affect performance in the long term. I've used other layering technologies for the past few years so I can at least spot the typical problems.

Reply
0 Kudos
auhank
Enthusiast
Enthusiast

Possibly disabling AllowDirectRDP (group policy from VMware View) is acceptable in some environments. I'm uncertain if this works with callers on Sun Ray, still of interest on our site.

Reply
0 Kudos
Lieven
Hot Shot
Hot Shot

‌we are using the "WaitForFirstVolumeOnly" regkey. Now it's a question of knowing the username before the actual logon starts and use that as a variable in the startup.bat file on the writable volume.

After my holidays, I will continue testing. But I'm still silently hoping for VMware to give us guidance in this.

Reply
0 Kudos
jrp1
Contributor
Contributor

I had a similar issue and resolved it by adding the built-in NT AUTHORITY\INTERACTIVE account in the Administrators group via Group Policy.  I followed instructions here: Make all users local admins on only their current computer - Spiceworks.  Any user who logs in to a non-persistent VM becomes a local admin on only that machine.

Reply
0 Kudos
Lieven
Hot Shot
Hot Shot

I have added the registry key "HKLM\SYSTEM\CurrentControlSet\services\svservice\Parameters\WaitForFirstVolumeOnly with a value of "0" to the golden imgage

I have added the built-in NT AUTHORITY\INTERACTIVE account in the Administrators group via the prestartup.bat file available in the writable template

net localgroup administrator INTERACTIVE /add

When logging on to the VDI, the writable volume is assigned, the NT AUTHORITY\INTERACTIVE account has been nicely added to the local administrators group, but the user does not have administrator rights.

So it appears to be that the logon process started before adding the NT AUTHORITY\INTERACTIVE to the administrators group.

Solving it via a group policy would mean that all users having a VDI assigned are local admins of their VDI, irrespective of the fact that they have a writable volume or not.

The only way I see how to resolve this is to built a specific VDI pool for users with a writable volume and compose the VDIs in a specific OU where we can add the NT AUTHORITY\INTERACTIVE account to the local administrators group via group policy.

However, doing this limits the flexibility a lot and means also creating additional pools.

Reply
0 Kudos
Lieven
Hot Shot
Hot Shot

I opened a Support Request with VMware for this. SR# 15749132609

Let's hope they come up with a good solution/suggestion.

Reply
0 Kudos
Lieven
Hot Shot
Hot Shot

Rasmus Jensen (Senior EUC Architect at VMware) has found a way to resolve the issue by using the VMware View Script Host Service.

The idea is the following

1. Add all users that have the right to a writable volume to an AD group

2. Before user login happens, launch a script which adds the INTERACTIVE user account to the local administrators group only if the user that will be logging in is a member if the above mentioned AD group

The above can be accomplished by using a start session scripts (More info on start session scripts on https://pubs.vmware.com/horizon-62-view/topic/com.vmware.view.integration.doc/view_integration_start...)

REQUIRED CHANGES TO THE GOLDEN IMAGE

1. Set "VMware View Script Host Service” service to “Automatic"

2. Add registry key:

Location: HKLM\SOFTWARE\VMware, Inc.\VMware VDM\ScriptEvents\StartSession

String: AddLocalAdminScript

Type: REG_SZ

Value: wscript \\server\share\AddLocalAdmin.vbs

3. Add registry key:

Location: HKLM\SOFTWARE\VMware, Inc.\VMware VDM\Agent\Configuration

String: RunScriptsOnStartSession

Type: REG_DWORD

Value: 1

4. Copy the attached script to a share (rename script to AddLocalAdmin.vbs)

NOTES:

1. Make sure everyone has read permissions to this share because the authentication request to a CIFS share is made using the SYSTEM account per default. Therefore you need to set "Everyone" to have read permissions as a minimum to that share.

2. The VMware documentation uses environment variables as examples but they don't work as they are not expanded. (i.e. %ProgramFiles%) so the path to the script needs to be an absolute path.

3. "wscript" needs to be stated in front of the path to the script. Example: wscript \\server​\share\AddLocalAdminScripts.vbs (you could also copy your script in the Golden Image itself, but the disadvantage is that each change of the script will require you to recompose your pool)

I was not able to test this out yet, but will certainly do this in the next coming days/weeks. If somebody else has the time and teh environment to test this out, I woudl be very interested to know the outcome.

Reply
0 Kudos
Erossman
Enthusiast
Enthusiast

Hi,

that script doesn't work as expected. It isn't possible to check the user group membership because during the logon task vmware cannot determine the variable "ViewClient_Broker_UserName".

I have to remove the group membership check than it will works. But this is not a good solution to get everyone in this pool local administrative permissions.

I also don't want to create a separate pool for my few "special users" or work with uem privilege elevation. Any ideas?

Reply
0 Kudos