[SOLVED] RE: HELP Needed urgently- CAS no longer authenticating forprod serverafter server move

Wed Nov 21 12:06:44 EST 2007

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: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu]
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: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu]
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
	cas at tp.its.yale.edu
	http://tp.its.yale.edu/mailman/listinfo/cas

_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20071121/962f0fe8/attachment.html 