Issues with Citrix (version 5.4 or later)

Article
10/04/2011

While UAG comes pre-configured with an application template for Citrix, we often discover that Citrix makes certain changes to their product with incremental updates, and that can cause various issues with UAG when trying to publish later versions than the one that UAG’s template was designed for. At the time of writing, the steps below pertain to version 5.4.

***UPDATE***December 2012***
At this time, I confirmed that the steps are appropriate for version 6.5 as well
***********************************

The 1^st issue seen by many is “You have attempted to access a restricted URL” errors, usually accompanied by Web-Monitor security errors such as: “A request from source IP address 68.245.177.39, user JohnDough on trunk employees; Secure=1 for application Citrix-VDI of type CitrixXenApp5 failed. The URL /Citrix/DesktopWeb/loading.htm contains an illegal path. The rule applied is Default rule. The method is GET.”

You might see other similar variations of this, with other paths. For example:

· /Citrix/DesktopWeb/media/XenDesktopComboAll.ico

· /Citrix/DesktopWeb/html/styles/basicStyle.css

This is happening because our template was designed with the mindset that Citrix would be hosted under /citrix/xenapp. When you publish the application, it creates a rule to accommodate for the loading page (Citrix Rule no. 49), as well as other rules. However, if Citrix is under a different path, UAG errors out because the rules don’t match the actual requests generated by Citrix. To fix this, here are the steps:

1. Open the UAG console

2. Go to the Advanced Trunk Configuration

3. Go to the URL set tab

4. Scroll down to the Citrix rule no. 49.

5. For rules 49, 50 and 51, change the string XENAPP to [a-z0-9_-]*

6. Click OK

7. Activate the configuration

A similar issue may occur for other paths. For example, clients trying to download the Citrix online plug-in may get denied access to its URL (/Citrix/DesktopWeb/Clients_common/Windows/Online Plug-in/CitrixOnlinePluginWeb.exe). This is because this URL did not exist when the UAG template was created, so there’s no access rule for it at all. To address this, you will need to create a brand new rule. Here’s how:

1. On the URL Set tab, click Add Primary

2. Give the rule a name, based on the Citrix rule naming convention, but use a high number such as 99. The rule would be something like “CitrixXenApp5_Rule99”. The reason for using a high number is because future updates to UAG may change the default ruleset, and possibly add rules beyond the current 54 rules. If we named the rule “CitrixXenApp5_Rule55”, and a future update expands the rules for Citrix, it may overwrite your rule and re-introduce this problem.

3. Set the rule’s action to accept

4. Set the URL to match your server’s configuration. Usually, this would be “ /Citrix/DesktopWeb/Clients_common/Windows/Online Plug-in/CitrixOnlinePluginWeb\.exe”, but could be different if your server is not installed in /Citrix/DesktopWeb or for newer versions of Citrix, where the plug in has been renamed to CitrixReceiver.exe. Note the back-slash before the .exe – this is intentional, as part of the RegEx convention, for which the dot is a non-literal.

5. Set the parameters tab to ignore

6. In the Method drop-down, select get

7. Click OK

8. Activate your configuration.

Another issue that pops-up with Citrix often, and has been reported to occur with Citrix 5.4 is a looping behavior, where trying to launch the application triggers the browser to loop through the login page repeatedly, ad infinitum. This is caused by a change to the way Citrix handles cookies. To fix it, one needs to configure UAG to treat the cookies a little differently, and that is done via a custom SRA and AppWrap configuration.

To resolve this, you will need to create two XML files on your server, and populate them with the content that I will include ahead. Be careful when copying the content, to preserve a good structure. If any of the XML tags gets broken, it cause UAG to produce a 500 error, so be prepared to back-out any changes if you run into issues. You may also contact me directly via the contact-me form to obtain the files directly from me. The 2^nd file there is the more sensitive one, as it has a very long line of text that must be kept intact.

Here are the steps:

1. Copy the content of the first box below into a text file, and save it as “WhlFiltSecureRemote_HTTPS.XML” on your UAG server, under the folder <UAG Path>\Von\Conf\Websites\<Your Trunk>\Conf\CustomUpdate

2. Look at the path settings (highlighted below in green). Your actual path for the Citrix installation may differ (a common variation is /Citrix/XenApp/auth/). If so, change it in the file you create.

3. Copy the content of the second box below into a text file, and save it as “WhlFiltAppWrap_HTTPS.XML” on your UAG server, under the same folder

4. If there are files by those names in there already, STOP! The files CAN be combined, but it could be tricky to do, and I recommend opening a support case with Microsoft CSS to work-through that process.

5. Activate your UAG configuration

1^st file (WhlFiltSecureRemote_HTTPS.xml):

