IBM Support

QRadar: Security considerations for configuring external authentication accounts

Flashes (Alerts)


Abstract

As a QRadar® administrator, is there guidance for configuring external authentication such as LDAP?

Content

As previously indicated in technical note 566407 QRadar: External Authentication Fails Due to Password Fallback Change for Administrators (Updated 30 August 2019), IBM® QRadar® includes functionality to selectively enable local fallback for users when external authentication is enabled.

 

Considerations for local fallback

QRadar® supports integrating with various external authentication providers to make authentication easier for users. As a backup, administrators can configure local fallback authentication and enable it for key users. Care must be taken to ensure that the external authentication provider is trustworthy, as this configuration outsources a security decision and a rogue authentication admin can compromise your QRadar system. It is important to make external authentication connections in a secure way, such as using the secure version of protocols. Example, administrators can use ldaps rather than ldap.
 
The following examples illustrate potential security concerns when fallback authentication is improperly configured within QRadar.
 
When external authentication is configured, all login attempts are first sent to the external authentication provider. If the request fails or cannot be made, QRadar moves to local fallback for the user if enabled. Local fallback can occur when the external provider cannot be reached, such as network connectivity issues, or if the user cannot be authenticated due to external provider account lockout or incorrect password. 
 

Example 1:

Alice is an administrator of QRadar. Normally Alice authenticates to QRadar with their LDAP username and password. Mallory compromised the LDAP server and disabled Alice’s account. Alice is able to log in by using local fallback authentication.
 
Since fallback authentication is relied on whenever the external provider does not successfully validate a user, it is important to disable local fallback or the account entirely when you terminate QRadar access for a user to prevent them from using the fallback.

 

Example 2:

Mallory no longer requires access to QRadar. Alice removes Mallory’s QRadar user role in LDAP, but did not disable Mallory’s account or local fallback. Mallory can still log in using local fallback.
 
When external authentication is enabled, it is not possible to have a local only user, as every login request is first sent to the external authentication provider. It is critical for QRadar Administrators to validate that every QRadar user account corresponds to a matching LDAP user, otherwise a rogue external authentication admin could create a matching account in LDAP, with an alternative password.  It is not possible to configure QRadar to use mixed authentication modes, when external authentication is enabled it is not possible to have a local only account.

 

Example 3:

Bob leaves the default QRadar admin user account enabled after setting up LDAP, and uses local authentication fallback to access the QRadar account, since they do not have an LDAP user called admin. Mallory has an LDAP user called admin that was created by the domain administrator, but is not supposed to have access to QRadar. Mallory is able to use the LDAP credentials for the admin user to access QRadar.

 

Deployment Best Practice

In QRadar® deployment with external authentication enabled, administrators can take the following actions to limit access to only authorized users:
 

[{"Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwsyAAA","label":"Admin Tasks"}],"Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Version(s)"}]

Document Information

Modified date:
12 November 2020

UID

ibm16367391

Page Feedback