New article
Recently updated
Troubleshooting access and login issues
Who is this article for?Site Administrators who are attempting to troubleshoot access issues.
Site Admin permissions are required.
This guide will explain how to effectively troubleshoot these issues.
In this article:
1. Auditing logins
Login audits can be helpful when tracing back changes to the application or diagnosing access issues.
Creating an Audit Trail Query
Open the Audit Trail and select 'Log In' from the 'User Access' row. You will see three types of login:
- Login - Classic login.
- Login Browser - Browser login.
- Login SSO - Browser login via Single Sign-On.
By hovering over a row in the Audit Trail, a blue filter icon will appear at the beginning of the row. When selected, you can choose to filter the Results by the User or Date.
Exporting results
Click 'Audit Trail▼' and select 'Printable Version'. Select the results (Ctrl + A) and paste them into a blank spreadsheet (Ctrl +V).
Once the login data is in Excel, you can analyse it as required, like identifying dates where the number of logins dropped.
2. Login issues
Incorrect password lockout
After three failed login attempts, a User account will become locked. This is designed to prevent brute entry breaches of the system. This mechanism is separate between Browser and Classic.
You can tell if a User has been locked out by checking their notebook. It will display the following message:
Login failures are marked in the Audit Trail.
Browser
Classic
To resolve this, you can unlock the User manually from their notebook menu (in whichever application they are locked out of).
Incorrect Username
Users trying to log in with an incorrect username will see the following error: 'Unknown username or password. Please try again.'.
As this is the same error as for incorrect password attempts, the way to tell the issue is with the username is that the account will not be locked after three attempts (as the username isn't recognised by the system).
Incorrect User login attempts are not marked in the Audit Trail.
Inactive Users
Users whose account was made inactive will see the following error: 'This user is inactive. Contact your Site Administrator to have this user reactivated.'.
To resolve this, reactivate the User by selecting the 'Reactivate' option from their notebook.
Inactive User login attempts are not marked in the Audit Trail.
Permissions-based error
If a User doesn’t have the appropriate permissions to access a page or item, they will be met with an access error (even when accessing via a direct link):
To resolve this issue, make sure you have granted the User the correct Permissions.
IP Whitelisting error
If the User is outside of the org networ, they will encounter the following message: encountering the 'IP whitelisting is enabled for this site'.
To resolve this, make sure that you have whitelisted their IP address.
3. Password reset issues
As part of the troubleshooting process, you may ask a User to reset their password. There are a couple of issues that they may run into when trying to do so.
Reset email not received
To resolve this issue, make sure the User checks their Spam/Junk folders. They should also ask their IT department to whitelist our domain to make sure the emails can get through the filters.
You can also check the User's email address in their notebook to eliminate the possibility of typos causing the issue.
'Unfortunately, this email address is in use by more than one user...' error
If the User's email address is associated to more than one account, they will receive this error.
To resolve this issue, remove the email address from the account that isn't in use.
4. Single Sign-on issues
To help identify errors with Single Sign-Ons (SSO), you have view-only access to our SSO configuration page. This allows you to see the error logs, the IdP URL, and the certificate used.
To access the page:
- Open the Go To... menu.
- Hover over 'Site Admin' at the bottom of the menu.
- Select 'Manage SSO' (under 'Site Options').
SSO fails for specific User(s)
When SSO login fails for a specific User(s), this is usually due to the User attempting to login via SSO and not having a valid profile in Ideagen Risk Management.
The error logging and the Audit Trail can be used to diagnose these issues. A standard error message for this issue is '[Time/Date stamp]- No user found with email address [email address]; SSO Failed'.
A profile may be invalid if:
- There is no User profile configured for this User.
- There is a User profile but it has no email address.
- There is a User profile but it's not in a valid state to login (inactive).
- The email address has been used for multiple Users in the system.
To resolve this, ensure the User profile is valid for access.
SSO fails for all User(s)
When all Users are unable to login via SSO, this indicates an issue with the SSO configuration.
There are several variations for this issue, each one is a symptom of a different configuration error. They are all detailed below.
Redirect from the IdP login page fails.
If there is an error log indicating a failure for an individual User, troubleshoot using the above section.
If there are no SSO error logs, check that the IdP endpoint is set to SAML Consumer type, with a POST binding and that the URL is correct (‘https://<yoursitename>.pentanarpm.uk/cpmweb/sso/samlresponse’.)
There is a login failure referencing invalid attributes in the SSO error logs.
Ensure that the IdP has been configured to use email/mail claim only, as this is the only claim our system accepts.
Check the URL config in the IdP to ensure that the redirect is configured correctly to our POST-binding endpoint.
There is an invalid encryption error in the SSO Error logs.
Ensure that both parties are using valid, in date certificates (this can be checked in the metadata at the top of the SSO Admin page).
Ensure that the customer certificate being used is a valid signing certificate (this can be primary or secondary, provided it is valid and in date).
Refresh certificates in both the IdP configuration and the SSO configuration to ensure that there are no errors.
Users being forced to login to the IdP each time they access the site, even when they have a valid session open
Sessions time out, prompting a refresh of the login, so ensure that the open session is still active.
If the session is still active, check that the User is not accessing the application via the SSO login URL (https://<sitename>.pentanarpm.uk/cpmweb/login) as this will always take Users via the re-login process.
If this is correct, check the Global Encryption settings in your IdP, looking for the Integrated authentication on Intranet sessions option. This ensures that your IdP isn’t configured to request a new session every time the User tries to access the resource.