LDAP: 500 Internal Server Error (NoMethodError) with working gitlab-rake gitlab:ldap:check

[Bob Jones]

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!

[Aleksey Tsalolikhin]

On Tue, Mar 7, 2017 at 12:09 PM, Bob Jones <onetru...@gmail.com> wrote:

Is there a way I can turn up the gitlab logging verbosity to show me more details about why the ldap call is failing?  

Did you try How change gitlab log level? #9491 ?  It's a year and a half old so may be stale but give it a whirl?

Best,

Aleksey

ᐧ

[Bob Jones]

So, I tried that and it did produce more verbose logging, but nothing useful about what the LDAP problem is unfortunately.

Bob

[Aleksey Tsalolikhin]

Understood, thanks. 

Since this is EE, have you considered reaching out to support? 

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/eeeceafc-07f3-490c-adb4-1e7ca9a97c66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Drew Blessing]

Hi Bob,

I'm on the GitLab team. Aleksey has a great suggestion - please contact support at https://support.gitlab.com and we'll be happy to take a look. 

At a quick glance, I don't see anything obviously wrong with your configuration. My suggestion would be to completely remove or comment the `attributes` section, as it's generally not needed. Also, I'm not 100% sure, but `directory_ldap` as the provider 'ID' may have an issue with the underscore. If that's a problem we need to either fix it, or document it. I look forward to your support request. 

[Bob Jones]

So the _ in the provider 'ID' was the culprit.  Removing that fixed all the issues.

Thanks for your help,
Bob