Hi,

Want to bring in some more information about what I found regarding the 
intermittent login issue we are seeing on CAS 3.6.0 with ldap backend, and 
Oracle Db for ticketing. We enabled more logging and also removed ldap pooling 
to just remove the possibility that the ldap connections were not the problem.  
So again this happens intermittently user goes to a Site and attempts to login, 
they are presented with the login page again and only by closing the browser 
and clearing the cache are they able to access the page.

After enabling the logging I found that information is being posted back to the 
CAS application and the user is being authenticated but the error I'm seeing is 
the following:

2015-08-11 17:15:48,838 TRACE 
[org.jasig.cas.web.flow.TerminateWebSessionListener] - <Entering method 
[sessionStarted with arguments [[[RequestControlContextImpl@184f6711 
externalContext = 
org.springframework.webflow.mvc.servlet.MvcExternalContext@4f7998f, 
currentEvent = success, requestScope = map['response' -> 
org.jasig.cas.authentication.principal.Response@1b827dd5, 'serviceTicketId' -> 
'ST-9927-7JMySenzWiQQodUjhmok-hostname'], attributes = map[[empty]], 
messageContext = [DefaultMessageContext@1413390f sourceMessages = map[[null] -> 
list[[empty]]]], flowExecution = [Ended execution of 'login']], 
[FlowSessionImpl@7a071214 flow = 'login', state = 'redirectView', scope = 
map['service' -> http://clientsite.fiu.edu/login/cas.php, 'credentials' -> 
[username: null], 'warnCookieValue' -> false, 'ticketGrantingTicketId' -> 
'TGT-6516-qjmXYvQi4XV5ndgE32t3hqQAe9WeKv9qeeOIEbctCaVmargYif-hostname']]]]>
2015-08-11 17:15:48,839 DEBUG 
[org.jasig.cas.web.flow.TerminateWebSessionListener] - <Error getting service 
from flow state.>
java.lang.IllegalStateException: No active FlowSession to access; this 
FlowExecution has ended

So the user is then stuck on the login page and unable to go anywhere. Now this 
issue is intermittent I had the user close their browser and they were able to 
login with no problem. If I revert our envionrment back to 3.4.7 we have no 
problems what so ever.  So it doesn't seem to be anything relating to tomcat, 
ldap, oracle or even the f5.  I saw an earlier thread regarding the error above 
where they commented out the webflow:flow-execution-listeners from the 
cas-servlet.xml and it helped resolved the issue.

Any thoughts.

thanks!

___________________
Juan Quintanilla
UTS - Enterprise Group
305-348-6573
[email protected]
________________________________________
From: Juan Quintanilla <[email protected]>
Sent: Thursday, July 30, 2015 1:23 PM
To: [email protected]
Subject: Re: [cas-user] CAS Intermittent login issue

Thanks, so found out some more information regarding our load balancers. The 
timeout for the current LB  configuration is less than the 5 minute CAS session 
timeout so I thought maybe the previous LB had a longer timeout session and 
that is why we never saw the issue when CAS 3.4.7 was running there but then we 
saw that LB had a smaller session time out.  So that burst my bubble, I thought 
that the LB was expiring the session before CAS reached its session timeout.  
So I would expect to see that more on the old LB since its timeout was 60 
Seconds but we never ran into the issue.



___________________
Juan Quintanilla
UTS - Enterprise Group
305-348-6573
[email protected]
________________________________________
From: Michael O Holstein <[email protected]>
Sent: Thursday, July 30, 2015 12:48 PM
To: [email protected]
Subject: Re: [cas-user] CAS Intermittent login issue

This is the relevant bits in log4j.xml that I use when trying to sort through 
stuff .. note that it creates big files in a hurry so change the size on your 
appender rollover to something like 50mb. You can also create a new appender 
name for the extra verbose debug stuff and just change the appender-ref entries 
to whatever you called the extra appender (if you are archiving prod logfiles 
and don't want to archive the debug stuff with username/password).

<logger name="org.springframework" additivity="true">
        <level value="ALL" />
        <appender-ref ref="cas" />
    </logger>

    <logger name="org.jasig" additivity="true">
        <level value="ALL" />
        <appender-ref ref="cas" />
    </logger>

The value ALL is the lowest possible (below even TRACE .. so literally 
everything) and the additivity means any child of the logger inherits the same 
property .. so the above logs all the springframework as well as all of the cas 
stuff.

Depending on how your SSL is configured as long as you have the private key 
(which you obviously do) you can use Wireshark to decode the SSL traffic and 
see the underlying HTTP .. so you can tcpdump to a file and examine later. Once 
you figure out where it craps out you can start Tomcat with the debugger turned 
on and attach to it so you can set breakpoints in your IDE to examine what data 
is coming/going .. but that is more of a realtime affair once you find and can 
reproduce the problem.

Michael Holstein
Cleveland State University
________________________________________
From: Juan Quintanilla <[email protected]>
Sent: Thursday, July 30, 2015 12:19 PM
To: [email protected]
Subject: Re: [cas-user] CAS Intermittent login issue

But I would assume that when the web flow starts over again the jession is lost 
it should let the user in.  In our case the user will not be able to login 
until they clear their cache and close their browser.  So even though we see a 
post in the access logs its not a guarantee that any user information actually 
reached the server.  Would decreasing the cas session timeout from the default 
5mins or increasing the timeout help in any way.


So in order to see if the user information is reaching the server during the 
post is it better to enable debugging on:

<logger name="org.jasig.cas.web.flow">

    <level value="INFO" />

  </logger>


 or

<logger name="org.springframework.webflow">

    <level value="INFO" />

  </logger>

Thanks!
___________________
Juan Quintanilla
UTS - Enterprise Group
305-348-6573
[email protected]
________________________________________
From: Andrew Morgan <[email protected]>
Sent: Thursday, July 30, 2015 12:03 PM
To: [email protected]
Subject: Re: [cas-user] CAS Intermittent login issue

The behavior you describe is exactly what happens when the JSESSION is
lost and the login ticket cannot be validated.  The web flow starts over
when that happens.

        Andy

On Thu, 30 Jul 2015, Juan Quintanilla wrote:

> The other interesting part is the fact that I see a post in the Tomcat access 
> logs but no user information in the cas.log.  Would that be an indication 
> that the user information within the sesison was not properly received or 
> what logging can I enable to verify that the user info was passed. Usually in 
> the logs I only see the entries after they have authenticated into ldap so it 
> never reaches that part.
>
>
>
> Thanks!
>
>
> ___________________
> Juan Quintanilla
> UTS - Enterprise Group
> 305-348-6573
> [email protected]<mailto:[email protected]>
>
>
> ________________________________
> From: Juan Quintanilla <[email protected]>
> Sent: Thursday, July 30, 2015 11:19 AM
> To: [email protected]
> Subject: Re: [cas-user] CAS Intermittent login issue
>
>
>
>
>
>
> Prior to having the environment on the F5 we had the users test against the 
> servers individually and there was no problem but then again the issue does 
> not always happen.  I have tried to reproduce the issue myself but have not 
> been able to.  So we didn't see the problem until we had more users accessing 
> the system once it was on the F5.  Our previous CAS environment 3.4.7 is 
> running on a Cisco Ace if I'm not mistaken and there were no problems there.  
> We have sticky sessions enabled based on the ip address.
>
>
>
>
> ___________________
> Juan Quintanilla
> [email protected]<mailto:[email protected]>
>
>
> ________________________________
> From: Michael O Holstein <[email protected]>
> Sent: Thursday, July 30, 2015 11:00 AM
> To: [email protected]
> Subject: Re: [cas-user] CAS Intermittent login issue
>
>
> I've noticed this as well, but if you use Chrome/Firefox in debug mode you'll 
> see the JSESSION ID as a cookie in either case so I don't think that matters.
>
>
> Even though you've only got one app server I'd bet the F5 has stickyness 
> configured (and you will need it) but how exactly it's being done might be 
> screwing with your app. Have you tried setting up something simple like 
> cas-sample-java-webapp against the inside address (bypass the F5) and see if 
> the problem still exists?
>
>
> We ended up forgoing a Cisco ACE in favor of two Nginx boxes and HAProxy/VRRP 
> as well as load balancing out the back .. for pretty much the same reasons .. 
> plus it's much easier to troubleshoot when you have control over the whole 
> path.
>
>
> Michael Holstein
>
> Cleveland State University
>
>
> ________________________________
> From: Christopher Myers <[email protected]>
> Sent: Thursday, July 30, 2015 10:38 AM
> To: [email protected]
> Subject: Re: [cas-user] CAS Intermittent login issue
>
> One thing to check - does the CASified application have the correct IP 
> address for the CAS server? We had something similar happen when we put our 
> CAS environment behind our Barracuda, and one of our hosted third-party 
> applications still had the old DNS entry cached.
>
> Chris
>
>
>
>
>>>> Juan Quintanilla <[email protected]> 07/30/15 9:29 AM >>>
>
> Hi,
>
>
>
> We are implementing CAS 3.6.0 using ldap authentication, with oracle for the 
> ticket registry, and tomcat 8.  We have the environment running on an F5 load 
> balancer but currently with only one web server in the loop.  I just wanted 
> to ask if any have encountered intermittent issues with logging into an 
> application using CAS.
>
>
>
> What I'm encountering is a user hits the cas login page after being 
> redirected by the client application but after they enter their credentials 
> they are redirected to the login page with the login information cleared. If 
> they try again logging again the process just repeats, if they enter bad 
> credentials no error message is displayed on the screen or even in the logs. 
> If the user closes their browser and clears their cache they are able to 
> login.
>
>
>
> In the Tomcat access logs we notice that there is a post during that 
> transaction but we didn't see a jessionid in the url string associated with 
> the post.  We are removing ldap pooling and extending the cas session timeout 
> in the web.xml to see if maybe their session is expiring. It does not happen 
> all the time its sporadic so it makes it difficult to troubleshoot.  We have 
> talked to our networking team but they don't seem to see any problems on 
> their side, they have just extended the session timeout. Our last resort 
> would be to take the environment off the F5 and see if that helps or place 
> the old environment on the F5 to see if the problem persists on that 
> environment then we can narrow it down the issue being on the F5 load 
> balancer. Since the problem does not always happen we having a hard time 
> determining whether the problem is with the load balancer or some 
> configuration on the CAS/Tomcat side.
>
>
>
> Has anyone encountered something similar, any suggestions will really help.
>
>
> ___________________
> Juan Quintanilla
> [email protected]<mailto:[email protected]>
>
>
> --
> You are currently subscribed to [email protected] as: 
> [email protected]
> To unsubscribe, change settings or access archives, see 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=-iNdYBOtAzGOq2iqp68NvZd48uVjq3RYhUSTSOwP-hw&s=UhbKdLiKiH1dWDoIBTUyJ0Ys79eyXgz8yaFmaHy2Zu0&e=
>
> --
> You are currently subscribed to [email protected] as: 
> [email protected]
> To unsubscribe, change settings or access archives, see 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=-iNdYBOtAzGOq2iqp68NvZd48uVjq3RYhUSTSOwP-hw&s=UhbKdLiKiH1dWDoIBTUyJ0Ys79eyXgz8yaFmaHy2Zu0&e=
>
> --
> You are currently subscribed to [email protected] as: [email protected]
> To unsubscribe, change settings or access archives, see 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=-iNdYBOtAzGOq2iqp68NvZd48uVjq3RYhUSTSOwP-hw&s=UhbKdLiKiH1dWDoIBTUyJ0Ys79eyXgz8yaFmaHy2Zu0&e=
>
> --
> You are currently subscribed to [email protected] as: [email protected]
> To unsubscribe, change settings or access archives, see 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=-iNdYBOtAzGOq2iqp68NvZd48uVjq3RYhUSTSOwP-hw&s=UhbKdLiKiH1dWDoIBTUyJ0Ys79eyXgz8yaFmaHy2Zu0&e=
>
> --
> You are currently subscribed to [email protected] as: [email protected]
> To unsubscribe, change settings or access archives, see 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=-iNdYBOtAzGOq2iqp68NvZd48uVjq3RYhUSTSOwP-hw&s=UhbKdLiKiH1dWDoIBTUyJ0Ys79eyXgz8yaFmaHy2Zu0&e=
>

--
You are currently subscribed to [email protected] as: [email protected]
To unsubscribe, change settings or access archives, see 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=-iNdYBOtAzGOq2iqp68NvZd48uVjq3RYhUSTSOwP-hw&s=UhbKdLiKiH1dWDoIBTUyJ0Ys79eyXgz8yaFmaHy2Zu0&e=

--
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=--AtaQTrdS2AbfuzDPQi4CegNfGLl-Qix4YFy4pN6bU&s=snEHAVZN_O-9TAiRyKhPzxGyYnsGmyOWZW44vHi8KUQ&e=

--
You are currently subscribed to [email protected] as: [email protected]
To unsubscribe, change settings or access archives, see 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=--AtaQTrdS2AbfuzDPQi4CegNfGLl-Qix4YFy4pN6bU&s=snEHAVZN_O-9TAiRyKhPzxGyYnsGmyOWZW44vHi8KUQ&e=


--
You are currently subscribed to [email protected] as: [email protected]
To unsubscribe, change settings or access archives, see 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ja-2Dsig.org_wiki_display_JSG_cas-2Duser&d=AwICAg&c=1QsCMERiq7JOmEnKpsSyjg&r=NauC5-J1X4CCd25sdSxQCA&m=mcEYrlsPyMzRqAxzoj5VqRHVOZInkCiba6GsRI9DAiQ&s=on-aHgj54lEyZtL4YkBjY_NnuOZgiMg_3eERFybezeU&e=


-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to