Hello Tom,

6.4.3.x has been improved in terms of these operations.

My advice is to plan an upgrade or test it in a test environment first.

Thanks.

Regards,

Luciano Testa

We had experienced severe performance issues due to LDAP operations. It turned out that it had to do with groups - we have hundreds of groups in eDirectory and each user has up to about 50 group memberships. This caused user search operations from AA in LDAP take nearly 20s or timeout after 20s.

Our workaround was to put the few groups we need in AA in a separate container, and limit the scope were AA looks for groups to this container.

Is possibly what you are observing related to groups too?

That’s correct; we faced the same issue in the early versions of AAF (5.x), which prompted us to discontinue the use of groups entirely. We haven’t defined any search-based criteria for groups. In this context, the main concern is the extensive number of bind, query, and unbind operations required to retrieve user data.

Hi Luciano,

That’s good news! Although the release notes do not mention it, it’s great to hear that improvements have been made to the LDAP operations. Can you provide more insights into these improvements?

Hi Luciano,

I’ve upgraded a test environment to version 6.4.3.2, but the number of LDAP bind operations per OSP login remains the same. Additionally, the previously mentioned number of 21 was incorrect; it is actually 14 bind/query/unbind operations per OSP login. We use OSP only for step-up authentication, so I’m unsure why there needs to be so much communication with the LDAP repository.

As mentioned earlier, this behavior is putting a significant load on our LDAP repository back-end nodes. Do you have any idea how we can reduce this to more manageable levels? The configured user for the repository can maintain a pool of connections where the bind has already occurred. It’s not necessary to unbind and rebind after each query operation.

Hi Tom,

I confirmed with Development that the OSP does not perform LDAP operations with AA. It's AA that does that.

In any case, can we get a set of logs? Perhaps you can open a ticket with TS and we can follow up there.

Thanks.

Regards,

Luciano Testa

Hi Luciano,

Thank you for your response!

The fact that OSP itself does not make direct calls to the LDAP backend was so implicit for me that I didn’t mention it. Of course, the interaction with the LDAP backend happens via Aucore, and OSP uses the Aucore API.

I focused specifically on OSP, but it’s possible that the usual flow (Create Endpoint > Get Chains > Logon > Login) could result in multiple calls to the LDAP backend.

I will further extend the test setup with our own implementations to see if I can link the number of LDAP backend calls to the specific API calls. I’ll compile this information along with the OSP logs, and for that, I will create an SR.

Thanks. I think we have to see this more in detail and perhaps bring it to Development. Let me know the ticket number once you have it.

Regards,

Luciano