ldap_all_add_on_seat_sync_worker removes all active GitLab Duo seats
Summary
When LDAP is configured but duo_add_on_groups is not yet configured, the ldap_all_add_on_seat_sync_worker can remove all users from active seats for GitLab Duo in 18.3. I believe this was introduced in !200729 (merged)
In a customer case, LDAP is configured and we can see the worker ran without any additional configuration:
{"severity":"INFO","time":"2025-08-25T07:00:05.554Z","meta.caller_id":"GitlabSubscriptions::AddOnPurchases::LdapAllAddOnSeatSyncWorker","correlation_id":"f43c2f7a10ac6d03223075142b2b211f","meta.root_caller_id":"Cronjob","meta.feature_category":"seat_cost_management","meta.client_id":"ip/","add_on_purchase_id":2,"message":"Duo Bulk User Unassignment","response_type":"success","payload":{"users":[61,156,10,33,32,27,98,68,17,51,35,58,18,26,30,154,17,93,108,14,62,97,55,70,19,22,24,62,49,95,94,65,50,45,9,69,12,16,64,21,25,73,56,36,38,44,56,60,112,115,134,50,58,87,85,80,76,5,131,1,100,75,37,79,34,89,77,81,82,41,78,125,126,86,74,83,43,96,4,11,90,23,135,117,123,128,129,142,143,133,139,29,109,110,155,31,39,118,157,28]}}
{"severity":"ERROR","time":"2025-08-25T07:00:06.901Z","meta.caller_id":"GitlabSubscriptions::AddOnPurchases::LdapAllAddOnSeatSyncWorker","correlation_id":"f43c2f7a10ac6d03223075142b2b211f","meta.root_caller_id":"Cronjob","meta.feature_category":"seat_cost_management","meta.client_id":"ip/","add_on_purchase_id":2,"message":"Duo Bulk User Unassignment","response_type":"error","payload":{"errors":"NO_ASSIGNMENTS_FOUND"}}This only happened after upgrading to 18.3.
Duo provides a summary on why this happens:
If LDAP is enabled and there's an active Duo add-on purchase, but no duo_add_on_groups are configured, the worker will:
Start execution (passing both initial checks)
Call fetch_duo_member_dns_from_ldap which will return an empty Set since all providers will skip the group processing due to next if duo_add_on_groups.blank?
Process all LDAP users with this empty set of member DNs
Since no users will match the empty set, all LDAP users will be added to users_to_remove
The worker will then call BulkUnassignService to remove Duo access from all LDAP users
This means that if you have LDAP configured but don't specify any duo_add_on_groups, the worker will effectively remove Duo access from all LDAP users during its next run.
Steps to reproduce
Did not directly reproduce.
Example Project
What is the current bug behavior?
Users are removed from a GitLab Duo seat nightly when the ldap_all_add_on_seat_sync_worker runs without any configuration.
What is the expected correct behavior?
The worker should only run when duo_add_on_groups is configured in the gitlab.rb. Users should not have their seats removed from GitLab Duo.
Workaround
Admin > Monitoring > Background Jobs > Cron. Find ldap_add_on_seat_sync_worker_cron and click disable
Output of checks
GitLab Self Managed 18.3
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: \\\\\\\`sudo gitlab-rake gitlab:env:info\\\\\\\`) (For installations from source run and paste the output of: \\\\\\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\\\\\`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of: \\\`sudo gitlab-rake gitlab:check SANITIZE=true\\\`) (For installations from source run and paste the output of: \\\`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\\\`) (we will only investigate if the tests are passing)
Possible fixes
Patch release information for backports
If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.
Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.
High-severity bug remediation
To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.