SSO Known Issues and Recommendations

We recommend you disable AD authentication in Configuration Manager to force SSO use and encourage pre-existing AD authentication users to start using SSO authentication.

AD Authentication can be re-enabled for troubleshooting and can coexist with SSO if AD authentication is also required.

For a consistent and reliable SSO experience, we recommend using the Identity Provider (IdP) in conjunction with Active Directory to Identity Provider (AD-to-IdP) synchronization.

SSO with MFA is only possible using IdP multi-factor authentication. The MFA setting in Configuration Manager applies only to SQL and Active Directory logins.

SSO currently supports multiple web consoles in a load-balanced configuration. This configuration is not part of the LogRhythm SIEM and would require a third-party hardware or software solution. The SSO configuration is part of the Authentication Service that is common to all Web Consoles. If you have multiple Web Consoles in a non-load-balanced configuration, you must choose one to use with SSO. You must specify which Web Console to use in the SSO configuration parameter Web Console Callback URL.

When the Web Console saves the SSO configuration, users may see the following sequence of statuses in the upper-right corner:

Yellow Disconnecting status.
Red Disconnected status.
Notification message: You have lost the live data connection. Please check your internet connection and refresh your browser.

Refresh your browser to reconnect the Web Console.

SQL Authentication must be enabled in Configuration Manager for SSO to work. SSO will fail if SQL Authentication is disabled.

When a user is auto-provisioned via SSO, the Description field in their Client Console Person record is populated with "Auto Provisioning <firstName> <lastName>".
The uniqueness determinant for user matching with LogRhythm SSO is the combination of first name and last name in the Name field of the Client Console Person record. SSO auto-provisioning fails when a second user happens to have the same unique combination of first name and last name that matches an existing Person record. Using first name and last name as the uniqueness determinant can cause issues when the same person has two or more logins (for example, Chris User the analyst, and Chris User the administrator of the SOC), or when two people have the same first name and last name.
- SSO user auto-provisioning for the second user fails because the first name and last name match an existing Name field in the Client Console Person record.
- It does not matter if the Login field is different (for example, Chris.User@company.com and Chris-Admin.User@company.com).
- The middle name is not used to determine uniqueness.

Workaround:

- Manually edit the user's Name field in the Person record (for example, change the first name to Joe-Admin so the resulting first name and last name combination is Joe-Admin User).
  Additional Issues:
  - This change may not be acceptable to a company's HR department.
  - If the user is part of AD Group-Based Synchronization, the AD admin must perform the manual edit because AD is the source authority for AD-synchronized users.