Environment
Novell Access Manager
Novell Access Manager 3.0
Novell Access Manager 3.0 Service Pack 3
Novell Access Manager has been configured with:
Novell Access Manager 3.0
Novell Access Manager 3.0 Service Pack 3
Novell Access Manager has been configured with:
- Two Novell Identity Provider servers (NIDPs) building an IDP cluster
- Two Linux Access Gateway servers (LAGs) building a LAG cluster
- Both clusters have been placed behind a layer 4 switch for load balancing and fail over
- A basic Authorization injection policy has been configured for the problem related accelerator
Situation
- After the Novell Access Manager setup has been updated with from service pack 2 to service pack 3 users seem to use their authenticated session due to a content switch to another LAG initiated by the layer 4 switch.
- Restarting the browser seems to solve the problem temporarily
Resolution
Re-assign the Certificate assigned to the accelerator hosting the embedded service provider
Additional Information
Troubleshooting:
The Embedded service provider (NESP) did not use the same certificate both LAGs. The security context for authenticated users will be locally stored on a LAG by making use of a session cookie.
If a given user which already authenticated will hit a LAG cluster member which does not already store any security context for that user the LAG will send out a query (Sending DMessageBus Message: Node: Get All) with the users session ID retrieved from the cookie to all possible cluster members in order to retrieve information about the users security context.
Any LAG cluster member being able to provide this information will send out a response message (DMessageBus Message Response: and Actual response objects returned:[number of returned objects]) with the information on where to retrieve the requested session information.
The actual session information will be distributed over the synchronous SOAP back channel hosted on the embedded service provider (NESP). If the Certificates used on the embedded service provider are not the same the establishment of the SOAP Back channel will fail. For the situation this TID has been written the process was looping on retrieveing the injection policy information from a LAG cluster member
- From the NIDP "logging" configuration screen enable "File Logging", "Echo To Console" and "Trace Logging". The NESP running on the LAG will inherit the logging setting from the NISP. Switching the Application and Liberty "Component File Logger Levels to debug should be enough
- Reproduce the problem once more and retrieve the "/var/opt/novell/tomcat4/logs/catalina.out" from all ivolved LAG members
- search the log files for the "Match NOT Found!" error message.
The Embedded service provider (NESP) did not use the same certificate both LAGs. The security context for authenticated users will be locally stored on a LAG by making use of a session cookie.
If a given user which already authenticated will hit a LAG cluster member which does not already store any security context for that user the LAG will send out a query (Sending DMessageBus Message: Node: Get All) with the users session ID retrieved from the cookie to all possible cluster members in order to retrieve information about the users security context.
Any LAG cluster member being able to provide this information will send out a response message (DMessageBus Message Response: and Actual response objects returned:[number of returned objects]) with the information on where to retrieve the requested session information.
The actual session information will be distributed over the synchronous SOAP back channel hosted on the embedded service provider (NESP). If the Certificates used on the embedded service provider are not the same the establishment of the SOAP Back channel will fail. For the situation this TID has been written the process was looping on retrieveing the injection policy information from a LAG cluster member