locked
Citrix XenApp5 Session Error RRS feed

  • Question

  • I get this error when trying to access Citrix XenApp 5 using the XenApp5 template with UAG RTM.

    Session Error
    There is a problem with your session. For security reasons, you must close your browser window and log on again to continue accessing your published resources.
    To log on again, you must restart your browser.

    I added the entry SSLVPNTemplates.xml as described in the UAG release notes:
    http://technet.microsoft.com/en-us/library/dd772157.aspx

    I also tried adding a WhlFiltAppWrap_HTTPS.xml entry in a CustomUpdate directory for the trunk as discovered by Jason here:
    http://forums.forefrontsecurity.org/default.aspx?g=posts&m=1323

    However I still get the error.

    I also was unable to find the source of the entry Jason posted on an old IAG machine. I found some entries in WhlFiltSecureRemote_HTTPS.xml on my IAG but not in any *appWrap*.xml files.

    So am I missing anything? Anyone else experience this problem and have additional steps to fix or thoughts on how to further diagnose the issue?
    Friday, March 12, 2010 5:26 PM

Answers

  • We spent a long time debugging this and the issue is related to cookies expected by Web Interface. The fix code allows the cookies to reach the client and hence keep WI happy. If you use a tool like Fiddler or Charles, you can see the different cookie results with the native code (no cookies on clinet) and the added code (cookies on client). The AppWrap changes definitely work as I took the custom file to a customer and it fixed their "Session Error" issues straight away. Did you do an IISRESET after adding the custom file? Maybe you need an activation too?

    Where did you place the new WhlFiltAppWrap_HTTPS.xml file?

    Cheers

    JJ
    Jason Jones | Forefront MVP | Silversands Ltd
    • Marked as answer by techaccnt Monday, March 15, 2010 6:03 PM
    Friday, March 12, 2010 5:53 PM
  • Hi,
    Publishing Citrix has always been a challange for IAG and UAG, because Citrix changes their cookie behavior very frequently. Most of this stuff can be fixed using the correct AppWrap, but it may be tough to figure out for some versions. I'm not sure to which version of Citrix Jason's solution applies, and if you have the same version or not, but I would suggest you use HTTPWatch or Fiddler to check if the AppWrap file you used has actually made any change to the code. You could also add some generic clause to it to make it more visible (like changing some "welcome" text to uppercase, for example).
    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Monday, March 15, 2010 6:22 PM
    Monday, March 15, 2010 6:22 PM

