Cross site single sign on not working between two UAG servers
As usual I worked on a case regarding cross site single sign on and thought of sharing the experience and observations with all.
Here customer has configured cross site single sign on as per the document https://technet.microsoft.com/en-us/library/ee921441.aspx
But in his environment he had two separate UAG servers one with UAG RTM update 2 and other was UAG sp1 and his single sign on was not working across the UAG servers between two web sites.
Requirement: As requirement, Single Sign On cookies provide cross site single sign on functionality, hence focus of this post is primarily towards SSO cookies which is also circumstantial in this scenario.
Troubleshooting
As per the technet article, all the custom update folders had required files and all the procedures and steps mentioned in above technet were followed, still cross site single sign on was not working. So took httpwatch trace from a client machine while trying to repro the issue. We found that if
we login to a web site published through UAG sp1 we get following cookies at the time of login from validate.asp page.
If we click on a link, on this website that takes us to other website which is published through other UAG server we were redirected to logon page i.e. single sign on was not working.
In the other httpwatch, taken while trying to logon from website published through other UAG server i.e. non sp1 UAG , We had a cookie WHLSSO as shown marked below, we did not see similar cookie in the previous
snapshot, although we had some weird looking cookies.
From here I tried to click to a link that takes to website published through UAG SP1 and that worked.
Lab setup
I had a lab handy of UAG servers , I recreated the scenario by keeping one UAG with sp1 and other without SP1 and configured cross site single sign on between two websites to find out the cookie assignment at the
time of validation of user logon and found following
Single Sign On Cookies on UAG SP1
i.e.
WhlSSO Receivedr1=51559F68BFF4E6D3D9CCFF142E41458211E537AAF2099635F13E45F74F32EB23&p1=079192257FB4F36F01CC28A912A44EC9&u1=AF5719730B423A01169187E3A7ACFF47528424A29DDEDE2583429AC5BCF8EB5F&n=5E9984013D36464F8143A40E16EAFA5D&1=5E99A3B1DA7BCE4DAC1D370766C8B0BF1527AAE1E9C5FF025DDEFDDB508EC058&t=0996D90D89A498EA4ABFD998BF07C4130BFE03E6BEFC92AA4116B6ADE1461141&l=AA097705547486AE92C1A72560EACB84&s=58B1980E20E0 / .cssotest.com (Session) Server No No
And
WhlSSOAttr Receiveddomain%3Dcssotest.com%3B+path%3D/ / .cssotest.com (Session) Server No No
Single Sign On Cookies on UAG RTM with update 2
i.e.
WhlSSO Received r1=51559F68BFF4E6D3D9CCFF142E41458211E537AAF2099635F13E45F74F32EB23&p1=079192257FB4F36F01CC28A912A44EC9&u1=AF5719730B423A01169187E3A7ACFF47528424A29DDEDE2583429AC5BCF8EB5F&n=5E9984013D36464F8143A40E16EAFA5D&1=5E99A3B1DA7BCE4DAC1D370766C8B0BF1527AAE1E9C5FF025DDEFDDB508EC058&t=943E9A6AF105F05DAC6F697842E83E0BFE56B7A7C4A08030DDF524A2AE0006BB&l=AA097705547486AE92C1A72560EACB84&s=2B728411DC7A / .cssotest.com (Session) Server No No
Observation
From
httpwatch taken from two UAG servers in the lab with and without sp1 of UAG, it was clear that UAG sp1 assigns two SSO cookies i.e. WhlSSO and WhlSSOAttr on theother side UAG without sp1 assigns only one SSO cookie i.e. WhlSSO.
Comparing it with customer scenario it appeared that due to file corruption (under the custom update folders) these SSO cookies are not assigned with correct names as we saw in lab scenario.
Resolution
We followed the cross site single sign on configuration process again from scratch (as explained in above technet article) on two UAG servers. In order to test we took httpwatch while trying to access and found SSO cookies on UAG SP1 with correct
names and single sign on was also working properly between two websites published through two UAG servers.