Could not authenticate you from Ldapmain because "Invalid credentials for user.name"

Question

I use

• debian 9
• gitlab-ce 11.10.4-ce.0
• omnibus install via apt
• openldap 2.4.44

ldap configuration

Configured /etc/ldap/ldap.conf :

BASE    dc=serverX,dc=lan
URI     ldap://serverX.lan
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt

Configured /etc/gitlab/gitlab.rb :

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS
  label: 'Gitlab LDAP'
  host: '10.0.0.1'
  port: 389
  uid: 'sAMAccountName'
  method: 'plain' # "tls" or "ssl" or "plain"
  bind_dn: 'cn=admin,ou=users,dc=serverX,dc=lan'
  password: 'xxxx'
  encryption: 'plain'
  active_directory: false
  allow_username_or_email_login: true
  block_auto_created_users: false
  base: 'ou=users,dc=serverX,dc=lan'
EOS

Output of gitlab-rake gitlab:ldap:check is OK :

# gitlab-rake gitlab:ldap:check
Checking LDAP ...

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

Checking LDAP ... Finished

Users created from phpldapadmin :

Searched tons of web ressources, but I can't figure out the way to create LDAP users or use existing ones.

I don't know what is the issue and why I get Invalid credentials for user.name : I edited via phpladmin the Password attribute (md5) and I type the same one in the LDAP Gitlab login page :

Gitlab logs :

==> /var/log/gitlab/gitlab-rails/production.log <==
Started POST "/users/auth/ldapmain/callback" for 10.0.0.1 at 2019-05-16 07:56:16 +0200
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"user.name", "password"=>"[FILTERED]"}
Redirected to http://domainX.lan/users/sign_in
Completed 302 Found in 411ms (ActiveRecord: 23.1ms)
Started GET "/users/sign_in" for 10.0.0.1 at 2019-05-16 07:56:17 +0200
Processing by SessionsController#new as HTML
Completed 200 OK in 119ms (Views: 104.6ms | ActiveRecord: 7.5ms)

