Authentication fails with correct password with Samba LDAP/AD

How to Use GitLab Self-managed
1

Hi.

I’m trying to connect my GitLab instance to my Samba LDAP/AD. GitLab seems to able to communicate with it just fine, but the authentification keeps failing, no matter what I try:

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

Server: ldapmain
LDAP authentication... Failed. Check `bind_dn` and `password` configuration values
LDAP users with access to your GitLab server (only showing the first 100 results)

Checking LDAP ... Finished

I have tried all different possible combinations of the user name:

  • CN=gitlab,CN=Users,DC=company,DC=local
  • cn=gitlab,cn=Users,dc=company,dc=local
  • gitlab
  • COMPANY\gitlab
  • company\gitlab

Additionally I tried it with active-directory disabled and my personal account where I’m 1000% certain I used the correct password.

(Of course I ran gitlab-ctl reconfigure after changing the config every time)

And the gitlab-rake gitlab:ldap:check test always outputs the same as above.

Weirdly enough I also can’t authenticate using ldapsearch!

Attempts 
  • ldapsearch -D "cn=myuser,cn=Users,dc=company,dc=local" -w "<password>" \
    -p 389 -h 10.128.1.254 \
    -b "cn=Users,dc=company,dc=local"
    Results in
    ldap_bind: Strong(er) authentication required (8)
        additional info: BindSimple: Transport encryption required.

  • ldapsearch -D "cn=myuser,cn=Users,dc=company,dc=local" -w "<password>" \
    -p 389 -h 10.128.1.254 \
    -b "cn=Users,dc=company,dc=local" \
    -Y NTLM
    Results in
    SASL/NTLM authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
        additional info: SASL:[NTLM]: NT_STATUS_OBJECT_NAME_NOT_FOUND

  • ldapsearch -D "cn=myuser,cn=Users,dc=company,dc=local" -w "<password>" \
    -p 389 -h 10.128.1.254 \
    -b "cn=Users,dc=company,dc=local" \
    -Y GSSAPI
    Results in the nothing saying error
    SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0))

More on that issue here: connection - ldapsearch - Strong(er) authentication required - Transport encryption required - Super User

They might be related…

Active Directory Explorer is having no issues whatsoever and other windows services work just fine with it too, so I don’t think it’s an issue on the AD side.
Which btw runs on a Synology, if that makes any difference.

Any idea on how to further investigate this issue are greatly appreachiated!

2

I haven’t found a solution and LDAP still isn’t working…

3

Bumping again.

4

Hi there,

you’re talking about AD -> do you mean Microsoft Active Directory? If yes it has nothing todo with Samba!

It would be helpful if you would post your entire LDAP config here.

Have a look here for a working MS AD LDAP configuration.

The bind_dn should be every time in the form of your 1st or 2nd example. MS AD is not case sensitive so both will work. For other directories this can be different and I guess that for this configuration active-directory should be false all the time.

Good luck!

5

Well, if the Active Directory server is running on a Linux server, the daemon behind the service is samba.

gitlab_rails['ldap_enabled'] = true

###! **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: 'Company AD'
    host: 'ad.company.local'
    port: 389 # we don't have LDAPS
    uid: 'sAMAccountName'
    bind_dn: 'CN=gitlab,CN=Users,DC=company,DC=local'
    password: 'correct password'
    encryption: 'plain' # I tried all 3 values
#     verify_certificates: false
    active_directory: true
#     allow_username_or_email_login: false
#     lowercase_usernames: false
#     block_auto_created_users: false
    base: 'CN=Users,DC=company,DC=local'
    user_filter: ''
#     ## EE only
#     group_base: ''
#     admin_group: ''
#     sync_ssh_keys: false
EOS

Can’t really see any significant differences, that would explain why it fails at the authentification step (aka the correct password getting rejected).

6

Sorry, I’m not familiar with such an AD deployment. I guess Samba is the problem - trace the logs of Samba and AD. In the MS event viewer you should see logs regarding auth…

1 Like
7

I have been unable to do that, as the Synology seems to be messing with it somehow. Increasing the log verbosity and restarting the service didn’t seem to work for some reason, so I’m out of ideas on what to do or try…

8

Hey ConnectingMedia, do you have fixed this problem? I’m currently working on the same problem. :confused:

9

edit your smb.conf and add


ldap server require strong auth = no

in global section