<WHLFILTSECUREREMOTE ver="2.2"> <COOKIES_HANDLING> <SERVER> <SERVER_NAME mask="">.*</SERVER_NAME> <Set-Cookie remove=""> <NAME>WINGSession</NAME> <Path remove="true">/Citrix/DesktopWeb/auth/</Path> </Set-Cookie> <Set-Cookie remove=""> <NAME>WIUser</NAME> <Path remove="true">/Citrix/DesktopWeb/auth/</Path> </Set-Cookie> <Set-Cookie remove=""> <NAME>WIClientInfo</NAME> <Path remove="true">/Citrix/DesktopWeb/auth/</Path> </Set-Cookie> </SERVER> <SERVER> <SERVER_NAME mask="">.*</SERVER_NAME> <Set-Cookie> <NAME>WINGSession</NAME> <Secure remove="true"/> </Set-Cookie> <Set-Cookie> <NAME>WIUser</NAME> <Secure remove="true"/> </Set-Cookie> <Set-Cookie> <NAME>WINGDevice</NAME> <Secure remove="true"/> </Set-Cookie> <Set-Cookie> <NAME>WIAuthId</NAME> <Secure remove="true"/> </Set-Cookie> <Set-Cookie> <NAME>WIClientInfo</NAME> <Secure remove="true"/> </Set-Cookie> </SERVER> </COOKIES_HANDLING> </WHLFILTSECUREREMOTE>

2^nd file (WhlFiltAppWrap_HTTPS.xml)

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml"> <MANIPULATION> <MANIPULATION_PER_APPLICATION> <APPLICATION_TYPE>CitrixXenApp5</APPLICATION_TYPE>  <DATA_CHANGE ee="1"> <URL case_sensitive="false">/Citrix/.*/auth/silentDetection.aspx</URL>  <SAR> <SEARCH encoding="base64">ZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</SEARCH> <REPLACE encoding="base64"> ICAgICAgICAgICAgICAgICAgICB3aGxJc1NlY3VyZSA9ICJGQUxTRSI7DQogICAgICAgICAgZnVuY3Rp b24gY2hlY2tXSExSV1MoKQ0KICAgICAgICAgIHsNCiAgICAgICAgICB2YXIgd2hsVVJMID0gbG9jYXRp b24uaHJlZjsNCiAgICAgICAgICBpbmRleDEgPSB3aGxVUkwuaW5kZXhPZigiLy8iKTsNCiAgICAgICAg ICBpbmRleDIgPSB3aGxVUkwuaW5kZXhPZigiLyIsaW5kZXgxKzIpOw0KICAgICAgICAgIGluZGV4MyA9 IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDIrMSk7DQogICAgICAgICAgaW5kZXg0ID0gd2hsVVJMLmlu ZGV4T2YoIi8iLGluZGV4MysxKTsNCiAgICAgICAgICAvL2dldCB0aGUgd2hsIGluZGljYXRvciBmb3Ig YSBzZWN1cmUvIG5vbiBzZWN1cmUgUldTDQogICAgICAgICAgd2hsVVJMID0gd2hsVVJMLnN1YnN0cmlu ZyhpbmRleDQtMSxpbmRleDQpOw0KICAgICAgICAgIC8vbWVhbnMgdGhlIFJXUyBpcyBzZWN1cmVkDQog ICAgICAgICAgaWYgKHdobFVSTCA9PSAiMSIpd2hsSXNTZWN1cmUgPSAiVFJVRSI7DQogICAgICAgICAg fQ0KICAgICAgICAgIGNoZWNrV0hMUldTKCk7DQogICAgICAgICAgZnVuY3Rpb24gc2V0SXRlbUluQ29v a2llKG5hbWUsIHZhbHVlKQ== </REPLACE> </SAR>  <SAR> <SEARCH encoding="base64">dmFyIGlzU2VjdXJlID0gKGxvY2F0aW9uLnByb3RvY29sLnRvTG93ZXJDYXNlKCk gPT0gJ2h0dHBzOicpOw==</SEARCH> <REPLACE encoding="base64">dmFyIGlzU2VjdXJlID0gd2hsSXNTZWN1cmU7</REPLACE> </SAR>  <SAR> <SEARCH encoding="base64">aWYgKHdpbmRvdy5sb2NhdGlvbi5wcm90b2NvbC50b0xvd2VyQ2FzZSgpI D09ICJodHRwczoiKQ==</SEARCH> <REPLACE encoding="base64">aWYgKHdobElzU2VjdXJlPT0iVFJVRSIp</REPLACE> </SAR>   <SAR> <SEARCH encoding="base64">Y29va2llID0gY29va2llICsgIjsgcGF0aD0=</SEARCH> <REPLACE encoding="base64">Ly8gY29va2llID0gY29va2llICsgIjsgcGF0aD0=</REPLACE> </SAR> </DATA_CHANGE> </MANIPULATION_PER_APPLICATION> </MANIPULATION> </APP_WRAP>

Comments

Anonymous
January 01, 2003
Very nice :) !
Anonymous
May 18, 2013
Hey Ben, I followed the instructions to remove the looping issue and it works perfectly on UAG SP2. When I upgrade to SP3, SSO on Citrix seems to fail, as we get the Windows 2008 R2 login screen rather than the application. Any ideas on this?
Anonymous
November 04, 2013
Any further information on the above since the introduction of SP3? I've hit the same problem and would like to know if anyone has found a resolution!! Thanks, James.

Share via

Issues with Citrix (version 5.4 or later)

Comments

Additional resources