Hello all. I’ve been beating my head around this for a few hours now and cannot crack this issue. So here’s the situation. I’m setting up an instance of GitLab EE Omnibus version 8.17.2-ee.0.el7. I have configured LDAP authentication against our AD server with the following config (and have tried various combinations and options, such as uid as cn which is the same value as sAMAccountName):
gitlab_rails[‘ldap_enabled’] = true
gitlab_rails[‘ldap_servers’] = YAML.load <<-EOS
directory_ldap:
user_filter: “”
allow_username_or_email_login: false
label: DIRECTORY
active_directory: true
block_auto_created_users: true
base: “DC=directory,DC=virginia,DC=edu”
attributes:
first_name: givenName
name: displayName
email: mail
last_name: sn
username: sAMAccountName
bind_dn: “CN=gitlab,OU=Accounts,DC=directory,DC=virginia,DC=edu”
password: “2jkakjrkiiuu@3445”
port: “389”
method: tls
host: directory.virginia.edu
uid: sAMAccountName
EOS
I can use those credentials and settings in ldapsearch successfully. Also gitlab-rake gitlab:ldap:check works just fine with the following results (condensed):
Checking LDAP …
Server: ldapdirectory_ldap
LDAP authentication… Success
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: CN=tas6n,CN=Users,DC=directory,DC=virginia,DC=edu sAMAccountName: tas6n
DN: CN=rck4p,CN=Users,DC=directory,DC=virginia,DC=edu sAMAccountName: rck4p
Checking LDAP … Finished
However, when I go to login to our GitLab site as tas6n I get a 500 error with the following from the gitlab-rails/production.log:
Started POST “/users/auth/ldapdirectory_ldap/callback” for 10.250.1.67 at 2017-03-07 14:40:01 -0500
Processing by OmniauthCallbacksController#ldapdirectory_ldap as HTML
Parameters: {“utf8”=>“✓”, “authenticity_token”=>“XQcVFiSTK1aNedtsWHlUl4jULSOkz5femKXqQtk5gXw+wno2r60wfh42W7iQ/WyYWvFfBU8ge3juA64PmU/hAA==”, “username”=>“tas6n”, “password”=>“[FILTERED]”}
Completed 500 Internal Server Error in 13ms (ActiveRecord: 1.2ms)
NoMethodError (undefined method provider' for nil:NilClass): lib/gitlab/o_auth/auth_hash.rb:29:in provider’
lib/gitlab/o_auth/auth_hash.rb:16:in normalized_uid' lib/gitlab/o_auth/auth_hash.rb:25:in uid’
lib/gitlab/ldap/user.rb:37:in find_by_uid_and_provider' lib/gitlab/ldap/user.rb:33:in gl_user’
lib/gitlab/o_auth/user.rb:18:in persisted?' lib/gitlab/ldap/user.rb:45:in update_user_attributes’
lib/gitlab/ldap/user.rb:24:in initialize' app/controllers/omniauth_callbacks_controller.rb:25:in new’
app/controllers/omniauth_callbacks_controller.rb:25:in ldap' lib/gitlab/middleware/multipart.rb:93:in call’
lib/gitlab/request_profiler/middleware.rb:14:in call' lib/gitlab/middleware/go.rb:16:in call’
lib/gitlab/middleware/readonly_geo.rb:30:in `call’
I can successfully bind via ldapsearch with the DN for tas6n that is returned via the ldap check rake command, so I know the server is responding to that. I’ve searched and haven’t come across anyone who gets the 500 error with a working gitlab-rake gitlab:ldap:check so I’m asking now.
Does anyone have a clue as to what is going on? Is there a way I can turn up the gitlab logging verbosity to show me more details about why the ldap call is failing? I really am stuck in the water here. Thanks!