IBM Support

QRadar: Active Directory authentication modules deprecated from QRadar Console appliances

News


Abstract

Administrators who use Kerberos-based Active Directory (AD) authentication are being alerted that they need to transition to the Lightweight Directory Access Protocol (LDAP) to authenticate to QRadar. The underlying open source component of the Kerberos-based Active Directory (AD) is being removed as the component library is no longer supported. When administrators attempt to upgrade QRadar software, a new error message halts the installation when Active Directory authentication configurations are detected.

Content

About

IBM® is alerting QRadar administrators to transition from Kerberos-based Active Directory (AD) authentication to the direct Secure Lightweight Directory Access Protocol (LDAPS) implementation as the underlying open source component libraries for Active Directory are no longer supported. This technical note is intended to inform administrators that future versions of the QRadar® installer include a check to detect Kerberos-based Active Directory configurations. If the Active Directory module is configured, you must disable the Active Directory authentication module or configure LDAPS authentication before you attempt to upgrade to QRadar 7.4.1 fix pack 1 or QRadar 7.3.3 fix pack 5.

Urgency

IMPORTANT: Administrators with Active Directory through Kerberos-based authentication must configure LDAP or another authentication type in QRadar to avoid an interruption in service or extended maintenance hours. When Active Directory is detected, an error message displays to administrators to alert them that they must configure an alternate authentication type. Administrators cannot continue the software update on the QRadar Console until LDAPS or another configuration module is configured. This error message cannot be skipped or deferred as detection of a configured Active Directory module halts the software update.
We have detected that you currently use the Active Directory authentication module.
An underlying open source component of the Kerberos-based Active Directory (AD) support is out of  service. 
In order to increase reliability in future updates we have chosen to transition authentication from Kerberos-based 
AD support to the direct Secure LDAP (LDAPS) implementation. Follow the instructions at http://ibm.biz/BdqeYV to 
reconfigure for direct Secure LDAP, then restart the upgrade.
Figure 1: Error message displayed to administrators with Active Directory authentication enabled.

Affected products

The following QRadar versions are scheduled to have Active Directory authentication modules deprecated:

How to identify the issue

If Active Directory is detected when you attempt to upgrade QRadar administrators can confirm the QRadar Console is using Active Directory. Before you delete or change your authentication module, you can record the Server URL and Context fields as these values required to set up a new LDAP authentication module. 
  1. Log in to QRadar as an administrator.
  2. Click the Admin tab.
  3. Click Authentication.
  4. Review the General Authentication Setting tab to determine whether Active Directory is configured.image 5283
    Figure 2: Administrators with Active Directory selected for their Authentication Module cannot continue a software update until LDAP or another authentication type is selected.

    Results
    The QRadar installer halted the software update as it detected Active Directory configured as the Authentication Module in QRadar. Administrators can discuss with their Active Directory administrators on how to proceed with a transition to LDAPS authentication. Before you attempt to modify your authentication settings, record the Server URL and Context fields from your existing Active Directory configuration and review the configuration notes provided for LDAP or LDAPS configuration.

Configuration notes for administrators

This section includes reference information for LDAP configuration and notes for administrators. Administrators can review the documentation and notes provided here to get started.
Before you begin
  1. Review the LDAP configuration documentation for QRadar.
  2. Record the Server URL and Context values from your existing Active Directory configuration, these fields are required to set up LDAPS authentication.
  3. If you plan to use LDAPS (TCP/636 by default) an SSL or TLS certificate is required. You might need to contact your firewall teams to open required ports.
