LDAP group sync does not support nested groups
Summary
Using an IDM (Redhat) based LDAP server, syncing LDAP nested group is broken.
Steps to reproduce
In IDM a super group e.g. dev-all does not include all members of subgroups e.g. "dev-component1" as cn=member records. So if you try to sync a gitlab group with the super group "dev-all" and you are a member of the subgroup "dev-component", you end up being removed from the Gitlab group and the super group sync only direct members in this group.
In other tools like JIRA, in LDAP integration you can specify that group membership is not calculated from group side using cn=member, but is calculated from the user record using cn=memberOf records in LDAP. This way the tool can integrate smoothly with Redhat based IDM LDAP.
What is the current bug behavior?
Currently syncing Gitlab group with nested LDAP group results in syncing only direct members but not members of subgroup. If the user setting the sync up is a member of the subgroup, he/she will be removed from the Gitlab group since he is not a member of the LDAP group he/she is syncing.
What is the expected correct behavior?
Expected behaviour is to sync the super group members to the Gitlab group and don't remove the user who sets up the sync if he/she is a member of one of the subgroups.
Relevant logs and/or screenshots
In the logs, it shows that the LDAP sync is performed successfully
Results of GitLab environment info
$ gitlab-rake gitlab:env:info
System information System: Proxy: no Current User: git Using RVM: no Ruby Version: 2.5.3p105 Gem Version: 2.7.6 Bundler Version:1.16.6 Rake Version: 12.3.1 Redis Version: 3.2.12 Git Version: 2.18.1 Sidekiq Version:5.2.3 Go Version: unknown
GitLab information Version: 11.6.2-ee Revision: 308f077a Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: postgresql DB Version: 9.6.11 URL: http:// HTTP Clone URL: http:///some-group/some-project.git SSH Clone URL: git@:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: yes Using Omniauth: no
GitLab Shell Version: 8.4.3 Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-
Results of GitLab application Check
$ gitlab-rake gitlab:check SANITIZE=true Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 8.4.3 ? ... OK (8.4.3) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: 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 ... 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)
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... 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? ... yes Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) Projects have namespace: ... . . 6/2 ... yes 625/1321 ... yes . . Redis version >= 2.8.0? ... yes Ruby version >= 2.3.5 ? ... yes (2.5.3) Git version >= 2.18.0 ? ... yes (2.18.1) Git user has default SSH configuration? ... yes Active users: ... Elasticsearch version 5.6 - 6.x? ... skipped (elasticsearch is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
In other tools like JIRA, in LDAP integration you can specify that group membership is not calculated from group side using cn=member, but is calculated from the user record using cn=memberOf records in LDAP. This way the tool can integrate smoothly with Redhat based IDM LDAP. So an additional parameter for LDAP can be added to tune the group membership for LDAP servers that use same as Redhat IDM membership scheme.