It’s been a long time since I’ve explored Citrix clipboard redirection….how well has it evolved?
When you are working with remote applications and desktops, often clipboard redirection is vital to have for users to be able to do their jobs. I regularly copy and paste code snippets into and out of remote applications and desktops on Citrix. But unfortunately, because there are nefarious people out there, sometimes this can be seen as a security risk. The chances of exfiltrating data by copying and pasting is, unfortunately, a significant area of data loss prevention.
I always used to take the attitude of “there are seldom technological solutions to behavioural problems”, and maintain that securing data in this way was more a problem for HR (in hiring the right people) than for I.T. (in locking all of the doors and windows). Some of this still stands up to scrutiny, obviously – a bad actor can always take a photo on his phone, write it down, even memorize it. But these days, a lot of security standpoints are to do with slowing down the ability of a bad actor to do damage, to restrict their progress deeper into your systems – mainly to remove some of the more obvious methods for stealing data or compromising devices, which therefore increases the chances of detection with less damage done.
As said earlier, I hadn’t looked at Citrix clipboard redirection for a long time, so I was pleasantly surprised that we now have a much more granular set of policies associated with the clipboard to choose from. The requirement we had was from developers who often had to copy and paste into their session but security wished them to be prevented from copying any data back out. A quick perusal of the available Citrix policies allowed me to quickly see this could easily be achieved.
Citrix policies for clipboard
First let’s have a quick run-through of the policies that we actually have available for clipboard redirection at this point in time.
Client clipboard redirection
This policy has been around for a very long time, and simply allows clipboard redirection to be done. It is turned on by default – we most commonly used to see this policy defined when we were looking to turn off the redirection.
Clipboard redirection bandwidth limit
Specifies the maximum allowed bandwidth (kbps) for data transfer between the session and the local clipboard.
Clipboard redirection bandwidth limit percent
Pretty similar to the above, and again one that has been around a while, this specifies the maximum amount of bandwidth the clipboard transfer can consume, as a percentage of the total session bandwidth.
Read-only clipboard
This is one of the newer policies (well, it came along in 7.0, so new-ish), and this gave the first control around in which direction clipboard redirection would work. This policy simply disables session-to-client redirection, and allows client-to-session redirection. However this policy no longer applies if you are on a VDA version higher than 7.5.
Restrict client clipboard write
These settings came along in 7.6, and this one simply works the same as the previous setting – it disables session-to-client (writing to the client), and enables client-to-session (writing to the session). However this policy can be extended by using another policy (Client clipboard write allowed formats), whereas the previous policy can not – and anyway, the previous policy only applies to 7.5 or lower VDAs.
Restrict session clipboard write
Again from 7.6 onwards, this is the flip side of the previous setting and allows you to disable client-to-session (writing to the session) and enables session-to-client (writing to the client). Again, this can be extended by another policy (Session clipboard write allowed formats).
Client clipboard write allowed formats AND Session clipboard write allowed formats
These two policies (again, available from 7.6 onwards) are identical in activity except that they work on client-only clipboard or session-only clipboard as defined above. Obviously, the corresponding “Restrict xxx clipboard write” policy needs to be defined in order for this to take effect. This works as a kind of “override”, in that the respective session or client clipboard write is disabled (by the respective policies), but the data types defined here are selectively allowed to be copied and pasted. If you wanted to allow this to work in both directions, you would need to defined both the “restrict write” policies and then both the “write allowed formats” policies as well.
There are a number of data formats to choose from – there are some system-defined formats, there are some custom XenApp and XenDesktop formats, and you could even define your own. The system defined formats are described in this article. The Citrix custom formats are not defined anywhere I can seem to reference, although there are a number of articles out there discussing their usage.
So, if you’re concerned specifically about users cutting and pasting screenshots or lifting the contents of Word documents, then restricting to the text formats is a pretty good place to start (my “copy-text-only-from-client-to-session” setting is below)
That’s it for the policies, that’s all we have (there are some clipboard-related policies for Linux VDA, but we will ignore those :-))
Testing
Let’s see if our policy works. Remember, we wanted to allow the user to copy and paste only text, and only from the client into the session – not the other way, and not any other formats.
So that’s that, all well and good – testing was exactly what we expected 
Copy and paste direct
Now, an interesting aside to this is that for a while now, we’ve been able to copy and paste files and folders directly into RDP sessions, but not into Citrix sessions. However if your Workspace App is at the latest version and the VDA of your Citrix session is 1903 or higher, you should now be able to enable this. However, if you’re using Clipboard policies as above, you will need to add a further format type – CFX_FILE – into the policy to allow this to be achieved in your chosen direction (or directions).
Summary
So here’s a quick summary of what to configure for some possible sets of requirements:-
Full, bi-directional clipboard redirection
Set “Client clipboard redirection” to Allowed
Full, client-to-session only clipboard redirection
Set “Client clipboard redirection” to Allowed
Set “Restrict client clipboard write” to Enabled
Full, session-to-client only clipboard redirection
Set “Client clipboard redirection” to Allowed
Set “Restrict session clipboard write” to Enabled
Selective formats, bi-directional clipboard redirection
Set “Client clipboard redirection” to Allowed
Set “Restrict session clipboard write” to Enabled
Set “Restrict client clipboard write” to Enabled
Set “Session clipboard write allowed formats” to required formats
Set “Client clipboard write allowed formats” to required formats
Selective formats, client-to-session only clipboard redirection
Set “Client clipboard redirection” to Allowed
Set “Restrict session clipboard write” to Enabled
Set “Restrict client clipboard write” to Enabled
Set “Session clipboard write allowed formats” to required formats
Selective formats, session-to-client only clipboard redirection
Set “Client clipboard redirection” to Allowed
Set “Restrict session clipboard write” to Enabled
Set “Restrict client clipboard write” to Enabled
Set “Client clipboard write allowed formats” to required formats
That’s all I have on clipboard redirection – we can now mix and match these policies to (hopefully!) make your environments a little bit more secure without actually interrupting some of your user workflows.