3
votes

The following ldapsearch command works, flawlessly.

ldapsearch -LLL -s sub -P 3 -D "CN=,OU=IT,OU=Non-Users,OU=Users,OU=UserAccount,DC=,DC=com" -H ldaps://.com: -w '' -v -b 'OU=Users,OU=UserAccount,DC=,DC=com' '(&(objectClass=person)(sAMAccountName=))'

But, regardless, of how much I double-check the values are typed correctly, this, configured in gitlab.yml, does not.

ldap:
enabled: true
host: '.com'
port:
uid: 'sAMAccountName'
method: 'ssl'
bind_dn: 'CN=,OU=IT,OU=Non-Users,OU=Users,OU=UserAccount,DC=,DC=com'
password: ''
allow_username_or_email_login: true
base: 'OU=Users,OU=UserAccount,DC=,DC=com'
user_filter: ''
group_base: ''

Yes, the BindDN is at a different location than the other users, but it is south of it, so the query base is valid.

All attempts throw this error on the screen:

Could not authorize you from LDAP because "Invalid credentials"

production.log indicates the following:

Started GET "/users/sign_in" for 127.0.0.1 at 2014-07-18 08:13:17 -0400
Processing by Devise::SessionsController#new as HTML
Completed 200 OK in 21ms (Views: 12.8ms | ActiveRecord: 0.0ms)
Started POST "/users/auth/ldap/callback" for 127.0.0.1 at 2014-07-18 08:13:25 -0400
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"", "username"=>"", "password"=>"[FILTERED]"}
Redirected to http:///users/sign_in
Completed 302 Found in 3ms (ActiveRecord: 0.0ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2014-07-18 08:13:56 -0400
Processing by Devise::SessionsController#new as HTML
Completed 200 OK in 10ms (Views: 5.9ms | ActiveRecord: 0.0ms)
Started POST "/users/auth/ldap/callback" for 127.0.0.1 at 2014-07-18 08:20:03 -0400

The LDAP in question is Active Directory, and while I don't have access to the server natively in order to query the logs, the "badPwdCount" is incremented for each attempt at a web login, and I don't understand how, or why.

I know the perils of end users and their insistence that they're typing their usernames and passwords in correctly, but I've checked, triple-checked, octuple-checked that there aren't any typos in my declarations, and I can't find any other incident with this same error combination. I know that the syntax here is correct.

What could possibly be the problem?

3
does a login from another system authenticating against this AD work? Possibly the user typed their password n times wrongly and now the account is locked. And is this a problem of EVERY user or just a certain one?heiglandreas
So, the service account that is binding is the one showing an invalid password attempt, not the user that is trying to authenticate. If any user attempts to authenticate, the service account fails its password check.bmelton
Sorry for the late reply. So does a login with the service account work otherwise?heiglandreas
Oh. Sorry for the misunderstanding. I actually meant a regular account that is only used for this service. Hence "serviceaccount". I didn't know that Microsoft actually uses this term for a special account type. Sorry!heiglandreas
Service accounts work fine. I was able to resolve my problem, which was simply that I was following the configuration settings for a manual installation, but I'd installed the Omnibus .deb.bmelton

3 Answers

3
votes

Here is my working AD settings for LDAP.

#########################################
ldap:  
    enabled: true  
    host: '16.184.18.88'  
    port: 636  
    uid: 'sAMAccountName'   #userPrincipalName  
    method: 'ssl' # "tls" or "ssl" or "plain"  
    bind_dn: 'CN=Gitlab Git,CN=Users,DC=mydomain,DC=net'  
    password: 'My_Password'  
    allow_username_or_email_login: false  
    base: 'CN=Users,DC=mydomain,DC=net'  
    user_filter: '(memberOf=CN=Developers,OU=GitLabHQ,DC=mydomain,DC=net)'  
    group_base: 'OU=GitLabHQ,DC=mydomain,DC=net'  
    admin_group: GitLabAdmins
########################################
1
votes

We had the similar issue, though our settings were all correct as we were getting the user search results by setting up the similar LDAP configuration on different tools like Jenkins, SonarQube; etc.

We resolved the issue by setting the value of DefaultForceNoPage to true in the ldap.rb file located at (the path may vary for different versions of gitlab):

/opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/net-ldap-0.16.0/lib/net/ldap.rb
                                                                      ^^^^^^^

defaultForceNoPage

which is false by default. So, once you have set the value to true, restart the GitLab server using:

gitlab-ctl reconfigure

You can also check if you are getting the results of the users of your organization by:

gitlab-rake gitlab:ldap:check

LDAP rake

Note: Most common issues users face while logging into the application using their mail id's, you should put:

uid: 'mail'
-1
votes

I too have got "invalid credentials" error while trying to configure LDAP in gitlab. The error is absolutely due to the format of ldap query. And gitlab appln looks for a specific format to bind the user to AD.

Here is my working configuration

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: '<LDAP hostname>'
  port: 389
  uid: 'sAMAccountName'
  method: 'plain' # "tls" or "ssl" or "plain"

  bind_dn: 'CN=<user name>,OU=<ou1>,OU=<ou2>,...,DC=example,DC=com'
  password: 'My_Password'
  active_directory: true
  allow_username_or_email_login: true
  block_auto_created_users: false
  base: 'DC=example,DC=com'

If you are not sure of bind_dn. Use a AD query tool that provides you the complete bind dn of the user.