Citirx XenApp WI 5.4 loops with 302 redirect through UAG
I came across quite few scnerio's recently where I have seen WI 5.4 loops in 302 redirect issue through reverse proxies and in my case its UAG. I debugged the HTTP stream to understand the Citirx WI 5.4 behaviour and to me it looked bit different in flow as compared to previous WI 5.x builds. I tried to tweak the same fix that I provided previously for WI 5.x through UAG but this time it wasnt helping {Grrr..}. After investing some time in lab it all came down to authentication flow thats changed in WI 5.4.
In simple previously Citirx was first installing the Citirx web client and then authenitcating the end user accessing XenApp landing page, now with WI 5.4 they first do authN and then install the client component, which makes sense from WI point fo view as they do have security reservations.
Debugging showed that we are getting in 302 redirect loop at "/Citrix/.*/auth/silentDetection.aspx. I reversed the flow and narrowed down to problem where certain cookies that are signed by UAG are not being interpreted by XenApp. So what I had to do is to write a custom SRA file as follows:
In SRA file <WhlFiltSecureRemote_HTTPS.xml> under cookie handling tag this is what you need to do:
<?xml version="1.0"?>
<WHLFILTSECUREREMOTE ver="2.2">
<COOKIES_HANDLING>
<SERVER>
<SERVER_NAME mask="">.*</SERVER_NAME>
<Set-Cookie remove="">
<NAME>WINGSession</NAME>
<Path remove="true">/Citrix/XenApp</Path>
</Set-Cookie>
<Set-Cookie remove="">
<NAME>WIUser</NAME>
<Path remove="true">/Citrix/XenApp</Path>
</Set-Cookie>
<Set-Cookie remove="">
<NAME>WIClientInfo</NAME>
<Path remove="true">/Citrix/XenApp</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>
===============
The above will fix the looping problem of WI 5.4 through UAG.
You need to copy this file to ...\Microsoft Forefront Unified Access Gateway\Von\Conf\Websites\<your trunk name> \Conf\CustomUpdate
PS: Dont copy /Paste this from here as it might break the XML Syntax and to test that out once you write this file just load it in Internet Explorer to see if its healthy and not broken. Also feel free to tweak the files as you would like as its a very generic configuration I am sharing here.
I would also suggest to use the WhiFiltAppWrap_HTTPS.xml to avoid other known Citirx issues in previous WI 5.x builts. You need to copy this file along with the other in same location <...\Microsoft Forefront Unified Access Gateway\Von\Conf\Websites\<your trunk name> \Conf\CustomUpdate> .
===============
<?xml version="1.0"?>
<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">
<MANIPULATION>
<MANIPULATION_PER_APPLICATION>
<APPLICATION_TYPE>CitrixXenApp5</APPLICATION_TYPE>
<!-- citrix 4.5 fix client cookies issue -->
<DATA_CHANGE ee="1">
<URL case_sensitive="false">/Citrix/.*/auth/silentDetection.aspx</URL>
<!-- check if RWS is secured or not -->
<SAR>
<SEARCH encoding="base64">ZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</SEARCH>
<REPLACE encoding="base64">
ICAgICAgICAgICAgICAgICAgICB3aGxJc1NlY3VyZSA9ICJGQUxTRSI7DQogICAgICAgICAgZnVuY3Rpb24gY2hlY2tXSExSV1MoKQ0KICAgICAgICAgIHsNCiAgICAgICAgICB2YXIgd2hsVVJMID0gbG9jYXRpb24uaHJlZjsNCiAgICAgICAgICBpbmRleDEgPSB3aGxVUkwuaW5kZXhPZigiLy8iKTsNCiAgICAgICAgICBpbmRleDIgPSB3aGxVUkwuaW5kZXhPZigiLyIsaW5kZXgxKzIpOw0KICAgICAgICAgIGluZGV4MyA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDIrMSk7DQogICAgICAgICAgaW5kZXg0ID0gd2hsVVJMLmluZGV4T2YoIi8iLGluZGV4MysxKTsNCiAgICAgICAgICAvL2dldCB0aGUgd2hsIGluZGljYXRvciBmb3IgYSBzZWN1cmUvIG5vbiBzZWN1cmUgUldTDQogICAgICAgICAgd2hsVVJMID0gd2hsVVJMLnN1YnN0cmluZyhpbmRleDQtMSxpbmRleDQpOw0KICAgICAgICAgIC8vbWVhbnMgdGhlIFJXUyBpcyBzZWN1cmVkDQogICAgICAgICAgaWYgKHdobFVSTCA9PSAiMSIpd2hsSXNTZWN1cmUgPSAiVFJVRSI7DQogICAgICAgICAgfQ0KICAgICAgICAgIGNoZWNrV0hMUldTKCk7DQogICAgICAgICAgZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==
</REPLACE>
</SAR>
<!-- setting isSecure to false -->
<SAR>
<SEARCH encoding="base64">dmFyIGlzU2VjdXJlID0gKGxvY2F0aW9uLnByb3RvY29sLnRvTG93ZXJDYXNlKCkgPT0gJ2h0dHBzOicpOw==</SEARCH>
<REPLACE encoding="base64">dmFyIGlzU2VjdXJlID0gd2hsSXNTZWN1cmU7</REPLACE>
</SAR>
<!-- remove secure setting when creating cookie on client machine -->
<SAR>
<SEARCH encoding="base64">aWYgKHdpbmRvdy5sb2NhdGlvbi5wcm90b2NvbC50b0xvd2VyQ2FzZSgpID09ICJodHRwczoiKQ==</SEARCH>
<REPLACE encoding="base64">aWYgKHdobElzU2VjdXJlPT0iVFJVRSIp</REPLACE>
</SAR>
<!-- disable the line: "cookie = cookie + "; path=" -->
<!-- https://support.citrix.com/article/CTX117597 -->
<SAR>
<SEARCH encoding="base64">Y29va2llID0gY29va2llICsgIjsgcGF0aD0=</SEARCH>
<REPLACE encoding="base64">Ly8gY29va2llID0gY29va2llICsgIjsgcGF0aD0=</REPLACE>
</SAR>
</DATA_CHANGE>
</MANIPULATION_PER_APPLICATION>
</MANIPULATION>
</APP_WRAP>
==============
Once both the WhlFiltSecureRemote_HTTPS.xml and WhlFiltAppWrap_HTTPS.xml files are in place WI 5.4 should work fine. Please note if you already have custom files in place for other apps on your trunk then carefully merge this in those exisiting files.
PS: Some of the users seeing the Cookie Session error once redirect problem is resolved. So the solution for that one is just adding two more cookies to the above proposed SRA file so here we go:
<WHLFILTSECUREREMOTE ver="2.2">
<COOKIES_HANDLING>
<SERVER>
<SERVER_NAME mask="">.*</SERVER_NAME>
<Set-Cookie remove="">
<NAME>WINGSession</NAME>
<Path remove="true">/Citrix/XenApp</Path>
</Set-Cookie>
<Set-Cookie remove="">
<NAME>WIUser</NAME>
<Path remove="true">/Citrix/XenApp</Path>
</Set-Cookie>
<Set-Cookie remove="">
<NAME>WIClientInfo</NAME>
<Path remove="true">/Citrix/XenApp</Path>
</Set-Cookie>
<Set-Cookie remove="">
<NAME>WIAuthId</NAME>
<Path remove="true">/Citrix/XenApp</Path>
</Set-Cookie>
<Set-Cookie remove="">
<NAME>WINGDevice</NAME>
<Path remove="true">/Citrix/XenApp</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>
Hope this helps.
PS: this post is written considering a very generic and almost XenApp default configuraiton through UAG. Feel free to tweak the XML files as per your requirements.
For custom Paths issue review Ben's blog as he got a nice post up there https://blogs.technet.com/b/ben/archive/2011/10/05/issues-with-citrix-5-4.aspx
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
OK, I got it to not loop, but I had to modify your XML and replace /Citrix/XenAPP/ with /Citrix/UAG since UAG is the site on out WI referenced by UAG. Is it possible to use wild cards so any WI logon point/site is accessible? Thanks for your worjk on thisAnonymous
January 01, 2003
Chris you can have wildcards but ensure that you dont break the path whatever you modify. I am not sure if WI login could be reachable using just a wildcard.you need to test this out.Anonymous
January 01, 2003
Hi, sorry, the page ends... /Citrix/UAG/auth/silentDetection.aspxAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
good catch Frank.Anonymous
June 20, 2011
Thanks Faisal, very useful!Anonymous
July 26, 2011
Thanks Faisal...I got it working. And the looping issue which Chris is facing, can be solved by removing Single-Sign On.Anonymous
August 24, 2011
In our customers case we also had to add: <Set-Cookie remove=""> <NAME>WIAuthId</NAME> <Path remove="true">/Citrix/XenApp</Path> </Set-Cookie> <Set-Cookie remove=""> <NAME>WINGDevice</NAME> <Path remove="true">/Citrix/XenApp</Path> </Set-Cookie> In order for all cookies to get passed through unencrypted.Anonymous
December 22, 2011
Faisal great work, I am now up and running. Keep up the good work. Phil.Anonymous
December 23, 2011
Somebody is using Single Sign ON ??? If we enable Single Sign On we always get a user called --> siteuser and it doesn't authenticate.