Slow performance with LDAP user.

[Facu Basgall]

Hello. I have integrated Wazuh with LDAP, but I notice that when I log in with a valid AD user, Wazuh responds much (much!) slower and takes much longer to process web requests.

With the default “admin” user, it works normally.

[Juan Felipe González Ortiz]

Hi Facu, I'll look into it and let you know what I find out.

[Juan Felipe González Ortiz]

Hi Facu,

Thanks for reaching out and reporting this behavior. It’s possible that the indexer is attempting to check other authentication backends before validating against LDAP, which can cause the login to feel much slower.

To better understand your setup, could you please share the following files (feel free to redact any sensitive information):

• /etc/wazuh-indexer/opensearch-security/config.yml

• /etc/wazuh-indexer/opensearch-security/roles_mapping.yml

[Facu Basgall]

Hi, I am sharing the requested files with you.

[Juan Felipe González Ortiz]

Here’s the English version of the response:

---

Hi Facu,

We’ve reviewed your case and, at first glance, your configuration looks correct. To move forward, our team will simulate an LDAP environment and test some scenarios.

In the meantime, could you share how many groups and users you currently have in your directory? This detail is important since the number of objects can directly affect the LDAP performance with Wazuh.

[Facu Basgall]

Hi! How many groups and users in the AD in general or in the Wazuh Admin and Wazuh Readers groups?

[Juan Felipe González Ortiz]

Hi, In the Wazuh groups, but also if it's possible the total amount of groups.

This is to be able to replicate an environment as similar to yours as possible.

[Facu Basgall]

Good.

I have in my AD approximately 4900 users, 9200 groups

But in the Wazuh Admin group I have only 7 users and in the Wazuh Readers group only 3 users.

[Juan Felipe González Ortiz]

Hi, most likely the poor performance is due to the users and groups issue. 

I'm going to set up an environment simulating that number of groups and users and let you know.

[Juan Felipe González Ortiz]

Hi Facu,

Thanks again for sharing the details of your environment. We’ve been reviewing the behavior and, as you mentioned, the large number of groups (around 9200) and users (about 4900) in your AD could be contributing to the performance degradation when logging in with LDAP accounts.

We are currently setting up a test environment that simulates a similar scale of users and groups in order to validate whether this is the main factor impacting the performance of Wazuh when authenticating via LDAP. Once we finish the simulation, we’ll be able to confirm and share possible optimizations or workarounds.

In the meantime, could you also let us know if the latency happens only during the initial login or if it also affects subsequent requests after authentication? That detail will help us narrow down whether the issue is strictly related to group resolution at login time or if it continues while handling queries.

We’ll keep you updated as soon as we have results from the simulation.

[Facu Basgall]

Hi Juan, thanks for your answer

The slowness in wazuh occurs in all requests or web browsing, it is not only a specific case of the login. 

[Juan Felipe González Ortiz]

We’ve been running some tests on our side to better understand the behavior you described with LDAP users being slower in the Wazuh web interface.

Using a local LDAP environment, we created a test user and compared API response times against the default admin user. We ran multiple benchmarks (20–50 requests per user, measuring both authenticate and GET /security/users/<user>). The results show that response times are consistently fast (<0.03s) for both users, regardless of whether they are local or LDAP. This suggests that the slowdown is not happening at the API/LDAP level, but rather somewhere else in the Wazuh web interface layer (UI rendering, role mapping, multiple API calls in parallel, etc.).

Since you mentioned your environment has around 4900 users and 9200 groups, it’s possible that the size of the directory and the number of groups per user could be adding overhead during role mapping or group resolution in the Wazuh Dashboard.

To help us narrow this down, could you provide:

• Whether the slowdown occurs only during login, or also when navigating the Wazuh Dashboard after login.

• If the affected LDAP user is a member of a very large number of groups.

• Any noticeable differences between local users (like admin) and LDAP users in terms of speed.

We’ve also attached a small script (compare_wazuh_users.sh) that you can run in your environment to benchmark login and user info retrieval times for specific users. This will help confirm if the slowdown is visible directly at the API level or only through the web interface.

How to use the script

1. Copy the attached file to your Wazuh server (or any host that can reach the API).

2. Make it executable:

chmod +x compare_wazuh_users.sh

Edit the file to set:

• SERVER="YOUR_WAZUH_IP"

• USER1 / PASS1 (e.g. admin)

• USER2 / PASS2 (e.g. your LDAP test user)

Run it

./compare_wazuh_users.sh

The script will generate a CSV file with all attempts and also print a summary with min, max, and average times per user/endpoint.

If you could share those results, along with a bit more detail about your LDAP setup, it would help us understand better where the slowdown comes from.

[Facu Basgall]

Hi! Thanks for waiting

This slowdown occurs when browsing the Wazuh dashabord

Unfortunately I don't have the information on how many groups the user belongs to.

I have run the provided script, I have attached the results, but I have not observed any drastic differences in the times.

A05762 is an LDAP user

I think I remember reading some time ago that you can configure Wazuh to increase the cache time with LDAP, can it be?

That is to say that it is not going to consult the AD all the time for the user, but to keep it in cache to reduce the times

Is this so? Can you help me with this configuration?

(note: maybe I'm wrong but I remember reading it some time ago)