### Summary LDAP group sync might get stuck without any error messages when domain restriction is configured for a group. ### Steps to reproduce 1. Configure LDAP on your GitLab instance. 1. Create an LDAP user without an email address. 1. In LDAP, Associate it with a cn that's used for LDAP Group Sync within GitLab. 1. Perform LDAP sync and then login with this user. Because there's no e-mail in LDAP, it will get some temporary email on the GitLab side like `temp-email-for-auth@gitlab.host`. 1. Create a top-level group within GitLab. 1. Configure [a domain name restriction](https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-group-access-by-domain) with any value besides `gitlab.host` for that top-level group. 1. Configure LDAP Group Sync between the top-level group and the cn used in step #3 1. Trigger a group sync and observe that not only the user isn't added, but group sync remains stuck for that group. ### What is the current *bug* behavior? Group sync is stuck, and there are no error messages that can point you in the right direction. ### What is the expected *correct* behavior? Group sync should fail with a descriptive error message or at least there should be some clear error message in the logs. ### Relevant logs and/or screenshots Nothing useful is shown in the logs while running the group sync. ### Output of checks #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> System information System: Ubuntu 20.04 Proxy: no Current User: git Using RVM: no Ruby Version: 3.1.5p253 Gem Version: 3.5.9 Bundler Version:2.5.9 Rake Version: 13.0.6 Redis Version: 7.0.15 Sidekiq Version:7.1.6 Go Version: unknown GitLab information Version: 17.0.4-ee Revision: 9dbd6804d1b Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 14.11 URL: https://gitlab.host.tld HTTP Clone URL: https://gitlab.host.tld/some-group/some-project.git SSH Clone URL: git@gitlab.host.tld:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: yes Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 14.35.0 Repository storages: - default: unix:/var/opt/gitlab/gitaly/gitaly.socket GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Gitaly - default Address: unix:/var/opt/gitlab/gitaly/gitaly.socket - default Version: 17.0.4 - default Git Version: 2.44.2.gl1 </pre> </details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> Checking GitLab subtasks ... Checking GitLab Shell ... GitLab Shell: ... GitLab Shell version >= 14.35.0 ? ... OK (14.35.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successful Checking GitLab Shell ... Finished Checking Gitaly ... Gitaly: ... default ... OK Checking Gitaly ... Finished Checking Sidekiq ... Sidekiq: ... Running? ... yes Number of Sidekiq processes (cluster/worker) ... 1/1 Checking Sidekiq ... Finished Checking Incoming Email ... Incoming Email: ... Reply by email is disabled in config/gitlab.yml Checking Incoming Email ... Finished Checking LDAP ... LDAP: ... Server: ldapmain LDAP authentication... Success LDAP users with access to your GitLab server (only showing the first 100 results) User output sanitized. Found 20 users of 100 limit. Checking LDAP ... Finished Checking GitLab App ... Database config exists? ... yes Tables are truncated? ... skipped All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Cable config exists? ... yes Resque config exists? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet) Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units) Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units) Projects have namespace: ... can't check, you have no projects Redis version >= 6.2.14? ... yes Ruby version >= 3.0.6 ? ... yes (3.1.5) Git user has default SSH configuration? ... yes Active users: ... 17 Is authorized keys file accessible? ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes Elasticsearch version 7.x-8.x or OpenSearch version 1.x ... skipped (Advanced Search is disabled) All migrations must be finished before doing a major upgrade ... skipped (Advanced Search is disabled) Checking GitLab App ... Finished Checking GitLab subtasks ... Finished </pre> </details> ### Additional investigations - The issue looks rather similar to https://gitlab.com/gitlab-org/gitlab/-/issues/348226, but in this case: - I was able to run `group.fail_ldap_sync!` without any errors. - `group.members.map(&:errors).map(&:full_messages)` did not show any errors at all. - We reproduced it on GitLab 17.0.4, also reproduced at the customer's environment with GitLab 17.4.2. <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->