Could not authenticate you from Ldapmain because "Invalid credentials for user.name"
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: [email protected]
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 passwordtest
, 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.
Gilles Quenot
I am a freelancer, developer & Linux system administrator. I like to play around Linux and GNU tools, text processing, web scraping, javascript, xpath, bash, perl, python, awk, VmWare automation, devOps tools... Contact : first name DOT last name AT sputnick DOT fr
Updated on July 17, 2022Comments
-
Gilles Quenot almost 2 years
I use
- debian 9
- gitlab-ce 11.10.4-ce.0
- omnibus install via apt
- openldap 2.4.44
ldap
configurationConfigured
/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 viaphpladmin
thePassword
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: [email protected] 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 thisldiff
viaslapadd -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: [email protected] 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
-
Gilles Quenot almost 5 yearsDay saver, BIG UP, logged via LDAP <3
-
EricLavault almost 5 years#!/bin/:) .. and don't forget to uncomment the attributes in gitlab.rb for the synchronization to take effect !
-
Gilles Quenot almost 5 yearsSorry, don't know what you mean. Which synchronization do you mean ?
-
EricLavault almost 5 yearsThis is explained here docs.gitlab.com/ee/administration/auth/ldap.html, the config maps gitlab user settings like 'username' to the possible matching attribute in your directory that contains the corresponding user data that you need to sync (don't bother if you don't need it!), but still note that username and email are mandatory for the sync and the account auto creation to work in gitlab. It's safe to copy/paste values from the doc as it covers the usual mapping for AD and openldap.
-
Gilles Quenot almost 5 yearsYes, thanks, needed to match old user with LDAP ones