External authentication guidelines
You can configure an external authentication provider to allow IBM® QRadar® to authenticate users without QRadar storing passwords locally for those users.
- Ensure that your external provider is trustworthy because you are delegating an important security decision to this external provider. A compromised provider might allow access to your QRadar system to unintended parties.
- Ensure that the connection to the external provider is secure. Choose only secure communications protocols, by using LDAPS instead of LDAP, for example.
- Consider whether you want to enable a local authentication fallback in case the external provider is unavailable. If the external provider is compromised, it might be used as a denial of access attack.
- The decision to configure an external authentication provider applies to all administrator and
users. There is no such thing as a
local-only userin QRadar.
- If you enable auto-provisioning of QRadar accounts, a compromised provider might be used to force the creation of a rogue QRadar account, so use caution when you are combining these features.
- QRadar users that do not
have an entry in the external provider are relying on the fallback feature to check the local
password. A compromised external authentication provider might be used to create a
shadowfor an existing QRadar account, providing an alternative password for authentication.
Local authentication fallback
Each non-administrator user can be configured for local authentication fallback. Local authentication fallback is turned off by default. If enabled, a non-administrator QRadar user can access the system by using the locally stored password even if the external provider is unavailable, or if the password in the external provider is locked out or is unknown to the user. This also means that a rogue QRadar administrator might change the locally stored password and log in as that user, so ensure that your QRadar administrators are trustworthy. This is also the case if an external authentication provider is not configured.
The default administrator account, named admin, is always configured for local authentication fallback by default. This prevents the administrative user from being locked out of the system, but also means you must ensure that the configured external authentication provider has the correct entry for the admin user, and that the password is known only to the authorized QRadar administrator. If you cannot maintain control of the admin entry in the external authentication provider, disable the admin account within QRadar to prevent unauthorized users from logging in to QRadar as admin. When you enable auto-provisioning, such as when you use LDAP group authentication, any user account that matches the LDAP query are created or reactivated with the appropriate roles as mapped. To prevent this from happening, disable auto-provisioning by using LDAP local.
For other privileged QRadar users (users with the admin role), you can choose on a user-by-user basis whether to enable local authentication fallback. The ENABLE_FALLBACK_ALL_ADMINS setting (disabled by default) can be used to force all privileged users to use local authentication fallback. If local authentication fallback is configured, the same considerations apply as for the admin account.
When you configure an external authentication provider and create a new user, that user doesn't automatically have a local password set for QRadar. If a user needs a local password, then you must configure local authentication fallback for that user. Local authentication fallback allows a user to authenticate locally if external authentication fails for any reason, including invalid passwords. Fallback users can then access QRadar regardless of the state of the external authentication.
Even if local authentication fallback is enabled for a user account, QRadar first attempts to authenticate the user to the external authentication module before it attempts local authentication. When external authentication fails, QRadar automatically attempts to authenticate locally if local authentication fallback is enabled for that user. User accounts cannot be configured only to authenticate locally when an external authentication provider is configured. For this reason, it is important that all QRadar user accounts correspond to an external authentication provider account of the same name associated with the same authorized user.
Ensure that the external authentication provider is trustworthy, as this configuration outsources a security decision and a rogue authentication admin can allow unauthorized access to your QRadar system. Make this connection in a secure way, by using the secure version of protocols (for example by using LDAPS rather than LDAP).
Local authentication fallback is not available with SAML authentication. No users are able to authenticate locally when you use SAML authentication.
When offboarding users, disable local authentication fallback for that user before you remove their authentication access from the external authentication provider.