8

I'm trying to set up LDAP authentication with GitLab (version 7.12.2 installed on Ubuntu 14.04 amd64 on a VM, Omnibus set up). I've edited my gitlab.rb file to look like the following:

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
 main: # 'main' is the GitLab 'provider ID' of this LDAP server
   label: 'LDAP'
   host: '********'
   port: 389
   uid: 'sAMAccountName'
   method: 'plain' # "tls" or "ssl" or "plain"
   bind_dn: 'CN=********,OU=********,OU=********,DC=********,DC=***'
   password: '********'
   active_directory: true
   allow_username_or_email_login: false
   block_auto_created_users: false
   base: 'DC=********,DC=***'
   user_filter: ''
EOS

This results in the dreaded "Could not authorize you from Ldapmain because "Invalid credentials"." error. I've tried, for the username (in the bind_dn variable): "johnsmith@example.com" (email based on username), "John Smith" (full name) and "johnsmith" (username). Results are always the same. My password does have an @-sign in it. I'm not sure if I need to escape it, or how.

Logs show this:

Started POST "/users/auth/ldapmain/callback" for 127.0.0.1 at 2015-07-22 17:15:01 -0400
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"********", "password"=>"[FILTERED]"}
Redirected to http://192.168.56.102/users/sign_in
Completed 302 Found in 14ms (ActiveRecord: 3.6ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2015-07-22 17:15:01 -0400
Processing by SessionsController#new as HTML
Completed 200 OK in 20ms (Views: 8.3ms | ActiveRecord: 2.9ms)

And gitlab-rake gitlab:ldap:check shows this:

Checking LDAP ...

LDAP users with access to your GitLab server (only showing the first 100 results)
Server: ldapmain

Checking LDAP ... Finished

However, when I use ldapsearch from the Ubuntu VM (so same environment), I do get a bunch of results:

ldapsearch -x -h ******** -D "********@********.***" -W -b "OU=********,OU=********,DC=********,DC=***" -s sub "(cn=*)" cn mail sn dn

Curiously, the DN's in the results look like this:

dn: CN=John Smith,OU=********,OU=********,OU=********,DC=********,DC=***

That is, there is an extra OU in there. I also see that the ldapsearch command has -s sub, which I believe means to search subgroups. I'm not super-familiar with the ins and outs of LDAP or Active Directory.

So I believe I'm missing something in my base, but I'm not sure what. It may also be a problem with user filter. I've done the requisite Googling, which got me this far, but now I'm out of ideas and solutions.

siride
  • 529
  • 2
  • 7
  • 18
  • 1
    Your entry for `base` looks a bit short. What happens when you put the full path from your ldapsearch result there (including all OUs)? – etagenklo Aug 07 '15 at 12:51
  • @etagenklo: you are correct. I made some other changes and was able to get it to work. I will post as an answer for posterity. – siride Aug 07 '15 at 13:42
  • this answer might be helpful: https://stackoverflow.com/a/54462889/6290553 – Raktim Biswas Jan 31 '19 at 14:56

1 Answers1

11

I was able to solve this after many different tries. A few notes:

  • Make sure that all the lines except the first have a single space for indent. The first line is the one that says "main:" and that has no indent at all.
  • The bind_dn is not the full LDAP path for the bind user, but just the username. In my case it's "xxx@example.com".
  • The base needs to be the Active Directory group or DN or whatever it's called that contains all the users.

Here's the final YAML:

main: # 'main' is the GitLab 'provider ID' of this LDAP server
 label: 'Active Directory'
 host: 'ad-server.example.com'
 port: 389
 uid: 'sAMAccountName'
 method: 'plain' # "tls" or "ssl" or "plain"
 bind_dn: 'user@example.com'
 password: 'password'
 active_directory: true
 allow_username_or_email_login: false
 block_auto_created_users: false
 base: 'OU=ABC,OU=XYZ,DC=example,DC=com'
 user_filter: ''
siride
  • 529
  • 2
  • 7
  • 18
  • 1
    so much +1! This is the only solution on the whole stackexchange network which was working for me! – Noir Jul 28 '16 at 12:15