LDAP Authentication using Active Directory failing despite login success

Updated Summary

Update LDAP documentation to note that with Active Directory, the bind_dn may need to be a value such as the admin user's email address or sAMAccountName when a DN doesn't work. I'm not exactly clear on why this is, but I've seen it many times with customers, and the user in this case confirms the same.

It will help users if we mention this in our docs so if they're stuck they can try one of these alternative values.

I've never seen this needed nor tried with OpenLDAP and other LDAP providers besides Active Directory.

Original summary and description below

LDAP Authentication with Active Directory failing after install.

Steps to reproduce

Running on RHEL 7.7 connecting to Active Directory on Windows Server 2016.

running gitlab-rake gitlab:ldap:check gives back error

Failed. Check 'bind_dn' and 'password' configuration values

However when looking at logs on the domain controller it shows that the user gitlab uses was successfully authenticated.

Logging in on the webpage gives back "Could not authenticate you from Ldapmain because "Invalid Credentials for ", but logs on the domain controller show a successful login.

My Config File:

gitlab_rails['ldap_enabled'] = true
gitlab_rails['prevent_ldap_sign_in'] = false
  gitlab_rails['ldap_servers']=YAML.load <<-'EOS'
   main:
   label: 'domain login'
   host: '<hostname>'
   port: 389
   uid: 'samAccountName'
   bind_dn: 'CN=gitlab,OU=<ou1>,OU=<ou2>,OU=<ou3>,OU=<ou4>,DC=<dc1>,DC=<dc2>,DC=com'
   password: '<password>'
   encryption: 'plain'
   verify_certificates: false
   active_directory: true
   smartcard_auth: false
   allow_username_or_email_login: false
   lowercase_usernames: false
   block_auto_created_users: false
   base: 'OU=<ou1>,OU=<ou2>,OU=<ou3>,DC=<dc1>,DC=<dc2>,DC=com'
   user_filter: ''
 EOS

What is the current bug behavior?

LDAP test (and any attempted login) fails while domain controller says that the user was authenticated successfully

What is the expected correct behavior?

LDAP user is able to log in

Possible fixes

I've looked at the solutions in the following related issues to no solution

Edited by Drew Blessing