Federated Sign-In Module Timeout Errors

PAM Federated Sign-In Module – Timeout, Connection Forbidden or 403 Errors.

 

After deploying the PAM Federated Sign-In module (FSM), you may receive generic Timeout or 403 errors in your browser or log files if it was not properly configured.

 

We assume that after adding the Federated Sign-In you can login to it successfully but then the PAM page does not appear. Instead, these generic exceptions appear in the log or in your browser.

 

After authentication by the Federated Sign-In it generates a ticket and redirects the browser to the PAM WEB Application. The WEB Application then takes this ticket and validates it with the same FSM before generating the page.

To accomplish this the PAM WEB Application, from the computer it is installed, connects to a URL at https://company.com/cas (with the ticket to validate and its own URL as parameter).

The error indicates that this call fails. The important event here is that it is not the browser from your workstation that makes this call but PAM WEB app from the computer where PAM is installed.

First, to validate tickets with the FSM, PAM should know it’s a load balancer URL.

This value is defined using the following parameters in the $PAM_HOME/web/conf/catalina.properties file:

Copy 
cas.managed.path=https://company.com
cas.server.name=https://company.com
cas.server.prefix=https://company.com/cas

 

Check these parameters to ensure they are accurate for your deployment. If they are not, please modify them as required and when finished, save the file then restart the PamManagement (Windows) or pammanager (Linux/Unix) service to complete the configuration.

Based on our experience with other users, we have found that configurations that may cause this behavior are the following:

  • DNS on the PAM computer works differently and does not resolve cas.managed.path to the computer where the load balancer resides. For example, there is a host record making it a localhost. We recommend pinging the load balancer to see how it resolves.
  • Routing behind the load balancer is configured in such a manner that it does not route traffic from inside the farm to the load balancer front end. For example, it short cuts it back to the localhost again to a non-SSL connection or the traffic from inside the farm comes to the wrong interface of the server with reverse proxy where the load balancer does not listen.
  • The load balancer does not process requests that came from inside the farm in the right way like it processes requests from the outside.