GitLab LDAP认证故障排查（SSL连接、用户认证问题）

Hey, let's figure out why your GitLab LDAP authentication isn't working—there are a few clear mismatches in your config and some quick checks we can run to fix this.

First, let's tackle the most obvious conflict in your LDAP setup:

1. Encryption Type vs. Port Mismatch #

You've set encryption: 'simple_tls' but are using port 389—this is a critical mismatch:

• simple_tls (LDAPS) uses port 636 by default, as it encrypts the connection immediately on handshake
• Port 389 is for unencrypted connections or start_tls (which upgrades a plaintext connection to encrypted after initial setup)

Fix this by aligning the two settings:

Option A: Use simple_tls (LDAPS) #

Update your gitlab.rb config:

gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
main:
  label: 'LDAP'
  host: '<internal IP of domain controller>'
  port: 636  # Switch to 636 for simple_tls
  uid: 'uid'
  bind_dn: 'CN=admin,DC=<project_name>,DC=local'
  password: '<password>'
  encryption: 'simple_tls'
EOS

Option B: Use start_tls (Recommended) #

If your domain controller supports it, start_tls is a more secure choice (uses port 389):

gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
main:
  label: 'LDAP'
  host: '<internal IP of domain controller>'
  port: 389
  uid: 'uid'
  bind_dn: 'CN=admin,DC=<project_name>,DC=local'
  password: '<password>'
  encryption: 'start_tls'  # Swap to start_tls for port 389
EOS

2. Verify Network Connectivity #

First, make sure your GitLab server can reach the LDAP domain controller on the correct port. Run these commands on your GitLab server:

• For port 636: nc -zv <internal IP> 636 or telnet <internal IP> 636
• For port 389: nc -zv <internal IP> 389 or telnet <internal IP> 389

If these fail, check your Google Cloud firewall rules:

• Ensure the GitLab server's VPC allows outbound traffic to the LDAP server's port
• Ensure the LDAP server's firewall allows inbound traffic from the GitLab server's IP address

3. Validate Bind DN & Credentials #

Double-check that your bind DN and password are correct and have permissions to query LDAP users:

• Use the ldapsearch tool to test the bind directly:
  • For unencrypted/start_tls:

    ldapsearch -x -H ldap://<internal IP>:389 -D "CN=admin,DC=<project_name>,DC=local" -w "<password>" -b "DC=<project_name>,DC=local" "(objectClass=user)"
    

  • For simple_tls:

    ldapsearch -x -H ldaps://<internal IP>:636 -D "CN=admin,DC=<project_name>,DC=local" -w "<password>" -b "DC=<project_name>,DC=local" "(objectClass=user)"
    

If this command returns a list of LDAP users, your bind DN and password are valid.

4. Handle Certificate Issues (For Encrypted Connections) #

If you're using simple_tls or start_tls, GitLab needs to trust your LDAP server's certificate:

• If you're using a self-signed certificate, copy it to GitLab's trusted certs directory and reconfigure:

  cp /path/to/your-ldap-cert.pem /etc/gitlab/trusted-certs/
  gitlab-ctl reconfigure
  gitlab-ctl restart
  

Final Steps: Apply Config & Test #

After updating your gitlab.rb, apply the changes and restart GitLab:

gitlab-ctl reconfigure
gitlab-ctl restart

If authentication still fails, check GitLab's auth logs for detailed error messages:

gitlab-ctl tail gitlab-rails/auth.log

The logs will tell you exactly what's wrong (e.g., bind failure, user not found, certificate error).

内容的提问来源于stack exchange，提问作者ryan.kom