Skip to main content

Hi,

In Active Directory, the default value for maximum number of results is 1000. That implies one must ask for pagination if the request could return more than 1000 results. (with ldapsearch the option is -E pr=1000/noprompt)

The Centreon code doesn’t make use of pagination for LDAP request and so, if we let the “Synchronize LDAP on login” option activated, the login of users is stuck a few minutes (between 2 and sometime 5!), which is not something acceptable. Also, if the group that interest us is after the 1000th result then it won’t appear in the form to configure an access group.

It’s important to note that when I execute the two requests (users & groups) manually with the ldapsearch command, with pagination, they never take more than a few second to execute although the about 1500 results I get. So maybe it’s not only the no use of pagination that is problematic with Centreon’s LDAP code…

To sum it up :

Is it possible for Centreon to make use of pagination for LDAP request to support results with more than 1000 records ? If not, is it possible that the user LDAP synchronization doesn’t block the login?
 

Peut-être en rapport :
 

$ cat sql-error.log*
2022-06-29 09:54|0|0|SQLSTATETHY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction QUERY : UPDATE contact SET
contact_ldap_dn = :userDn,
contact_name = :userDisplay,
contact_email = :userEmail,
contact_pager = :userPager,
ar_id = :arId
WHERE contact_id = :contactId, null
2022-06-29 09:55|0|0|SQLSTATETHY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction QUERY : UPDATE contact SET
contact_ldap_dn = :userDn,
contact_name = :userDisplay,
contact_email = :userEmail,
contact_pager = :userPager,
ar_id = :arId
WHERE contact_id = :contactId, null
2022-06-29 10:57|0|0|SQLSTATETHY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction QUERY : DELETE FROM contactgroup_contact_relation
WHERE contactgroup_cg_id = :cgId, null
2022-06-24 14:33|0|0|SQLSTATETHY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction QUERY : DELETE FROM contactgroup_contact_relation
WHERE contactgroup_cg_id = :cgId, null
2022-06-24 14:33|0|0|SQLSTATETHY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction QUERY : DELETE FROM contactgroup_contact_relation
WHERE contactgroup_cg_id = :cgId, null


Je précise qu’il s’agit de Centreon 22.04 (package centreon-web-22.04.0-2) sur RHEL 8
 


Hi @Stéphane 

To help us, what is your current size in terms of users on your LDAP directory, groups and the average number of groups per user?

This will allow us to build a test platform most closely resembling your case.

A few years ago, not all LDAP directories supported paging. If it is now, it will be easier for us when implementing.

Regards,


Hi,

We’re at 12561 users and 1562 groups. The number of users is very high because we have service accounts in the same OU than the human accounts (that is a problem in itself maybe).

I don’t know for the average groups per user but some users may belong to 50 or more groups.


Updated idea statusNewDiscussion ongoing

@Stéphane do you know that you can disable synchronisation on login and use a cron to made synchronisation? 


Yes I know. This is what I’m doing. I also know there is a synchronization that is done at a hardcoded (!) value of 3600 seconds.

But the problem I’m referring to seems to be the cause for some other problems with ACL. I won’t open yet another issue but recently I had an user which is in a LDAP group that happen to be after the 1000th result (I can see that in doing the request with ldapsearch) : although the LDAP group is linked to the access group and I did all the synchronization, the user doesn’t get the permissions he should have. I have to link its contact directly to the access group, then it works.

I can’t be sure but I guess fixing the “can’t get more than 1000 LDAP results per query” would fix many of the LDAP problems that the people opened issues for. Fixing this bug obviously means that Centreon is able to ask for pagination when doing LDAP query. Once again : the LDAP/AD server requires that the client ask for pagination for such requests.

The LDAP related code is a critical part of Centreon imo, because although SSO or OpenID exist, they can’t manage group membership afaik.


Updated idea statusDiscussion ongoingNeeds Votes