We resolved the problem. Jboss on the service server needed to be restarted as it was still caching tickets prior to the move of the cas and ad server. Thus the error "Unable to validate ProxyTicketValidator" Thanks to all of you who responded. Serge
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Petro Sent: Wednesday, November 21, 2007 9:43 AM To: Yale CAS mailing list Subject: Re: HELP Needed urgently- CAS no longer authenticating forprod serverafter server move Serge, [ We are not using any CAS client on one of the application ] I'm not sure how to understand this in light of the stack trace you posted. This error message is generated by the Yale Java CAS Client: [ edu.yale.its.tp.cas.client.CASAuthenticationException: Unable to validate ProxyTicketValidator [[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null] [edu.yale.its.tp.cas.client.ServiceTicketValidator casValidateUrl=[https://login.domainname.com/cas/serviceValidate] ticket=[ST-48-sKW5zzvf0SMiXRGNnqdu] service=[https%3A%2F%2Fintranet.domainname.com%2Fsuite%2Fportal%2Fssodet ect.do] renew=false]]] edu.yale.its.tp.cas.client.CASReceipt.getReceipt(CASReceipt.java:52) ] The package edu.yale.its.tp.cas.client exists in the Yale Java CAS Client. The jar containing that package has been distributed under such names as casclient.jar http://www.mvnrepository.com/artifact/cas/casclient As I noted in a previous message, there's an, um, "misfeature" where it fails to include the error message captured by the ProxyTicketValidator in the exception generated in CASReceipt. This is easily rectified by applying the change I posted yesterday on-list. This misfeature is not the cause of your ticket validation problems, but it is impairing getting a quality error message about whatever the real problem is. The logging in the PHP CAS Client is quite excellent. What log messages is that client generating when the PHP wiki application fails to validate the ticket? Are the applications attempting to use CAS able to themselves DNS resolve the CAS server? Can you wget the CAS server URLs over https from those boxen? Do they have web browsers you could use to manually validate a CAS ticket and see what problems you encounter? Note that the login portion of the CAS interaction in browser-mediated, such that so long as the end user's browser can resolve and reach both application-using-CAS and CAS-server, all is well, but the ticket validation portion of the CAS interaction absolutely requires that the application-using-CAS be able to itself resolve and reach the CAS server over HTTPS. That's likely the missing piece here. Andrew Andrew, Thanks for your reply, I'm not sure if this is SSL related because the server was working fine after the power outage we had last week. It's just that this issue erupted only today after we moved the servers offsite following after the outage. We are not using any CAS client on one of the application, it's a java hack that our developers did to integrate our software and the other application that we use with cas is wiki and that as well we did a hack and it's using phpCAS, other than that I'm just puzzled by the whole thing. So both applications are failing to authenticate. Thanks Serge -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Petro Sent: Wednesday, November 21, 2007 1:04 AM To: Yale CAS mailing list Subject: Re: HELP Needed urgently- CAS no longer authenticating for prod serverafter server move Serge, The error you report could be caused by a bad SSL certificate on the CAS server, or by the client applications otherwise failing to trust the SSL certificate presented by the CAS server (e.g., improperly installed cert). It could be caused by the client application boxes resolving via DNS (or a hosts file) servers other than the ones you think they're resolving. Exactly what version of the Java CAS Client are you using? If you aren't using 2.1.1, dropping it in *might* get you slightly better error messaging, though that's a stretch. Exactly what configuration do you have in your web.xml configuring the CASFilter? In particular, are the client filters properly configured such that the service= value they present at cas/login and at cas/serviceValidate are the same? The stack traces you post look "sanitized", with domain names replaced to protect the innocent. That's fine, but that does mean that I can't tell whether *that's* the problem. The Java CAS Client, especially in its 2.1.1 version, included a fair amount of Commons Logging statements. Do you have a logger configured? Can you crank it up to TRACE level? Does it report anything helpful? Much to its detriment, the Yale Java CAS client code tends to obscure the underlying cause of error when it generates this "Unable to validate ProxyTicketValidator" message. That's probably my fault. That should be fixed, even as a tiny tactical change to Yale Java CAS Client 2.1.1 for release as a 2.1.1.1... Andrew Andrew Petro Unicon, Inc. Serge Bianda wrote: We had a power outage in our building, so we decided to move our servers offsite (Kerberos server (AD)and CAS Server as well). We changed IP addresses and updated all DNS entries, however when we try to log into the site that used to be authenticated by CAS, we get the following error: ------------------------------------------------------------------------ - HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Unable to validate ProxyTicketValidator [[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null] [edu.yale.its.tp.cas.client.ServiceTicketValidator casValidateUrl=[https://login.domainname.com/cas/serviceValidate] ticket=[ST-48-sKW5zzvf0SMiXRGNnqdu] service=[https%3A%2F%2Fintranet.domainname.com%2Fsuite%2Fportal%2Fssodet ect.do] renew=false]]] edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:381) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte r.java:81) root cause edu.yale.its.tp.cas.client.CASAuthenticationException: Unable to validate ProxyTicketValidator [[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null] [edu.yale.its.tp.cas.client.ServiceTicketValidator casValidateUrl=[https://login.domainname.com/cas/serviceValidate] ticket=[ST-48-sKW5zzvf0SMiXRGNnqdu] service=[https%3A%2F%2Fintranet.domainname.com%2Fsuite%2Fportal%2Fssodet ect.do] renew=false]]] edu.yale.its.tp.cas.client.CASReceipt.getReceipt(CASReceipt.java:52) edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilt er.java:455) edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:378) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte r.java:81) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs. ------------------------------------------ We're still on 2.0.12 with CAS and it's been working fine until the move, we had planned on upgrading, but now is not the time to focus on upgrade, we need the site up first. Thanks Serge _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
