QRadar: LDAP and local admin user logins are slow or time out

Troubleshooting

Problem

When authentication is configured to use LDAP, logging in to the QRadar GUI takes more time than expected. The same issue can also be seen when a user logs in with the built-in admin account. This article guides administrators through common issues with slow authentication and timeout issues in the QRadar LDAP configuration.

Symptom

Users might experience longer wait times than expected at the login page:

Cause

Common causes for slow logins:

The base statement in the LDAP configuration is too wide.
The LDAP server is a Microsoft Active Directory, which uses referrals.
There might be more than one domain controller in use.
- If so, add certificates from all DCs to use secure authentication (SSL/startTLS).
The incorrect DNS value (for example DC-01.xyz.xyz.com) from certificate is used in ldapURL value to use secure authentication (SSL/startTLS).
- Example:
```
openssl x509 -in /opt/qradar/conf/trusted_certificates/ad_ldap_server.pem -text |grep DNS
   DNS:DC-01.xyz.xyz.com, DNS:xyz.xyz.com, DNS:xyz
```

Diagnosing The Problem

To diagnose whether the issue is caused by the LDAP configuration settings, follow both of the diagnosis procedures in order.

Scenario 1: Base statement is too wide

Log in to your Windows® server hosting Active Directory (domain controller).
Open Windows PowerShell.
To verify the user permissions, replace <username> with the actual user name in the following command:
```
Get-ADUser -Identity <username> -Properties *
```
Note the DistinguishedName returned by the query, which indicates the path to the user. For example, analyst1 has a path of CN=Users,DC=test,DC=internal:
```
DistinguishedName                    : CN=analyst1,CN=Users,DC=test,DC=internal
```
Verify that the Distinguished Name is correct for your LDAP server in the User Base DN field.

Results
The previous output states that the path to the analyst1 user is CN=Users,DC=test,DC=internal. However, the base statement uses DC=test,DC=internal. Therefore, the query must sort through all the entries and not specifically in Users.

Scenario 2: Referrals
LDAP authentications that use Active Directory implementations do not contain the entire record information for the user requested. When this request occurs, the system sends a response to use a referral. If the follow option is selected in the user interface, the request can introduce delay until the record is provided.

Resolving The Problem

Depending on which diagnosis step proved to be the source of the issue, follow the matching resolution procedure.

Scenario 1: Base statement too wide

Use the Distinguished Name that you noted down in the diagnosis steps from scenario 1 to update the User Base DN.
Click Save.
On the Admin tab of the QRadar UI, click Deploy Changes.

Result
Logins no longer delay or timeout. If you continue to experience issues with slow LDAP authentication or errors, contact QRadar Support.

Scenario 2: Referrals

Review the Server URL field to determine whether ports TCP/389 or TCP/636 are used when the Referral field is set to follow.
Verify with your Domain Administrator which port is the correct one. Administrators with LDAP ports configured to use TCP/389 or TCP/636 might be experiencing a reported issue where an LDAP port is required. For more information, see: APAR IJ27713: UNABLE TO LOGIN USING ENCRYPTED LDAP WITH MICROSOFT AD SERVICES ON STANDARD LDAP PORTS
Update the Server URL field to use Global Catalog ports (startTLS/3268 or SSL/3269).
Example:
Click Save.
On the Admin tab, click Deploy Changes.

Results
Under the Basic Configuration, if the Referral option is selected, we bind to port 389, and the base distinguished name of the operation is not in this directory but the domain controller has knowledge of another LDAP directory where it might be found, then the client is referred to next domain controller that is presumed to hold the requested object. If you bind to Global Catalog port 3268, your search includes all directory partitions in the forest, and if attribute is not in the Global Catalog, no further referrals are made. If you continue to experience issues with slow LDAP authentication or errors, contact QRadar Support.

Advanced troubleshooting

There could be some database performance or long searches running that cause system performance issues. For more information, see Searching in QRadar efficiently.

If you see any delay in traffic, you can try to run tcpdump from console to LDAP server to look at the timestamps in the traffic. It can indicate whether the LDAP response is slow, traffic is slow, or QRadar processing is slow:

tcpdump -nnvvAs 0 -i any host ldap_server -U -w - | tee ldap_server.pcap | tcpdump -r -

Sample output from previous command where we can see whether there is any response at all, or a delay from the LDAP server:

tcpdump: listening on any, link-type EN10MB (Ethernet), capture size 262144 bytes
reading from file -, link-type EN10MB (Ethernet)
14:08:42.861114 IP QRadar-console.local.52088 > WIN.qradar.ldap: Flags [S], seq 2977245408, win 42340, options [mss 1460,sackOK,TS val 2151629460 ecr 0,nop,wscale 12], length 0
14:08:43.862430 IP QRadar-console.local.52088 > WIN.qradar.ldap: Flags [S], seq 2977245408, win 42340, options [mss 1460,sackOK,TS val 2151630462 ecr 0,nop,wscale 12], length 0

Related Information

QRadar: How to find the User Base and Group Base DN information when using LDAP

IJ27713: UNABLE TO LOGIN TO QRADAR USING ENCRYPTED LDAP WITH MICROSOFT AD SERVI…

Document Location

Worldwide

[{"Type":"MASTER","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"}],"ARM Case Number":"TS007343853","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Tips