I seem to have the same problem as in the previous chains
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!