Skip to content

Dashes not supported in CN for LDAP Group Sync on first login

Summary

When a customer has dashes in their LDAP group CN, i.e. CN=ldap-group-dash, these aren't correctly parsed during the user's initial log in, and the user isn't synced with the appropriate LDAP groups. They are synced once a scheduled instance-wide LDAP sync is run.

Customer ticket reporting this issue: https://gitlab.zendesk.com/agent/tickets/137552 (internal use only)

For an initial LDAP login, the Group Sync is done via the update_memberships method in EE::Gitlab::Auth::LDAP::Access. The CNs for the sync are collected from the LDAP Person memberof attribute, and parsed via RegEx:

def cn_from_memberof(memberof)
  # Only get the first CN value of the string, that's the one that contains
  # the group name
  memberof.match(/(?:cn=([\w\s]+))/i)&.captures&.first
end

However, the above RegEx does not support dashes, and will parse incorrectly if they are present. I tested this in the rails console:

memberof = "CN=ldap-group-dash,OU=organization,DC=example,DC=com"
memberof.match(/(?:cn=([\w\s]+))/i)&.captures&.first
=> "ldap"

Steps to reproduce

  1. You have an LDAP user that is a member of CN=ldap-group-dash,OU=organization,DC=example,DC=com LDAP group
  2. Log into GitLab for the first time with this user
  3. A banner will display LDAP sync in progress. This could take a few minutes. Refresh the page to see the changes. but no group sync will occur
  4. On the scheduled LDAP group sync, the user will be correctly synced

What is the current bug behavior?

If an LDAP group CN contains dashes, it won't be parsed correctly for the initial log in Group Sync, and the user won't be synced on initial login. This does not effect the scheduled group sync.

What is the expected correct behavior?

Support dashes in the LDAP group CN for a successful group sync on initial log in.

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:		Ubuntu 16.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.6.3p62
Gem Version:	2.7.9
Bundler Version:1.17.3
Rake Version:	12.3.3
Redis Version:	3.2.12
Git Version:	2.22.0
Sidekiq Version:5.2.7
Go Version:	unknown


GitLab information
Version:	12.4.2-ee
Revision:	a3170599aa2
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	10.9
URL:		https://blunceford-omnibus-test.do.gitlap.com
HTTP Clone URL:	https://blunceford-omnibus-test.do.gitlap.com/some-group/some-project.git
SSH Clone URL:	git@blunceford-omnibus-test.do.gitlap.com:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers:


GitLab Shell
Version:	10.2.0
Repository storage paths:
  • default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 10.2.0 ? ... OK (10.2.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 ... 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: ... LDAP is disabled in config/gitlab.yml


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: ...
2/1 ... yes
10/2 ... yes
4/3 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.6.3)
Git version >= 2.22.0 ? ... yes (2.22.0)
Git user has default SSH configuration? ... yes
Active users: ... 3
Is authorized keys file accessible? ... yes
Elasticsearch version 5.6 - 6.x? ... skipped (elasticsearch is disabled)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

  1. Support dashes by Replacing the RegEx for the cn_from_memberof method with:
def cn_from_memberof(memberof)
  # Only get the first CN value of the string, that's the one that contains
  # the group name
  memberof.match(/(?:cn=([\w\s-]+))/i)&.captures&.first
end

Code base: https://gitlab.com/gitlab-org/gitlab/blob/v12.4.3-ee/ee/lib/ee/gitlab/auth/ldap/person.rb

  1. Could there be other characters in the CN that this RegEx doesn't support?

  2. Should we only support whitespace and word characters in the CN? In that case, we can update the documentation to reflect this change.

Edited by Blair Lunceford