We recently enable SSO with long-lived TGTs (about 8 hours) for a portal project we have been working on. We started to receive a number of help desk calls where end users were stuck in an endless "login loop".
A user would enter the correct login and password, but would be taken back to the CAS login screen.
After some research, we determined that what is happening is as follows:
1) The user was successfully logged in to a CAS protected web app. The closed the browser tab without logging out. This caused the CASTGC cookie to remain in the browser cookie jar (the browser only clears the cookie when completely closed). The user never hit the /cas/logout URL.
2) Meanwhile, the TGT expired on the server overnight (its lifetime was set to 8 hours).
3) User attempts to login the next day. User is taken to CAS login screen, enters correct credentials. However, because they have an invalid CASTG, they are taken back to the login screen.
You can reproduce this behavior with a browser extension that allows you to edit cookies (e.g. Cookie Manager + for Firefox):
1) Log into 1 CAS protected app.
2) Edit CASTGC cookie so that it is invalid (e.g. add some random characters).
3) Attempt to access another CAS protected app. You will be taken to the CAS login screen since you don't have a valid ticket granting cookie.
4) No matter how many times you successfully log in, you are redirected back to the CAS login because CAS won't overwrite the bad cookie!
I think that CAS ought to overwrite the cookie if a login is attempted. I can't think of a good reason you wouldn't want to do this, but maybe you have some more insight?
In any event, this causes much confusion among end users who need to be told to navigate to the CAS logout URL manually.
Red Hat Enterprise Linux Server release 6.4 (Santiago)