by Limor Wainstein

When deploying Citrix Virtual Apps and Desktops within enterprises and governmental institutions, there are security standards you may need to comply. Unauthorized access to confidential data and data breach can happen if proper security measures are not in place. In this post, we’ll go through some of the top security practices that with keeping your virtual environment secure. We’ll also compare some aspects of Citrix security with other enterprise-ready VDI platforms. Let’s get started.

Managing User Privileges

Users should be granted only the access capabilities they require. When it comes to Microsoft Windows, access privileges are applied to desktops as follows–rights are configured via User Rights Assignment, and group memberships are controlled via Group Policy.Amazon Workspaces which is another popular VDI platform lets you assign only one workspace to a single user for security reasonswhich is something that you could consider your XenDesktop.

The main benefit of this release it is now possible to desktop administrative rights to a user without needing to grant physical control over the computer which stores the desktop.

When you’re planning desktop privileges, it is important to note:

1. When users without privileged access connect to a desktop, they see the time zone of the system running the desktop instead of their time zone by default. To allow users to view their local time instead of the system time zone, refer to Change basic settings.
2. A desktop administrator has complete control over the desktop. In case the desktop is a pooled desktop, as against a dedicated desktop, the administrator should be a trusted user in respect of all other users of that desktop. This includes future users. Users need to know of the potential data security risk posed by this setup.
3. A desktop administrator can install software, including potentially malicious software on that desktop. Administrators can also monitor and control network traffic interacting with the desktop in question.

There can be situations where some applications need to have desktop privileges even though there are intended for users and not administrators. In cases like this, users need to be made aware of potential security risks.

These applications need to be viewed as highly sensitive. The following approaches can help mitigate security risks:

• Enable two-factor authentication while disabling single sign-on mechanisms for these applications
• Enforce policies around contextual access
• Limit the application to a dedicated desktop only. In case the application needs to be published to a shared hosted desktop, other applications should not be executed on that desktop
• Desktop privileges should only be applied to a specific desktop, and should not include other computers
• Session Recording for the application should be enabled. It is a good practice to also allow similar security logging tools in the application and within Windows itself.
• XenApp and XenDesktop should be configured to limit the features used with the application
• All security features of the application should be enabled. These need to be limited to strictly the users’ requirements strictly.
• Have a plan in place that reconfigures, upgrades, or replaces the application so that desktop privileges are not required in future

Manage Login Rights

Login rights are essential for user and computer accounts. Similar to privileges related to Microsoft Windows, login rights are also applied to desktops in the usual way, i.e. (i) login rights configured via User Rights Assignment and, (ii) group memberships via Group Policy. 

Based on current security trends, it might be a good idea to incorporate a combination of digital signatures and Multi-Factor Authentication (MFA) into your user’s login workflow. Amazon Workspace and RDP recommend enabling at least one security precaution to avoid undesirable consequences. 

Windows logon rights include:

1. Logon locally
2. Logon over the network (access this computer from the network)
3. Logon via Remote Desktop Services
4. Logon as a service, and
5. Logon as a batch job

When it comes to computer accounts, computers should only be granted login rights they require. The “Access, this computer from the network” logon right, is required when:

1. For computer accounts of Delivery Controllers at VDAs
2. For the computer accounts of VDAs at Delivery Controllers.
3. For computer accounts of other servers in the same StoreFront server group of StoreFront Servers

When it comes to user accounts, only the necessary login rights should be granted for user accounts. 

By default, Microsoft grants the login right ‘Allow log on through Remote Desktop Services’ to group Remote Desktop Services. This excludes domain controllers.

In case your organization policy states that this group needs to be removed from this logon right, you can consider the following: 

1. The Virtual Delivery Agent (VDA) for Server OS utilizes Microsoft Remote Desktop Services.  Users can customize the Remote Desktop Users group as a restricted group. This controls group membership through Active Directory group policies. 
2. For other components of XenDesktop and XenApp, including the VDA for Desktop OS, the group Remote Desktop Users is not required. Therefore, the group Remote Desktop Users doesn’t need the logon right “Allow logon through Remote Desktop Services.”

