Suddenly all Single sign-on users fail to log in to a CA PAM SSO-enabled system with error "PAM-CMN-0926: Single sign-on authentication failed. Please contact your system administrator" without seemingly have done any change in the configuration.
Privileged Access Manager, all supported releases
PAM-CMN-0926 is a generic error covering a wide range of causes. It is impossible without further investigation to determine the root cause behind this problem. It is recommended to go to Configuration --> Diagnostics -->Diagnostic Logs --> Log Levels and set the CA PA as SAML SP Log Level to Verbose, then repeat the use case and observer the corresponding CA PAM as SAML SP log entries (log may be downloaded from the Download section under Diagnostic Logs)
The SSO process involves the exchange of an assertion request between PAM and the IdP (Azure, OKTA, SiteMinder...) where PAM is requesting for the IdP to authenticate a user. Once the IdP processes the authentication request, it sends back to PAM a completed information allowing (or denying) authentication, for PAM to authorize access to the resources it provides. The exchange implies the IdP sending back data to the source of the assertion (actually to a specific URL in the SP, the Assertion Consumer Service or ACS), for it to process it. The assertion received is validated by means of the IdP certificates provided and loaded to PAM with the IdP metadata, as loaded through the Configuration --> Security --> SAML --> SP Configuration --> Configured Remote SAML IdP page.
If anything in the process above fails (for instance if the assertion does not make it back to the ACS service, if the url the assertion is generated for does not macht correctly that of PAM, or if the certificates PAM has for the IdP are wrong, among other things), then SSO will fail
So one basic recommendation is to verify communication between the IdP and the SP, even before trying to log in as any specific user to PAM. To do that go to Configuration --> Security --> SP Configuration --> Configured Remote SAML IdP. Once in that screen, the IdP provider metadata loaded to PAM are present: selecting the checkbox near the configuration to be tested and hitting the TEST button should take the testing user to the IdP authentication page and upon successful authentication, Success should be reported.
The present article concerns one of the possible failure use cases: when either testing through the previous mechanism or through regular log in of a user, the following lines are obtained in the SP log
Mar 08 08:17:11 SAML_RP DEBUG [f0b59ea530] Validation with key #0 failed with exception: Unable to validate Signature
Mar 08 08:17:11 SAML_RP DEBUG [f0b59ea530] Validation with key #1 failed with exception: Unable to validate Signature
Mar 08 08:17:11 SAML_RP DEBUG [f0b59ea530] Validation with key #2 failed with exception: Unable to validate Signature
Mar 08 08:17:11 SAML_RP DEBUG [f0b59ea530] Validation with key #3 failed with exception: Unable to validate Signature
When this happens, PAM is unable to validate the assertion it has received from the IdP and therefore it cannot allow the authenticated user to proceed.
In general this error means that the certificate PAM has from the IdP provider is wrong because it has changed for whatever reason
To verify if this is the problem, please ask the IdP administrator to re-generate the IdP metadata and send them to the PAM administrator, for it to be reloaded in the Configuration --> Security -->SP Configuration --> Configured Remote SAML IdP.
That should resolve the issue.
In many occasions PAM is configured to download the IdP metadata automatically from the IdP. This is done by checking in Configuration --> Security -->SP Configuration --> Configuration the SAML IDP Metadata Refresh mode and set it to either Hourly or Daily. When this is checked and a URL is specified in "Metadata Refresh Source URL" in the metadata loaded tor the IdP under Configuration --> Security -->SP Configuration --> Configured Remote SAML IdP, PAM will try to access that URL to retrieve the IdP metadata again with the periodicity specified. Assuming such access is not possible from PAM at one point in time, it may occur that the updated configuration of the IdP does not make it to PAM, leading to this failure.
If this is the case one can either request the IdP administrator to send the updated metadata file or try to access the URL in the Metadata Refresh Source URL specified for the IdP and download it manually. This is also a good test to see if there is any actual problem with that URL which may be preventing automatic updates.