Symptoms

When connecting to a published desktop group, users are not able to administer their desktop.

Cause

This is by design. Pooled workstations share a single image and this means that each end user would need to be a local administrator on every workstation in the pool, which would allow users to interfere with other users' workstations.

For a number of reasons, including application compatibility, end users may need to be granted local administration privileges over workstations that they connect to. This has many security-related implications. In particular, if pooled workstations are used, then end users will be connected to an arbitrary workstation in a pool. In order for the end user to have administrative privilege, they would have to be a member of the Local Administrators group on a workstation.

Resolution

Two options are available to securely provide end users with administrative rights on a pooled desktop without giving them rights on all desktops in the group.

Option 1: Use NT-AUTHORITY\Interactive

This option relies on OS mechanisms. In this solution, the XenDesktop administrator would set up the golden workstation image as follows:

1. Make the in-built NT-AUTHORITY\Interactive account a member of the Local Administrators group.

2. Restrict logon rights for RDP connections as appropriate (Local Administrators only; potentially add the user group that the workstation image is published to, if they should be able to gain access through RDP), using the Remote Desktop Users group.

3. Restrict console logon rights as appropriate (same as for RDP connections), using the Log on Interactively policy.

The above steps could be carried out through a combination of group policy settings using Active Directory restricted groups changes to the golden image itself. This solution would affect log ons at the console of the virtual machine and could affect applications that use a LogonUser call.

Option 2: Manipulate Local Administrators Group

An alternative solution would be for XenDesktop to manipulate the Local Administrators group directly, adding user accounts to this group as appropriate.

This solution works as follows:

1. When creating a workstation group, the administrator defines whether end users should be granted local administrator rights on their workstation. This setting only applies to pooled and assign-on-first-use workstation groups.

2. All normal workstation and brokering operations are unchanged, except as follows:

The response to a iTicketing. Validate() request will include a new setting that determines whether the user should be granted local administration rights. The workstations issue this request after receiving an ICA connection from the end user, but before the end user is logged on to the workstation. Currently, the request includes the NFuse ticket received by the ICA client, along with other information, and the server’s response includes the user’s credentials, and the policy settings that should apply to the session. The server determines whether the workstation was published through a desktop that was marked in step 1. above, and if so, indicates this fact to the workstation.

3. The workstation agent passes this information on to the VDA (ICA Service) along with policy settings and the user’s credentials.

4. The ICA Service adds the user’s account to the Local Administrators group before logging on the user.

Note that there is no equivalent functionality to explicitly remove the user’s account from the Local Administrators group. Instead, it would be the XenDesktop administrator’s responsibility to re-image a workstation after it was used by a user with local administration rights.