Create a Auth Profile so that in new builds, domain wide Cookies are set.
Reproduction Steps :
- Created a CS vserver for hosts , example webpage.ssb.com and webpage1.ssb.com.
- We have 2 CS policies created corresponding to the 2 hosts mentioned above.
- Now we access webpage.ssb.com.
- User gets authenticated at AAA and the backend page is displayed.
- Now we open a different tab on the same browser session, and access webpage1.ssb.com
- The difference that we noticed were:
- In Previous builds, we are able to get the server behind webpage1 LB vserver.
- In latest builds, we get the AAA page again.
- We do not make any change rather than upgrade.
- We took traces in the working and non-working scenarios and below are the changes that we see :In the working case, it is seen that see that we are setting domain wide cookies:
Set-Cookie: NSC_TMAA=73e0417a70c904ab882595223bec3976;HttpOnly;Path=/;Domain=ssb.com\r\n
Set-Cookie: NSC_TMAS=1671b659a13a685dc4a49b5a1574db74;Secure;HttpOnly;Path=/;Domain=ssb.com\r\n
In the non-working case, we are setting on FQDN:
Set-Cookie: NSC_TMAA=9afc4cdec4b2f058ad306e33a4054fcc;HttpOnly;Path=/;\r\n
Set-Cookie: NSC_TMAS=2099c58e14c508f0f6c7b1e29c85d305;Secure;HttpOnly;Path=/;\r\n
- Hence, in the working case, when we access the second page (same domain) you are granted access. In the non-working case, the second page has different FQDN and we are prompted to login again.
- In the latest builds, there have been changes made to not to set domain wide Cookies by default.
- Domain Wide Cookies will be set by NetScaler only when required domain is configured in Auth Profile.
- Then we created a Auth Profile and bound it to the respective vservers.
- The set up then works as expected.
- If we take a trace after creating a Auth Profile, we will see the Auth Profile name in the NSC_TMAP Cookie set by NetScaler.
Note :
- Please avoid giving spaces in the names of the Auth Profile that you would be creating.
Problem Cause
AAA behavior change in generating Cookies for security reasons