Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Issues
  • #5009

Closed
Open
Created Sep 06, 2013 by Administrator@rootOwner

LDAP user white list and advanced LDAP searching.

Created by: samrocketman

Recently I've found a limitation of how gitlab handles LDAP to be a little cumbersome. I work for Drexel University and would like to hook our University LDAP into GitLab. However, we have more than 18k users in LDAP which means 18k users have the potential of accessing Gitlab. We're using it more as a tool to restrict to certain departments to foster collaboration. We are restricting GitLab by firewall to certain IP blocks and securing it with SSL but in my opinion that is not enough.

Therefore, being able to restrict LDAP users by using LDAP search queries for filtering by groups or by using a user white list would be best.

White list

The user white list would likely be easiest to implement. A user must exist in the whitelist and in LDAP in order for their authorization to be successful in GitLab.

LDAP search queries

If you support filtering LDAP queries here's an ldapsearch example of exactly what I mean.

$ ldapsearch -x -H ldap://example.com -b 'ou=people,dc=example,dc=com,o=internet' '(&(uid=user123)(ismemberOf=cn=gitlab,ou=groups,dc=example,dc=com,o=internet))' cn sn uid

Answer:

dn: uid=user123,ou=people,dc=drexel,dc=edu,o=internet
cn: FirstName Lastname
sn: Lastname
uid: user123

Here's what one would see when you query the gitlab group directly.

 $ ldapsearch -x -H ldap://example.com -b 'cn=gitlab,ou=groups,dc=example,dc=com,o=internet'

Answer:

uniqueMember: uid=user123,ou=people,dc=example,dc=com,o=internet

The gitlab group only contains records which point to other records. There is no actual user information stored in the gitlab group so it can't be used as a Base DN in the gitlab setup.

A combination solution of using LDAP groups and white listing.

Create a white list of users from an LDAP group. No complicated search filtering. Your white list can be dynamically updated as users are added/removed from the LDAP group. It will still be the case where users must exist in both LDAP and the white list in order to gain authorized access to GitLab.

Attempted Suggestions to get around this

  1. Synchronising LDAP groups to GitLab groups is not a good enough solution for user restriction. I've not used GitLab 6 EE yet but the way it is described doesn't appear to be a good solution for solving this problem.
  2. Setting initial user account creation to be limited to 0 repositories is a better solution so far and has thus been the best temporarily. However, there's still the problem of logged in users being able to access 'public' projects.
  3. Since we use CAS at the University I've been attempting to get omniauth-cas working (see #4997 (closed)). The idea of using omniauth is better because new users are created with disabled accounts and an Admin must enable their account before they get access. This is still not the best solution because there's potential for 18k+ users to create an account even if they can't log into it. omniauth would benefit from a white list in this case as well.
Assignee
Assign to
Time tracking