Better handling of Rate Limited LDAP Servers

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Cloud-based LDAP servers often have query rate-limits. When the rate limit is reached during a user or group sync, users can get blocked or removed from the relevant group. Adding an LDAP configuration option for rate_limit would allow GitLab to batch queries in a way that fits within the ratelimits thus preventing users being blocked or having their membership revoked.

Problem to solve

Users get blocked or have their membership revoked when query rate limits are reached with rate-limited LDAP servers. A user should only sign in with LDAP again in order to have their memberships reinstated. However, there are other impacts while the membership is revoked/blocked:

Proposal

One way to resolve this would be to add a "batching per hour" configuration option. This could be difficult to manage, for example if there are 200 users and 20 groups to sync:

  • If the rate limit is 60/hour, we would batch the daily sync to be over 4 hours (60, 60, 60, 20).
  • However group sync runs every hour as well so it would need to be coordinated as (40u+20g, 40u+20g, 40u+20g, 40u+20g, 40u+20g)
  • There are also LDAP queries when a user signs in so we would need to be well below the rate limit to allow for this.

I may be over-complicating things but wanted to point out the potential flaw in my proposed approach.

Intended users

Feature Usage Metrics

Does this feature require an audit event?

No need for audit events for this feature

Edited by 🤖 GitLab Bot 🤖