==> /var/log/gitlab/unicorn/unicorn_stdout.log <==
I, [2019-05-16T07:56:16.907169 #3996]  INFO -- omniauth: (ldapmain) Callback phase initiated.
E, [2019-05-16T07:56:16.917884 #3996] ERROR -- omniauth: (ldapmain) Authentication failure! invalid_credentials: OmniAuth::Strategies::LDAP::InvalidCredentialsError, Invalid credentials for user.name

The slapcat output with targeted user to login :

dn: uuid=gquenot,ou=users,dc=serverX,dc=lan
cn:: abcdef123456789==
sn: Foo Bar
objectClass: inetOrgPerson
objectClass: top
structuralObjectClass: inetOrgPerson
entryUUID: 5133fc-0be-2039-9825-cd7
creatorsName: cn=admin,dc=serverX,dc=lan
createTimestamp: 20190516045340Z
userPassword:: xxxxxxxx
mail: me@example.com
entryCSN: 20190516101837.136599Z#000000#000#000000
modifiersName: cn=admin,dc=serverX,dc=lan
modifyTimestamp: 20190516101837Z

Anyone knows what's wrong ?

Maybe someone can give me a sample ldiff and a working configuration ?

Edit:

slapadd try with this ldiff via slapadd -f file.ldiff :

dn: cn=admin,dc=serverX,dc=lan
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Firstname Lastname
givenName: Gilles
sn: Quenot
uid: gquenot
mail: me@example.com
userPassword: {MD5}xxxxxxxxxxxxxx

Error :

5cdd8fe4 slapcat_so.txt: line 1: unknown directive <dn:> outside backend info and database definitions.
slapadd: bad configuration file!

 Edit2

Fixed with :

ldapadd -x -H ldap://serverX:389 -D 'cn=admin,dc=serverX,dc=lan' -W -f stuff.ldiff

And updated password in phpldapadmin

Answer 1

Your Gitlab configuration targets Active Directory while you are using OpenLDAP to authenticate users, so the first thing to do is fixing the following parameters in /etc/gitlab/gitlab.rb:

uid: 'uid'
active_directory: false

I don't know what is the purpose of attributes in the context of an authentication (edit: attributes are used to synchronize user data from ldap to its Gitlab account, it shouldn't matter for the authentication itself).

Maybe there are other issues like the user's uid not being 'user.name', or the base being too narrow for example (user.name entry may not be under ou=people), if you don't know use the base dn as base search, or check by running a search with/without the 'ou' part :

ldapsearch -H ldap://10.0.0.1:389 -D cn=admin,dc=serverX,dc=lan -W -b ou=people,dc=serverX,dc=lan uid=user.name \*

I'd also check the credentials themselves directly against ldap , ie. not through Gitlab, by performing roughly the same query but using user.name bindings, here we actually tests that he can bind and read its own entry :

ldapsearch -H ldap://10.0.0.1:389 -D <user.name dn> -W -b <user.name dn> -s base \*

Also GitLab documentation insists on the fact that LDAP users must have an email address set, regardless of whether it is used to log in.

A typical ldif file containing user.name entry to be created using ldapadd -f (provided that the ou and dc's mentioned in its distinguished name exists) would look like this :

# user.name entry 
dn: uid=user.name,ou=users,dc=serverX,dc=lan
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Firstname Lastname
givenName: Firstname
sn: Lastname
uid: user.name
mail: user.name@domain.com
userPassword: {MD5}<base64EncodedHash>

I don't know though if/how GitLab is aware of the password encryption scheme (seems there is no config for this or I missed it).

---

You can create a test case entry :

• replace the <base64EncodedHash> with {MD5}CY9rzUYh03PK3k6DJie09g== (it represents the password test, if you need I have a script to generate them).
• don't forget also to replace the dc's with the real ones in the dn
• beware of empty lines and \t in the ldif file as it can break your ldap add/modify operations.
• run ldapadd -x -H ldap://10.0.0.1:389 -D cn=admin,dc=serverX,dc=lan -W -f ldifFilename to create the user entry.
• running the 1st ldapsearch cmd above, you should see a result for that new entry.
• running the second one, binding with the user credentials 'test' and searching for its own entry (hence the -b base parameter pointing to himself to avoid permission issues during search), you should again see the same result.

In gitlab.rb :

gitlab_rails['ldap_servers'] = YAML.load <<-EOS
  label: 'Gitlab LDAP'
  host: '10.0.0.1'
  port: 389
  uid: 'uid'
  bind_dn: 'cn=admin,ou=users,dc=serverX,dc=lan'
  password: 'xxxx'
  encryption: 'plain'
  active_directory: false
  allow_username_or_email_login: false
  block_auto_created_users: false
  base: 'ou=users,dc=serverX,dc=lan'

If you can bind with this user but not through gitlab ui, that could mean it does not handle the {MD5} authentication scheme.

Answer 2

I was facing the same problem - Invalid credentials even though I was keying in the correct credentials. This solution worked for me - My gitlab.rb had to be changed in this manner below. Previously I had not changed the value of 'uid' which was set to 'sAMAccountName', as you can see I commented it and changed the value to 'uid' itself. So 'uid' => 'uid' is the setting. Prior to doing this setting even when I was running the command - gitlab-rake gitlab:ldap:check , The output used to show - LDAP authentication... Success but no list of ldap users were shown. As soon as I changed the uid value as above, the rake command worked smoothly and showed me the list of all ldap users in the dc. Post this I was able to login also into the application through the UI

Note - Replace all the XXX with your own values.

gitlab_rails['ldap_enabled'] = true
gitlab_rails['prevent_ldap_sign_in'] = false
gitlab_rails['ldap_servers'] = {
'main' => {
  'label' => 'LDAP',
  'host' =>  '10.XXX.XX.XX',
  'port' => 389,
#  'uid' => 'sAMAccountName',
  'uid' => 'uid',#mandatory need to keep the value as 'uid' only
  'encryption' => 'plain',
  'verify_certificates' => false,
  'bind_dn' => 'cn=XXX,dc=XXXX,dc=XXX',
  'password' => 'XXX',
  'verify_certificates' => false,
#  'tls_options' => {
#    'ca_file' => '',
#    'ssl_version' => '',
#    'ciphers' => '',
#    'cert' => '',
#    'key' => ''
#  },
  'timeout' => 10,
  'active_directory' => false,
  'allow_username_or_email_login' => false,
  'block_auto_created_users' => false,
  'base' => 'dc=XXX,dc=XX',
#  'user_filter' => '',
#  'attributes' => {
#    'username' => ['uid', 'userid', 'sAMAccountName'],
#    'email' => ['mail', 'email', 'userPrincipalName'],
#    'name' => 'cn',
#    'first_name' => 'givenName',
#    'last_name' => 'sn'
#  },
  'lowercase_usernames' => true,

  # EE Only
#  'group_base' => '',
#  'admin_group' => '',
#  'external_groups' => [],
#  'sync_ssh_keys' => false
  }
}

Answer 3

I install GitLab using Docker Engine https://docs.gitlab.com/ee/install/docker.html

LDAP Configuration https://docs.gitlab.com/ee/administration/auth/ldap/#integrate-ldap-with-gitlab

sudo docker exec -it gitlab nano /etc/gitlab/gitlab.rb

## LDAP Settings
##! Docs: https://docs.gitlab.com/omnibus/settings/ldap.html
##! **Be careful not to break the indentation in the ldap_servers block. It is
##!   in yaml format and the spaces must be retained. Using tabs will not work.**

 gitlab_rails['ldap_enabled'] = true
 gitlab_rails['prevent_ldap_sign_in'] = false

##! **remember to close this block with 'EOS' below**
 gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
   main: # 'main' is the GitLab 'provider ID' of this LDAP server
     label: 'LDAP'
     host: 'ipa.example.com'
     port: 636
     uid: 'uid'
     bind_dn: 'uid=gitlab,cn=users,cn=accounts,dc=example,dc=com'
     password: 'gitlabpassword'
     encryption: 'simple_tls' # "start_tls" or "simple_tls" or "plain"
     verify_certificates: false
     smartcard_auth: false
     active_directory: false
     allow_username_or_email_login: false
     lowercase_usernames: false
     block_auto_created_users: false
     base: 'cn=users,cn=accounts,dc=example,dc=com'
     user_filter: ''
EOS

Save configuration, and than reconfigure GitLab:

 sudo docker exec -it gitlab /bin/bash
    
 root@gitlab:/# gitlab-ctl reconfigure
 root@gitlab:/# gitlab-ctl restart

Check if LDAP integration works:

root@gitlab:/# gitlab-rake gitlab:ldap:check
Checking LDAP ...

LDAP: ... Server: ldapmain
not verifying SSL hostname of LDAPS server 'ipa.example.com:636'
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
        DN: uid=admin,cn=users,cn=accounts,dc=example,dc=com       uid: admin
        DN: uid=gitlab,cn=users,cn=accounts,dc=example,dc=com      uid: gitlab

Checking LDAP ... Finished