If these computers are administered via Remote Desktop Services, you need to ensure that each administrator is included as a member of the Administrators group. If these computers are not administered via Remote Desktop Services, you may consider disabling Remote Desktop Services on these computers.

While organizations can add groups and users to the login right ‘Deny logon through Remote Desktop Services,’ it is not usually a recommended solution. 

Maintain a Disaster Recovery Plan

A disaster recovery plan (DRP) is a document with instructions on how to respond to unplanned incidents when a disaster strikes. Building a DRP is like buying an insurance. It’s something you can’t avoid if you’re an enterprise. The ideal situation would be to create two sites where one is active and the other one is fully capable of replacing the other one when a disaster strikes. 

Citrix XenApp or XenDesktop does not provide any out-of-the-box disaster recovery capabilities. You can instead choose a cloud-based solution like Azure Site Recovery which is Microsoft’s Disaster Recovery as a Service (DRaaS) solution. It provides replication, failover and recovery of virtual machines which exactly fits XenApp requirements. You might also find Amazon’s Disaster Recovery useful to consistently replicate, protect, and failover virtual machines to secondary site or to AWS. Apart from that, you can also try AWS disaster recovery options offered by third-party vendors like N2WS, Cloudendure etc. that might meet your requirements. 

Configure Service Settings

The Delivery Controller Windows services are configured to log in as NETWORK SERVICE identity. These service settings shouldn’t be modified. However, this does not apply to the Citrix Storefront Privileged Administration service or the Citrix Telemetry Service.

The Citrix Storefront Privileged Administration service is built to log in to Local System (NT AUTHORITY\SYSTEM). This is essential for Delivery Controller StoreFront operations which are not generally available to services. It is best not to alter these service settings. 

Similarly, the Citrix Telemetry Service is set up to log in as its own service-specific identity. Organizations can disable the Citrix Telemetry Service if needed. However, service besides this, and those already disabled, other Delivery Controller Windows services should not be disabled.

Configure Registry Settings

Enabling the creation of 8.3 folders and file names on a VDA file system is no longer a necessity. Users can configure the registry key NtfsDisable8dot3NameCreation to disable the creation of 8.3 folders and file names. Users can also complete this configuration by way of the fsutil.exe behavior set disable8dot3 command.

Deployment Scenario Security Implications

A user’s environment may include unmanaged user devices installed by the organization but under complete control of the user, or devices that are administered and managed by the organization. Each of the two environments has different security considerations as detailed below –

Managed User Devices

Managed user devices are either under (i) a user’s control, or (ii) the control of a trusted organization. These devices can be configured and supplied directly to users, or terminals may be provided which runs a single desktop in full-screen-only mode.

You can follow the best practices described above for managed user devices. This is advantageous as minimal software is required on a user device.

To configure a managed user device in window mode or full-screen-only mode, you can follow the steps below:

• Full-screen-only – Users can log in using the usual Login To Windows screen. The same user credentials can be used to log in automatically.
• User Device in Window Mode – Users need to first login to the user device, followed on by logging on to this release through a website supplied with the version.

Unmanaged User Devices

Unmanaged user devices that are neither administered nor managed by a trusted organization should not be assumed to be under administrative control. An organization may permit its users to configure their own devices, but the risk is that users may not follow general security best practices as described earlier.

The advantage here lies in the possibility to deliver secure desktops to unmanaged user devices. These devices should still have antivirus protection to defeat input attacks like a keylogger, etc.

Data storage considerations

By using this release, organizations can prevent users from storing data on user devices that are under the user’s physical control. That said, organizations still need to consider the implications of users storing data on desktops. It is generally not a good practice for users to store data on desktops. Data should instead be stored on database servers, file servers or other repositories that can be appropriately protected.

Mixed-version environments

Mixed-version environments are the inevitable product of certain upgrades. Organizations need to adhere to the best-practice and limit the time that different versions of Citrix components co-exist. In mixed-version environments, the security policy may not always be uniformly enforced.