I found a strange behaviour by 12.51 webagent which sometimes tries to set multiple SMSESSION cookies at the same time in a domain. Can anyone explain why?
Below is the screenshot.
i do not see the domains there.
is there a chance one is .server.company.com and the other is .company.com?
Have you tried using some other tool to verify this other than TamperData. I have encountered other issues with Tamper Data in testing phases.
Use some tools like IEHTTPHeader with IE Browser & check this.
IEHTTPHeaders Download Link : Jonas Blunck
Just as Josh recommended.
Here's a Tech note when you may possibily see multiple cookies.
Check your cookie domains and the FQDN that is being accessed.
Also missing is "Direction" of the Cookies. Cookies are 'Sent' and 'Received'. We use the tool HTTP Watch.
Seeing a similar issue, did you figure out what the issue was?
Adding some details...
1. We have SSO with another domain facilitated by a cookie provider. When logging into the other domain first (primary.com) then clicking a link from primary.com to the secondary domain (secondary.com), we are able to access resources on secondary.com server a until we make a call to secondary.com server b. We use TAI to enable communication between server a and server b. When we make a call to server b we receive two SMSESSION cookies as the image shows above for the secondary.com domain. One is persistent, one is transient.
2. Taking primary.com out of the picture entirely, if I call secondary.com and server b behind secondary.com, I see what is shown in the screenshot as well.
3. If I shut down server b on secondary.com and don't authenticate to primary.com, and call a garbage url (secondary.com/contextroot/garbage.html) I only receive the single transient cookie.
For scenario 1, the real issue is that when we get two SMSESSION cookies back IE doesn't send either one when server a behind secondary.com is called, resulting in a prompt for the user to login when the cookie provider determines it doesn't know who they are.
only one should be presented at a time. it could be cross domain sso somehow telling each domain they can trust one another.
if you conrtol both, try settting smzones... maybe abc as one zone and xyz as the other and setting up a cross zone trust
SSOZoneName and SSOTrustedZone
Security Zones for Single Sign-on - CA SiteMinder® - 12.52 SP1 - CA Wiki
that should help.
however i still do not see the domain of the smsession. really you should only hit this if you have .xyz.com and .abc.xyz.com
which means you need to fix your configuration.
The domains are identical for the SMSESSION cookies as reported by fiddler. I am replacing the actual domain with the word "mydomain".
SMSESSION 1 domain: .mydomain.com
SMSESSION 2 domain: .mydomain.com
There are no subdomains on either SMSESSION identifier.
never seen that before.
what in your set up can sent the set cookie directive?
Issue is resolved, mostly. Looks like the ACO for TAI was misconfigured for secondary.com server b and it was setting persistent cookies, while the rest of the app was dealing in transient cookies. IE has an issue with this apparently, when it received both persistent and transient set-cookie directives for the same name with the same domain, it freaked out and sent nothing. We did test that adding both primary and secondary to trusted sites appeared to to also resolve the issue for the single user, so we are assuming something about IE decided it was a security risk to send cookies when the situation occurred. Weird situation!
We corrected the ACO configuration and we still get two SMSESSION cookies, so that's still not idea, but at least IE is sending them back now and SSO seems fine.
Retrieving data ...