ay 06, 2010 5:46 PM
> To: cas-dev@lists.jasig.org
> Subject: Re:[cas-dev] Clearpass DotNetCasClient Proxy Ticket error
>
>
> Thats for the quick reply Scott!
>
> CAS firewall: I have confirmed with the security team that there are
no
> outbound firewall rules in effect
The other test node on the same subnet is not getting those socket timeout
errors. We'll look again at the host that's giving them. There is a concrete
test we can make using curl.
On May 7, 2010, at 4:46 AM, Marvin Addison wrote:
> My money is on a firewall issue. Socket connect timeouts almo
My money is on a firewall issue. Socket connect timeouts almost
always are caused by the sending host not being able to complete the
TCP handshake, which is a classic symptom of the recipient firewall
dropping the initial SYN. If your firewalls are configured to drop
instead of report a closed po
Generally, these errors fall into one of five categories:
1. Wrong callback url. I.e. its not one that's actually listening for the
PGT.
2. Callback URL is not returning an appropriate response nor is it over
HTTPS (by default, we only accept certain response codes [i.e. 200, and some
other ones]
Scott Bolan is correct. There are no outbound firewall rules between the CAS
server and his test station.
On May 6, 2010, at 2:45 PM, Scott B wrote:
>
> Thats for the quick reply Scott!
>
> CAS firewall: I have confirmed with the security team that there are no
> outbound firewall rules in eff
Is your CAS server allowed to "call back" to your own personal machine?
There may be outbound firewall rules in effect.
On Thu, May 6, 2010 at 4:35 PM, Scott B wrote:
>
> I am working on getting clearpass working with CAS. At this point I am
> unable to get a proxy ticket from CAS. I am able
I am working on getting clearpass working with CAS. At this point I am
unable to get a proxy ticket from CAS. I am able to authenticate to CAS but
the GetProxyTicketFor() request causes a java.net.SocketTimeoutException on
the CAS server.
I have attached the web.config file, CAS server logs, Tr