Configuring LDAP parameters
To closely map an existing Active Directory configuration to LDAP, you can configure the LDAP connection to use "Local" Authorization. Selecting 'Local' in the authorization module field allows existing users who previously authenticated to the system via AD can continue with the same capabilities after you configure the LDAP authentication module in QRadar.
  1. Click the Admin tab.
  2. Click System Configuration > User Management > Authentication.
  3. From the Authentication Module list, select LDAP.
  4. Click Add and complete the basic configuration parameters.
    LDAP parameter Description
    Server URL
    The DNS name or IP address of the LDAP server. The URL must include a port value.

    For example:
    • ldap://<host_name>:<port>
    • ldaps://<ip_address>:<port>
    SSL Connection Select True or False to specify whether Secure Sockets Layer (SSL) encryption is enabled. If SSL encryption is enabled, the value in the Server URL field must specify a secure connection.

    For example, ldaps://secureldap.mydomain.com:636
    Repository ID
    The Repository ID is an alias for the User Base DN (distinguished name) to avoid having to type a long string used when you enter your login details. When you have more than one repository in your network, you can place the User Base DN before the user name or you can use the shorter Repository ID.
     
    For example, the User Base DN is: CN=Users,DC=IBM,DC=com. You create a repository ID such as UsersIBM that is an alias for the user base DN.
    image of LDAP repository

    You can type the short repository ID UsersIBm instead of typing the following example of a complete User Base DN CN=Users,DC=IBM,DC=com.
    SSL Connection
    If the protocol is ldaps:
    • In the SSL Connection field, select True.
    • In the TLS Authentication field, select False.
    • The port must use the configured ldaps port for your organization (TCP/636 by default).
    • Administrators must configure certificates.
    TLS Authentication
    Transport Layer Security (TLS) encryption to connect to the LDAP server is negotiated as part of the normal LDAP protocol and does not require a special protocol designation or port in the Server URL field.
    If the protocol is TLS:
    • In the SSL Connection field, select False.
    • In the TLS Authentication field, select True.
    • The port must use the configured ldap port for your organization (TCP/389 by default).
    • Administrators must configure certificates.
    Search Entire Base
    • Select True to search all subdirectories of the specified Directory Name (DN).
    • Select False to search only the immediate contents of the Base DN. The subdirectories are not searched. This search is faster than one that searches all directories.
    LDAP User Field The user field identifier that you want to search on. You can specify multiple user fields in a comma-separated list to allow users to authenticate against multiple fields.

    For example, if you specify uid,mailid, a user can be authenticated by providing either their user ID or their mail ID.
    User Base DN
    The Distinguished Name (DN) of the node where the search for a user would start. The User Base DN becomes the start location for loading users. For performance reasons, ensure that the User Base DN is as specific as possible.
    For example, if all of your user accounts are on the directory server in the Users folder, and your domain name is ibm.com, the User Base DN value would be cn=Users,dc=ibm,dc=com.
    Referral
    Select Ignore or Follow to specify how referrals are handled.
     
    Important: Administrators transitioning from Active Directory authentication to LDAP can set the Referral option to Follow.
    Bind connection type
    • Anonymous bind
      Use anonymous bind to create a session with the LDAP directory server that doesn't require that you provide authentication information.
    • Authenticated bind
      If Authenticated Bind is selected, a dedicated bind user account can be created for this connection. QRadar can use this user for connecting and querying the LDAP server. For increased security, ensure that the user ID that is used for the bind connection does not have permissions to do anything other than read permissions for the LDAP directory.
  5. Click Test Connection.
  6. Select the authorization method Local.
  7. Click Save.
  8. Click Manage synchronization to exchange authentication and authorization information between the LDAP server and the QRadar Console.
  9. Administrators with multiple LDAP servers can repeat this procedure to add more servers to the list.
  10. Click Save Authentication Module.

    Results
    The configuration for LDAP or LDAPS is complete. Administrators can now schedule maintenance to upgrade the Console software. To locate release notes for QRadar appliances and find software downloads, see QRadar Software List 101. If you continue to experience issues with your software upgrade or the error message described in this technical note, open a case with QRadar Support.
 
 

[{"Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU008","label":"Security"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwtdAAA","label":"Upgrade"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Version(s)"}]

Document Information

Modified date:
12 November 2020

UID

ibm16253911