IBM Support

QRadar: Best Practices for User Behavior Analytics - User Import



The User Import function of User Behavior Analytics (UBA) allows administrators to import and predefine users to be monitored within the application. There are various methods available for importing these users: LDAP or Active Directory query, QRadar reference table, and CSV file. With these imported users, administrators can coalesce multiple usernames to a single user, and configure display information to provide extra context when you monitor system activity. This document summarizes the capabilities of this function, and provides some suggestions for the initial configuration.


You can access the User imports wizard from the following locations:
  • The Admin Settings page (Admin Settings > User Analytics > User Importuser import location in admin settings page
  • The User Import icon in the top menu bar on the UBA dashboard.
    user import location in UBA dashboard
  • The Import User Data section on the UBA Settings page.
    User Import section in UBA settings

Resolving The Problem

Importing Users

User Import add page
There are three supported methods for importing users into UBA. Administrators can import users from any combination of these sources, and are allowed multiple configurations of the same type. For the step-by-step process on adding import configurations, see Importing Users.
The available import options are:
  1. LDAP Import - Synchronize external LDAP/AD users. Set UBA to poll from the server at regular intervals. For more information, see Importing users with LDAP or Active Directory.
  2. Reference table - Synchronize a QRadar reference table. Can set UBA to poll from the reference table at regular intervals. For more information, see Importing users from a reference table.
  3. CSV File - Import data from a CSV file. Can also export the data to a QRadar reference table. For more information, see Importing Users from a CSV file.
Note: UBA does not distinguish between sources once the users are imported. For example, if the administrator imports data from two Active Directory instances but an attribute has a duplicate value in both, UBA sees the attribute as not unique.

Tuning Imported Users

After you complete at least one user import configuration, administrators can refine and customize how the attributes are displayed through the Tuning Page.
The Tuning page is located within the User Import window, next to the Add button:
User Import menu
Here is an example of the Tuning UI in version 4.1.0:
User Import Tuning page
The tuning menu has two main sections:
  1. User coalescing - Choose one or more attributes (aliases) that are commonly used in events sent to QRadar. UBA monitors and associates an event to a user when the Username field matches any of the attributes. If there are shared values for any chosen attribute between users, UBA coalesces all duplicates into one user, so choosing unique attributes is recommended.
  2. Display fields - Choose which attributes are displayed in the User Details page. More than one attribute can be chosen for each field, but UBA only displays the first non-empty value. For a user, if the first attribute has a value, UBA display that value, but if not, then it moves on to the second attribute. These display fields are shown when you click a user in the UBA dashboard, as well as their User Details page.
    UBA display fields in different parts of the UI
    Note: For Machine Learning peer group models, UBA can use three display fields for grouping: Job Title, Department, and Custom group. The administrator can fill one or more of these display fields with an attribute for their peer group models. For more information, see Peer grouping requirements.
Attributes generally refer to the imported properties directly, but it is also possible to create custom attributes from the data. For more information on custom attributes and tuning, see Tuning user import configurations.

Troubleshooting User Import Configuration

My UBA dashboard is not importing users as expected. For example, one user has multiple unique-looking aliases, can't find a certain user, or the same user shows up on the dashboard more than one time.

In most cases, there might be some issues in the User Import Configuration. Here are a few common areas to check:
  • Are all of the User Coalescing aliases unique to that user? The exact tuning can vary depending on environment and the use of unique attributes for User Coalescing aliases are highly recommended. For example, all new hires might have the same email before they are assigned one in the system. If email is chosen as an alias, then all new hires would be combined into one user, even if another unique alias, such as SAMAccountName, is also chosen. Likewise, if one user has multiple accounts, make sure to select at least one common attribute as an alias to coalesce them properly.
  • Do the users exist in the import source? The User Import feature retrieves every user it can find from the import configurations. If a user cannot be found, double check the import configurations (LDAP filters, base DN, and so on) as well as the data source itself.
UBA will automatically try to update its user database after any changes. If the wrong attribute was chosen for user coalescing, the attribute can be removed and the users are immediately coalesced again after settings are saved. Likewise, editing a user import triggers a data import.

After you adjust the settings, if the users are still not displaying as expected, then a rebuild of the user database might be required. Administrators can either remove users from the problematic import configuration, then import the users again. The steps are detailed under Resolving the Problem in this UBA technote.

If issues still persist, contact IBM Support and open a case for the UBA application.

User Import FAQ

  1. What fields can be chosen as aliases?
    An alias needs to be any LDAP attribute that contains a username that might be extracted by log sources reporting to QRadar.  For example, the attribute sAMAccountName from Microsoft AD is a good choice as the value of it appears in Windows Authentication events.  Any other attributes in the LDAP storage used as login names are a good choice.  Attributes containing phone numbers, office location, cube assignments, and so on, are normally not good attributes to select as these values are not normally extracted as usernames by the DSMs in QRadar. Tip: If a DSM extracts a field with a username, you can use that LDAP attributes holding those same values as aliases in UBA coalescing settings.
  2. How does the user import from LDAP determine whether a field is unique?
    UBA takes a sample of 1000 records from the configured LDAP server and checks whether any attributes contain duplicated values between the 1000 records. It displays an icon next to each attribute in the sample display when non-unique values are detected. The following screen capture provides a sample though not the entire LDAP population.
    Example of a non-unique property
  3. Can I coalesce people from 2 imports who don't share an alias?
    No. Currently, the only way to combine two entities in UBA is if the LDAP attributes configured for alias shares an identical value. It is important to pick LDAP attributes that have unique values.
  4. What attributes can and cannot be imported? 
    Currently, binary data attributes are not supported.  All textual LDAP attributes can be selected for either as displaying information or as an alias.

Document Location


[{"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":"a8m0z000000cwt3AAA","label":"QRadar Apps"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Version(s)"}]

Document Information

Modified date:
01 March 2022