February 13, 2018 at 7:02 pm #20883ray.wangParticipant
I’ve been testing with OpenAM 5.5 on Ubuntu and here’s what I’m doing.
– Change my cookie domain in Global Services from openam.example.com to openam.example.com + .example.com
– Logout from the AM console
– Try to log back in
This use case doesn’t work for me as I simply get a login page that hangs at “Loading…”. I have tried clearing all of my browser data + cookies, switching browsers, and I’ve also tried using the /manager interface to reload OpenAM, but none of these allow me to log back in. The only thing that has allowed me to log back in is to go to /var/lib/tomcat8 and rm -rf openam, which then allows me to create a new profile for OpenAM, resetting all of my configuration (as expected).
Can someone please advise me on how I change my cookie domain without breaking everything?February 13, 2018 at 11:44 pm #20884Peter MajorModerator
Tomcat 8.5+ versions do not allow preceding ‘.’ character in cookie domains, so make sure you set the cookie domain to example.com. Also don’t configure both openam.example.com and example.com domains at the same time, having example.com as the only value should suffice.February 14, 2018 at 7:20 pm #20905ray.wangParticipant
I will give that a try.January 17, 2019 at 12:41 am #24497VSIN89319Participant
I am facing same issue but in AM6.0 on RHEL (aws instance). we had cookie domain set as “ec2-xx-xx-xx-xx.ap-abcdefg-x.compute.amazonaws.com“, we have changed it to “ap-abcdefg-x.compute.amazonaws.com” after which i am not able to login using amadmin. (Tomcat version 9). any pointers on resolving this issue.
i had to update the domain name back to original using ssoadm for me to proceed with my work.
VSFebruary 6, 2019 at 3:32 pm #24703william.heplerParticipant
There is a KB that covers this as well:
As of OpenAM 13.5, the cookie domain defaults to the full FQDN. Login will not succeed unless the cookie domain is set correctly.
See FAQ: Cookies in AM/OpenAM (Q. What does the cookie domain default to?) for further information about this change.
I had recently run into this as well. I’ll see if there is a way to clarify this more.February 12, 2019 at 11:38 am #24770rajeshsadhanalaParticipant
To handle the cookie domain issue, we have to change the files in the backend database.March 27, 2019 at 12:01 pm #25275sandeep_murthyParticipant
I am facing the same issue on AM 6.5. Could you please elaborate what backed files were changed? Thanks.
April 3, 2019 at 4:16 pm #25384william.heplerParticipant
- This reply was modified 3 weeks, 2 days ago by sandeep_murthy.
You should use ssoadm:
Change the default cookie domain:
$ ./ssoadm set-attr-defs -s iPlanetAMPlatformService -t Global -u [adminID] -f [passwordfile] -a iplanet-am-platform-cookie-domains=[domain]
replacing [adminID], [passwordfile] and [domain] with appropriate values.
Potentially they may have used an LDAP editor and found iplanet-am-platform-cookie-domains and changed this manually in the configuration store. But sssoadm would be cleaner.
You must be logged in to reply to this topic.