LDAP configuration: «Could not authenticate you from Ldapmain because “Invalid credentials for <username>”»

How to Use GitLab Self-managed
1

Hello,

I seem to have the same problem as in the previous chains

and

namely I can see the account in the output of “gitlab-rake gitlab:ldap:check”, also on the console of gitlab-rails the account with a given ‘uid’ is found, so I see no problem in the connection to the server, self-installed OpenLDAP server on Ubuntu 20.04 LTS. In the logs of the OpenLDAP server I see

SRCH base="ou=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx" scope=2 deref=0 filter="(&(memberUid=xxx)(objectClass=posixGroup)(cn=xxx))"
SEARCH RESULT tag=101 err=0 nentries=1 text=

Yet immediately after this there appears

BIND dn="cn=xxx,ou=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx" method=128
RESULT tag=97 err=49 text=

Why does the ‘BIND’ appear with these arguments and not for example with the ‘uid’?

In the configuration ‘gitlab.rb’ we have

    'uid' => 'memberUID',
    'encryption' => 'start_tls', # "start_tls" or "simple_tls" or "plain"
    'verify_certificates' => true,
    'active_directory' => false,
    'allow_username_or_email_login' => false,
    'lowercase_usernames' => false,
    'block_auto_created_users' => false,
    'base' => 'ou=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx',
    'user_filter' => '(&(objectClass=posixGroup)(cn=xxx))',
...

as our LDAP directory consists of groups and member in them with the ‘memberUID’.

Just to note that with the empty ‘user_filter’ the login succeeded (but we cannot let all the people login from our department, so this is not a valid solution). Could it also be that this former user account (that I deleted via the web interface of our GitLab server) is somehow disturbing as a ghost?

Could you at least suggest me how to debug further the error? Thank you for any hints!

Greetings,

   apsi
2

PS Now I understand that after the first query the “cn” of the result is used for the connection (“BIND”?), right? Is there any way to use the filter with the query based on members in a group? It seems I will have a long way ahead planning a LDAP database that serves all the different kind of ways of authorisations on different clients…