LDAP Simple Auth does not work against Active Directory #1307

New Issue

GiteaMirror · 2025-11-02T03:56:12-06:00

GiteaMirror commented

2025-11-02 03:56:12 -06:00

Originally created by @elvarb on GitHub (Dec 1, 2017).

Gitea version (or commit ref): 1.23
Git version:
Operating system: Ubuntu Server
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

Authenticating users with LDAP Simple Auth requires you to fill in the following fields

User DN
User Filter

The user DN example given is uid=%s,ou=Users,dc=mydomain,dc=com

This does not work because the full user location in Active Directory is cn=full name,,ou=Users,dc=mydomain,dc=com , when the user logs in he gives a username that can not be mapped to a full cn location.

To solve this you have to use for user DN mydomain%s

The issue you create then is that for the User Filter is that it is based on the User DN location. In the log this is written to demonstrate the issue.

2017/12/01 13:56:57 [T] Fetching attributes 'sAMAccountName', 'givenName', 'Surname', 'UserPrincipalName' with filter (&(objectCategory=Person)(sAMAccountName=elvar)(memberOf=cn=giteaUsers,ou=Groups,dc=mydomain,dc=com)) and base mydomain\elvar

This base results in an error of LDAP Result Code 34 "Invalid DN Syntax"

To solve this the UserDN could be changed to only point to the search location, in this case either ou=Users,dc=mydomain,dc=com or dc=mydomain,dc=com. I am not sure if this could break current uses of LDAP simple auth, but I think it would be cleanest to not require the full path to the user dn if possible.

The other option I could see would be to add a new field/setting for the base DN used in the user filter. That way against active directory mydomain%s could still be used and for current uses this field could be ignored if empty and the user dn used instead.

See also https://github.com/gogits/gogs/issues/2526

Originally created by @elvarb on GitHub (Dec 1, 2017). - Gitea version (or commit ref): 1.23 - Git version: - Operating system: Ubuntu Server - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: ## Description Authenticating users with LDAP Simple Auth requires you to fill in the following fields * User DN * User Filter The user DN example given is uid=%s,ou=Users,dc=mydomain,dc=com This does not work because the full user location in Active Directory is cn=full name,,ou=Users,dc=mydomain,dc=com , when the user logs in he gives a username that can not be mapped to a full cn location. To solve this you have to use for user DN mydomain\%s The issue you create then is that for the User Filter is that it is based on the User DN location. In the log this is written to demonstrate the issue. 2017/12/01 13:56:57 [T] Fetching attributes 'sAMAccountName', 'givenName', 'Surname', 'UserPrincipalName' with filter (&(objectCategory=Person)(sAMAccountName=elvar)(memberOf=cn=giteaUsers,ou=Groups,dc=mydomain,dc=com)) and base mydomain\elvar This base results in an error of LDAP Result Code 34 "Invalid DN Syntax" To solve this the UserDN could be changed to only point to the search location, in this case either ou=Users,dc=mydomain,dc=com or dc=mydomain,dc=com. I am not sure if this could break current uses of LDAP simple auth, but I think it would be cleanest to not require the full path to the user dn if possible. The other option I could see would be to add a new field/setting for the base DN used in the user filter. That way against active directory mydomain\%s could still be used and for current uses this field could be ignored if empty and the user dn used instead. See also https://github.com/gogits/gogs/issues/2526

GiteaMirror added the type/bug label 2025-11-02 03:56:12 -06:00

GiteaMirror closed this issue

2025-11-02 03:56:13 -06:00

GiteaMirror commented

2025-11-02 03:56:13 -06:00

@shollander commented on GitHub (May 16, 2018):

@malweka has submitted a pull request for this (#2969) a while ago. For some reason it has been stalled. Would someone please get the pull request merged?

@shollander commented on GitHub (May 16, 2018): @malweka has submitted a pull request for this (#2969) a while ago. For some reason it has been stalled. Would someone please get the pull request merged?

GiteaMirror referenced this issue

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

[PR #1307] [MERGED] Add captcha support to OpenID based signup #15855

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#1307