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
  • #7017

Closed
Open
Created May 23, 2014 by Administrator@rootOwner

LDAP login failed with "Invalid credentials" if `user_filter` is non empty after upgrade to 6.9

Created by: raabf

If user_filter: in config/gitlab.yml is set, every LDAP login fail with

Could not authorize you from LDAP because "Invalid credentials". 

Upgrade

This issue occurs after upgrading to 6-9-stable. If you do a downgrade back to v6.9.2 the login will work fine again.

Environment

I use Gitlab with OpenLDAP.

My config/gitlab.yml (LDAP part):

ldap:
    enabled: true
    host: 'localhost'
    port: 389
    uid: 'uid'
    method: 'plain' # "tls" or "ssl" or "plain"
    bind_dn: ''
    password: ''
    allow_username_or_email_login: false
    base: 'ou=people,dc=example,dc=org'
    user_filter: '(objectClass=inetOrgPerson)'

Tests

I have tested it with following user_filter (wich all works on v6.8.2)

  • will fail: user_filter: '(&(objectClass=inetOrgPerson)(memberof=CN=gitlab-login,OU=groups,dc=example,dc=org))'
  • will fail: user_filter: '(objectClass=inetOrgPerson)'
  • works: user_filter: ''

Logs

here I try to log in with mustermm and user_filter: '(objectClass=inetOrgPerson)'

Gitlab

nothing spacial, the login will be registered.

Started POST "/users/auth/ldap/callback" for 192.168.123.40 at 2014-05-23 18:09:29 +0200
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"cF6HkKQE8OXjmMOyYentZg9o4r1LC4dGcludc8owbg4=", "username"=>"mustermm", "password"=>"[FILTERED]"}
Redirected to https://gitlab.example.org/users/sign_in
Completed 302 Found in 15ms (ActiveRecord: 0.0ms)
Started GET "/users/sign_in" for 192.168.123.40 at 2014-05-23 18:09:29 +0200
Processing by Devise::SessionsController#new as HTML
Completed 200 OK in 58ms (Views: 36.3ms | ActiveRecord: 0.0ms)

openLDAP (slapd)

This the OpenLDAP log. This is the interesting part. Although I tried to login with mustermm the log says that raaba will try to login and fails with err=4. I tried different accounts, but every time raaba occurs in this log. The log-in with raaba also produce the same error.

May 23 18:09:29 easyStore slapd[22344]: conn=2734 fd=13 ACCEPT from IP=[::1]:37025 (IP=[::]:389)
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=0 BIND dn="" method=128
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=0 RESULT tag=97 err=0 text=
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=1 SRCH attr=namingContexts supportedLdapVersion altServer supportedControl supportedExtension supportedFeatures supportedSASLMechanisms
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=1 ENTRY dn=""
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=2 SRCH base="ou=people,dc=example,dc=org" scope=2 deref=0 filter="(objectClass=inetOrgPerson)"
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=2 ENTRY dn="uid=raaba,ou=people,dc=example,dc=org"
May 23 18:09:29 easyStore slapd[22344]: conn=2734 op=2 SEARCH RESULT tag=101 err=4 nentries=1 text=
May 23 18:09:29 easyStore slapd[22344]: conn=2734 fd=13 closed (connection lost)

Here is the same log with a higher log level.

Commit

The relevant commit seems to be e9d4587f . If I comment out the line

#filter:   Gitlab.config.ldap['user_filter'],

the login works fine again like in v6.8.2. After commenting out the line, I tried to log-in with an user who should be filtered by user_filter, so the filter is still active and works. All command outputs or logs here are made with the line NOT comment out.

Application Checks

bundle exec rake gitlab:ldap:check RAILS_ENV=production

This output is like expected. Only the users who match the filter are shown (eg. some users are missing because of the filter):

Checking LDAP ...

LDAP users with access to your GitLab server (only showing the first 100 results)
DN: uid=raaba,ou=people,dc=example,dc=org  uid: ["raaba"]
DN: uid=mustermm,ou=people,dc=example,dc=org       uid: ["mustermm"]

Checking LDAP ... Finished

bundle exec rake gitlab:check RAILS_ENV=production

nothing spectial. all tests passed.

bundle exec rake gitlab:env:info RAILS_ENV=production

System information
System:         Ubuntu 12.04
Current User:   git
Using RVM:      no
Ruby Version:   2.0.0p299
Gem Version:    2.0.7
Bundler Version:1.6.2
Rake Version:   10.3.1
Sidekiq Version:2.17.0

GitLab information
Version:        6.9.0
Revision:       f0a32c6
Directory:      /home/git/gitlab
DB Adapter:     mysql2
URL:            https://gitlab.example.org
HTTP Clone URL: https://gitlab.example.org/some-project.git
SSH Clone URL:  git@gitlab.example.org:some-project.git
Using LDAP:     yes
Using Omniauth: no

GitLab Shell
Version:        1.9.4
Repositories:   /home/git/repositories/
Hooks:          /home/git/gitlab-shell/hooks/
Git:            /usr/bin/git
Assignee
Assign to
Time tracking