User identity server authentication error: "An error has occurred which may have invalidated your authentication"

  • 7005830
  • 23-Apr-2010
  • 19-Mar-2013

Environment

Novell Access Manager 3.1 Linux Novell Identity Server
Novell Access Manager 3.1 Windows Novell Identity Server

Situation

Novell Identity Server (IDP) setup in a cluster. The baseURL for this cluster configuration is tcp 443. However, the load balancing switch fronting the IDP servers translates the incoming browser/client requests from TCP 443 to 8443, which corresponds to the TCP port the IDP server is listening on. The IDP cluster 'Level four switch port translation' is enabled.

The users seem to be able to authenticate without problems. However users complain of randomly being presented with the following error message on the browser:

"An error has occurred which may have invalidated your authentication. Please try refreshing the browser page. If this error persists, please close this browser window, open a new browser, and login again."

When only one device exists in the cluster, the issue never happens. It seems that the error only happens when a user authenticates to one IDP server successfully, and then is bounced by the load balancing switch to another server in the cluster.

Resolution

Run iptables on the IDP server to translate TCP port 443 to 8443. See 'Translating the Identity Server port at https://www.netiq.com/documentation/novellaccessmanager31/identityserverhelp/data/b6fyxpk.html for more details.

Additional Information

When a user is bounced from one IDP server to another, request proxy'ing takes place. For example, if a user authenticates successfully to IDP1 and is then bounced by the load balancer to IDP2, IDP2 must proxy the request over to IDP1. The debug catalina.out log file shows the fact that we must forward/proxy the request below:

Must proxy HTTP request to other cluster member. This cluster member: 10.7.37.53, cluster member for this user: 10.27.138.46. </amLogEntry>

<amLogEntry> 2010-04-22T20:54:11Z INFO NIDS Application: AM#500105001: AMDEVICEID#2DBB0916E204B10A: AMAUTHID#DC964C17685FCB5296054687230D1921:  Forwarding HTTP request to cluster member at URL: https://10.27.138.46:443/nidp/app </amLogEntry>


The URL scheme and port (
https://10.27.138.46:443/nidp/app) is obtained from the baseURL. In the above case, the baseURL was 443 even though all requests from the load balancer came in on tcp 8443 (we could essentially have left the config at the default with a baseURL of 8443 with no issues). Since iptables was not running, the incoming request into TCP 443 had no listener and was rejected. The following catalina.out debug entry could be visible immediately after the proxy statements:

<amLogEntry> 2010-04-22T17:43:58Z DEBUG NIDS Application:
Method: NIDPProxyableServlet.myDoGetWithProxy
Thread: http-10.7.37.53-8443-Processor4

Exception message: "Connection refused"
     PlainSocketImpl.java, Line: -2, Method: socketConnect
     PlainSocketImpl.java, Line: 333, Method: doConnect
     PlainSocketImpl.java, Line: 195, Method: connectToAddress
     PlainSocketImpl.java, Line: 182, Method: connect

Adding the iptables translation port addressed the mapping and requests were passed to the application.

Note: When proxy'ing requests from one IDP to another, an SSL handshake is performed whereby certificates are validated. Make sure that the keystores are in sync and include the appropriate server andtrusted root certificates.