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:inprovider'
lib/gitlab/o_auth/auth_hash.rb:16:in normalized_uid'
lib/gitlab/o_auth/auth_hash.rb:25:inuid'
lib/gitlab/ldap/user.rb:37:in find_by_uid_and_provider'
lib/gitlab/ldap/user.rb:33:ingl_user'
lib/gitlab/o_auth/user.rb:18:in persisted?'
lib/gitlab/ldap/user.rb:45:inupdate_user_attributes'
lib/gitlab/ldap/user.rb:24:in initialize'
app/controllers/omniauth_callbacks_controller.rb:25:innew'
app/controllers/omniauth_callbacks_controller.rb:25:in ldap'
lib/gitlab/middleware/multipart.rb:93:incall'
lib/gitlab/request_profiler/middleware.rb:14:in call'
lib/gitlab/middleware/go.rb:16:incall'
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!
--
You received this message because you are subscribed to the Google Groups
"GitLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to gitlabhq+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/gitlabhq/840123c6-9866-4db3-98f2-f0e6875951b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