All replies

  • We spent a long time debugging this and the issue is related to cookies expected by Web Interface. The fix code allows the cookies to reach the client and hence keep WI happy. If you use a tool like Fiddler or Charles, you can see the different cookie results with the native code (no cookies on clinet) and the added code (cookies on client). The AppWrap changes definitely work as I took the custom file to a customer and it fixed their "Session Error" issues straight away. Did you do an IISRESET after adding the custom file? Maybe you need an activation too?

    Where did you place the new WhlFiltAppWrap_HTTPS.xml file?

    Cheers

    JJ
    Jason Jones | Forefront MVP | Silversands Ltd
    • Marked as answer by techaccnt Monday, March 15, 2010 6:03 PM
    Friday, March 12, 2010 5:53 PM
  • I placed the WhlFiltAppWrap_HTTPS.xml file in von\conf\WebSites\(trunkname)\conf\CustomUpdate then applied configuration (which probably wasn't needed) and then iisreset.

    Actually you just made me think that I should check file permissions on the new directory and file.

    I'll check what is happening with the cookies on the client.

    So where exactly did you find that on IAG, I looked but was unable to locate the piece you posted.

    Thank you.
    Friday, March 12, 2010 6:08 PM
  • Hmmm....location looks good.

    Email me (email address can be found in my blog) and I can send the actual XML file I have used...

    I will have a look at IAG again and find the exact file.

    Cheers

    JJ
    Jason Jones | Forefront MVP | Silversands Ltd
    Friday, March 12, 2010 8:05 PM
  • You should veify the URL in the appwrap matches the path to your login.aspx.
    <URL case_sensitive="false">/Citrix/.*/auth/login.aspx</URL>

    Friday, March 12, 2010 8:16 PM
  • I checked the login URL http://<hostname>/Citrix/XenApp/auth/login.aspx I assume the appwrap uses a regex format so .* would match XenApp but I also changed the appwrap file to explicitly use /Citrix/XenApp/auth/login.aspx but still no joy. Good thought though.
    Friday, March 12, 2010 11:02 PM
  • Many thanks to Jason, it appears that UAG might be a little fussy about the format of the WhlFiltAppWrap_HTTPS.xml file. I'll paste what I used there:

    <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/login.aspx</URL>
    <!-- check if RWS is secured or not -->
                <SAR>
                    <SEARCH encoding="base64">ZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</SEARCH>
                    <REPLACE encoding="base64">d2hsSXNTZWN1cmUgPSAiRkFMU0UiOw0KZnVuY3Rpb24gY2hlY2tXSExSV1MoKQ0Kew0KIHZhciB3aGxVUkwgPSBsb2NhdGlvbi5ocmVmOw0KCSBpbmRleDEgPSB3aGxVUkwuaW5kZXhPZigiLy8iKTsNCiAgICAgICAgICAgICBpbmRleDIgPSB3aGxVUkwuaW5kZXhPZigiLyIsaW5kZXgxKzIpOw0KICAgICAgICAgICAgIGluZGV4MyA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDIrMSk7ICAgICAgDQoJIGluZGV4NCA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDMrMSk7ICAgIA0KICAgICAgICAgICAgLy9nZXQgdGhlIHdobCBpbmRpY2F0b3IgZm9yIGEgc2VjdXJlLyBub24gc2VjdXJlIFJXUyAgICAgICAgICAgICAgICANCgkJd2hsVVJMID0gd2hsVVJMLnN1YnN0cmluZyhpbmRleDQtMSxpbmRleDQpOw0KCQkvL21lYW5zIHRoZSBSV1MgaXMgc2VjdXJlZA0KCQlpZiAod2hsVVJMID09ICIxIil3aGxJc1NlY3VyZSA9ICJUUlVFIjsNCn0NCmNoZWNrV0hMUldTKCk7ICAgICAgICAgICAgICAgIA0KZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</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>
             
        </DATA_CHANGE>
    </MANIPULATION_PER_APPLICATION>
     
     
    </MANIPULATION>
    </APP_WRAP>
    Monday, March 15, 2010 6:02 PM
  • Hi,
    Publishing Citrix has always been a challange for IAG and UAG, because Citrix changes their cookie behavior very frequently. Most of this stuff can be fixed using the correct AppWrap, but it may be tough to figure out for some versions. I'm not sure to which version of Citrix Jason's solution applies, and if you have the same version or not, but I would suggest you use HTTPWatch or Fiddler to check if the AppWrap file you used has actually made any change to the code. You could also add some generic clause to it to make it more visible (like changing some "welcome" text to uppercase, for example).
    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Monday, March 15, 2010 6:22 PM
    Monday, March 15, 2010 6:22 PM
  • Many thanks to Jason, it appears that UAG might be a little fussy about the format of the WhlFiltAppWrap_HTTPS.xml file. I'll paste what I used there:

    <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/login.aspx</URL>
    <!-- check if RWS is secured or not -->
                <SAR>
                    <SEARCH encoding="base64">ZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</SEARCH>
                    <REPLACE encoding="base64">d2hsSXNTZWN1cmUgPSAiRkFMU0UiOw0KZnVuY3Rpb24gY2hlY2tXSExSV1MoKQ0Kew0KIHZhciB3aGxVUkwgPSBsb2NhdGlvbi5ocmVmOw0KCSBpbmRleDEgPSB3aGxVUkwuaW5kZXhPZigiLy8iKTsNCiAgICAgICAgICAgICBpbmRleDIgPSB3aGxVUkwuaW5kZXhPZigiLyIsaW5kZXgxKzIpOw0KICAgICAgICAgICAgIGluZGV4MyA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDIrMSk7ICAgICAgDQoJIGluZGV4NCA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDMrMSk7ICAgIA0KICAgICAgICAgICAgLy9nZXQgdGhlIHdobCBpbmRpY2F0b3IgZm9yIGEgc2VjdXJlLyBub24gc2VjdXJlIFJXUyAgICAgICAgICAgICAgICANCgkJd2hsVVJMID0gd2hsVVJMLnN1YnN0cmluZyhpbmRleDQtMSxpbmRleDQpOw0KCQkvL21lYW5zIHRoZSBSV1MgaXMgc2VjdXJlZA0KCQlpZiAod2hsVVJMID09ICIxIil3aGxJc1NlY3VyZSA9ICJUUlVFIjsNCn0NCmNoZWNrV0hMUldTKCk7ICAgICAgICAgICAgICAgIA0KZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</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>
             
        </DATA_CHANGE>
    </MANIPULATION_PER_APPLICATION>
     
     
    </MANIPULATION>
    </APP_WRAP>

    So, did this still not work?
    Jason Jones | Forefront MVP | Silversands Ltd
    Monday, March 15, 2010 10:08 PM
  • Hi Both,

    I found that I needed the AppWrap changes for WI 4.5, 4.6 and 5.2. With 4.x you get a "inconsistent state" error and with 5.x you get a generic "session error" error but both seem to be attributed to the same underlying cookie issue.

    From my research, the Citrix cookie changes were made in WI 4.x to address a session fixation attack vector as discussed here:

    "The cookie in question is called 'WIAuthId'

    This error occurs as a side effect of a feature of WI 4's authentication code. To guard against what is known as a 'session fixation attack' (try Google), WI uses its own authentication cookie, such that, once the user is known to be authentic, a unique authentication id is stored in the web session's state, as well as being written back to the browser as a cookie. If these ID's become mismatched (e.g. because a session fixation attack is in progress) then the error you observed is generated.

    In this case, of course, the error is likely due to the fact that you have broken the authentication cookie mechanism, probably by somehow losing the cookie that was originally sent to the browser when the user authenticated (WI expects that cookie to be present in all requests to pages that require that the user is authenticated)."

    I have used the same code to fix both WI 4.6 and 5.2 deployments by simply using the UAG Citrix XenApp 5 template and dropping the custom AppWrap file in place...

    Cheers

    JJ 

    Jason Jones | Forefront MVP | Silversands Ltd
    Monday, March 15, 2010 10:14 PM
  • FYI - We actually used a program called "Charles" which provides some pretty cool features compared to some of the more traditional HTTP debuggers...
    Jason Jones | Forefront MVP | Silversands Ltd
    Monday, March 15, 2010 10:21 PM
  • Sorry I wasn't more clear, that one (the information I posted, which you had provided to me) worked and I marked your post as the answer to my question.
    Monday, March 15, 2010 11:25 PM
  • Sorry I wasn't more clear, that one (the information I posted, which you had provided to me) worked and I marked your post as the answer to my question.

    Cool! Great news!
    Jason Jones | Forefront MVP | Silversands Ltd
    Monday, March 15, 2010 11:39 PM