LDAP Auth in Docker Not functional #3988

New Issue

GiteaMirror · 2025-11-02T05:32:55-06:00

GiteaMirror commented

2025-11-02 05:32:55 -06:00

Originally created by @josh-hemphill on GitHub (Sep 19, 2019).

Gitea version: 1.9.3
Git version: 2.22.0
Operating system: Docker container on CentOS
Database:
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:
No lines in the log seemed relevant. Only the container initialization, services initialisation, and http requests show up in the docker-compose logs.

Description

There doesn't seem to be any way to test or see if the LDAP is working at all.
I'm trying to move my gitea instance to Docker, so I copied my LDAP settings from my working docker installation, but it doesn't seem to work.
I assume it also must be because of the LDAP not working that the 'Synchronize External Users' process doesn't run either.

My docker-compose.yml configuration

Originally created by @josh-hemphill on GitHub (Sep 19, 2019).   - Gitea version: 1.9.3 - Git version: 2.22.0 - Operating system: Docker container on CentOS - Database: - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: No lines in the log seemed relevant. Only the container initialization, services initialisation, and http requests show up in the docker-compose logs. ## Description There doesn't seem to be any way to test or see if the LDAP is working at all. I'm trying to move my gitea instance to Docker, so I copied my LDAP settings from my working docker installation, but it doesn't seem to work. I assume it also must be because of the LDAP not working that the 'Synchronize External Users' process doesn't run either. [My docker-compose.yml configuration](https://pastebin.com/CPsCAFbH)

GiteaMirror added the type/question label 2025-11-02 05:32:55 -06:00

GiteaMirror closed this issue

2025-11-02 05:32:56 -06:00

GiteaMirror commented

2025-11-02 05:32:57 -06:00

@davydov-vyacheslav commented on GitHub (Sep 19, 2019):

Hi,
I'm using 1.9.3 Gitea with LDAP (openLDAP) auth.

there is nothing todo in docker configuration towards the LDAP connection
have you read the auth article: https://docs.gitea.io/en-us/authentication/ (it helped me)
in order to help you the screenshot with your the LDAP configuration at https://gitea.your.domain/admin/auths would be helpful

@davydov-vyacheslav commented on GitHub (Sep 19, 2019): Hi, I'm using 1.9.3 Gitea with LDAP (openLDAP) auth. 1) there is nothing todo in docker configuration towards the LDAP connection 2) have you read the auth article: `https://docs.gitea.io/en-us/authentication/` (it helped me) 3) in order to help you the screenshot with your the LDAP configuration at https://gitea.your.domain/admin/auths would be helpful

GiteaMirror commented

2025-11-02 05:32:57 -06:00

@josh-hemphill commented on GitHub (Sep 20, 2019):

I have read the auth documentation many times when I got it working the first time.
I assume you mean the LDAP settings at https://gitea.your.domain/admin/auths/1?
It's listed as LDAP (via BindDN) and enabled.
Here's the configuration: https://pastebin.com/9GpN7iUF

@josh-hemphill commented on GitHub (Sep 20, 2019): I have read the auth documentation many times when I got it working the first time. I assume you mean the LDAP settings at https://gitea.your.domain/admin/auths/1? It's listed as LDAP (via BindDN) and enabled. Here's the configuration: https://pastebin.com/9GpN7iUF

GiteaMirror commented

2025-11-02 05:32:57 -06:00

@josh-hemphill commented on GitHub (Sep 26, 2019):

I've narrowed it down a bit. It will bind on Domain Admin accounts, but not read-only accounts. ldapsearch functions the same way within the docker container, so there must be something about having the LDAP auth behind docker's NAT that requires admin privileges.

@josh-hemphill commented on GitHub (Sep 26, 2019): I've narrowed it down a bit. It will bind on Domain Admin accounts, but not read-only accounts. ldapsearch functions the same way within the docker container, so there must be something about having the LDAP auth behind docker's NAT that requires admin privileges.

GiteaMirror commented

2025-11-02 05:32:58 -06:00

@josh-hemphill commented on GitHub (Oct 4, 2019):

I resolved some network issues and then found that in the newest version I had to qualify the Bind DN with DOMAIN\USERNAME instead of just the user's CN.

@josh-hemphill commented on GitHub (Oct 4, 2019): I resolved some network issues and then found that in the newest version I had to qualify the Bind DN with `DOMAIN\USERNAME` instead of just the user's CN.

GiteaMirror commented

2025-11-02 05:32:58 -06:00

@JessopDev commented on GitHub (Nov 26, 2019):

Hi Josh, would you be able to explain exactly what change you have made to the Bind DN? I have tried both username@domain.com and CN=username,OU=Users,OU=Managed,DC=domain,DC=com.

@JessopDev commented on GitHub (Nov 26, 2019): Hi Josh, would you be able to explain exactly what change you have made to the Bind DN? I have tried both username@domain.com and CN=username,OU=Users,OU=Managed,DC=domain,DC=com.

GiteaMirror commented

2025-11-02 05:32:58 -06:00

@josh-hemphill commented on GitHub (Dec 4, 2019):

@JessopDev It depends on the AD setup. For example, my company has a subdomain as the AD root, but all the emails are still the top-level domain. So your email might be username@domain.com but the bind DN will either be just username or whatever subdomain you have as the domain like domain\username.
If you AD path is CN=username,OU=Users,OU=Managed,DC=domain,DC=com then it will just be your username, but if it's CN=username,OU=Users,OU=Managed,DC=subdomain,DC=domain,DC=com then it'd be subdomain\username.

@josh-hemphill commented on GitHub (Dec 4, 2019): @JessopDev It depends on the AD setup. For example, my company has a subdomain as the AD root, but all the emails are still the top-level domain. So your email might be `username@domain.com` but the bind DN will either be just `username` or whatever subdomain you have as the domain like `domain\username`. If you AD path is `CN=username,OU=Users,OU=Managed,DC=domain,DC=com` then it will just be your username, but if it's `CN=username,OU=Users,OU=Managed,DC=subdomain,DC=domain,DC=com` then it'd be `subdomain\username`.

GiteaMirror referenced this issue

2025-11-02 12:28:41 -06:00

[PR #3988] [MERGED] Re-enable random avatar feature #17183

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3988