github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 10:39:38 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

User accounts not automatically created via LDAP login #1097

New Issue
Closed
opened 2025-11-02 03:48:25 -06:00 by GiteaMirror · 25 comments
GiteaMirror commented 2025-11-02 03:48:25 -06:00
Owner
Copy Link

Originally created by @tobias-- on GitHub (Sep 26, 2017).

  • Gitea version (or commit ref): 1.2.0+rc2
  • Git version:
  • Operating system: Windows 2008 Server R2
  • 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:
2017/09/26 10:22:12 [W] Failed to login 'XXXX' via 'AD': user does not exist [uid: 0, name: XXXX, keyid: 0]

Description

User accounts are not created automatically when a not yet registered, but valid ActiveDirectory user tries to log in for the first time (see log message above). When the user is created manually for the authentication source, he/she can log in with his/her ActiveDirectory password as expected. The log also confirms that binding the user works.

DISABLE_REGISTRATION is set to true (and I am pretty sure it worked with this setting prior to 1.2). LDAP via BindDN is used as authentication type. Users already registered via LDAP (prior to 1.2) can log in as expected.

User filter: (&(objectCategory=person)(objectClass=user)(|(sAMAccountName=%[1]s)(mail=%[1]s))(!userAccountControl:1.2.840.113556.1.4.803:=2))

Originally created by @tobias-- on GitHub (Sep 26, 2017). - Gitea version (or commit ref): 1.2.0+rc2 - Git version: - Operating system: Windows 2008 Server R2 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ``` 2017/09/26 10:22:12 [W] Failed to login 'XXXX' via 'AD': user does not exist [uid: 0, name: XXXX, keyid: 0] ``` ## Description User accounts are not created automatically when a not yet registered, but valid ActiveDirectory user tries to log in for the first time (see log message above). When the user is created manually for the authentication source, he/she can log in with his/her ActiveDirectory password as expected. The log also confirms that binding the user works. `DISABLE_REGISTRATION` is set to true (and I am pretty sure it worked with this setting prior to 1.2). LDAP via BindDN is used as authentication type. Users already registered via LDAP (prior to 1.2) can log in as expected. User filter: `(&(objectCategory=person)(objectClass=user)(|(sAMAccountName=%[1]s)(mail=%[1]s))(!userAccountControl:1.2.840.113556.1.4.803:=2))`
GiteaMirror added the issue/stale label 2025-11-02 03:48:25 -06:00
GiteaMirror commented 2025-11-02 03:48:26 -06:00
Author
Owner
Copy Link

@strk commented on GitHub (Sep 26, 2017):

Could this be related to the new "LDAP Sync" feature ?
Take a look at docs, if there's a way to enable/disable them,
and look at the database to see if there's a difference between
the old and new accounts on the gitea db.

@strk commented on GitHub (Sep 26, 2017): Could this be related to the new "LDAP Sync" feature ? Take a look at docs, if there's a way to enable/disable them, and look at the database to see if there's a difference between the old and new accounts on the gitea db.
GiteaMirror commented 2025-11-02 03:48:26 -06:00
Author
Owner
Copy Link

@tobias-- commented on GitHub (Sep 26, 2017):

@strk could be related. I did not enable the option "Enable user synchronization" in the LDAP authentication settings. But my understanding is, that this option updates existing users and adds all users matching the base dn on a regular schedule, which I think is not directly related to this issue.

What documentation are you referring to? https://docs.gitea.io/en-us/authentication is empty.

@tobias-- commented on GitHub (Sep 26, 2017): @strk could be related. I did not enable the option "Enable user synchronization" in the LDAP authentication settings. But my understanding is, that this option updates existing users and adds all users matching the base dn on a regular schedule, which I think is not directly related to this issue. What documentation are you referring to? https://docs.gitea.io/en-us/authentication is empty.
GiteaMirror commented 2025-11-02 03:48:26 -06:00
Author
Owner
Copy Link

@MCF commented on GitHub (Oct 19, 2017):

If anyone else is looking, the current version of the Authentication/LDAP docs can be viewed here:

https://github.com/go-gitea/docs/blob/master/content/doc/features/authentication.en-us.md

Unfortunately the LDAP sync feature is currently not described on that page.

@MCF commented on GitHub (Oct 19, 2017): If anyone else is looking, the current version of the Authentication/LDAP docs can be viewed here: https://github.com/go-gitea/docs/blob/master/content/doc/features/authentication.en-us.md Unfortunately the LDAP sync feature is currently not described on that page.
GiteaMirror commented 2025-11-02 03:48:27 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Oct 19, 2017):

@MCF sync is just single checkbox when adding auth source

@lafriks commented on GitHub (Oct 19, 2017): @MCF sync is just single checkbox when adding auth source
GiteaMirror commented 2025-11-02 03:48:28 -06:00
Author
Owner
Copy Link

@strk commented on GitHub (Oct 19, 2017):

Would still be good to have documentation about it (how it works,
what it syncs, when...)

@MCF the source of that document is under go-gitea/docs if
you want to contibute an improvement

@strk commented on GitHub (Oct 19, 2017): Would still be good to have documentation about it (how it works, what it syncs, when...) @MCF the source of that document is under go-gitea/docs if you want to contibute an improvement
GiteaMirror commented 2025-11-02 03:48:29 -06:00
Author
Owner
Copy Link

@MCF commented on GitHub (Oct 19, 2017):

Thanks for the response @lafriks, I was looking for what the option (checked) actually does. My use case is a large enterprise LDAP server with thousands of users, and a gitea server for a smaller dev team (30-40). I don't want all the people in the LDAP server as users on the gitea server, just those that have logged in. I've seen the discussion on the original pull request and it seems that this option creates users on the gitea server for everyone in the LDAP server. I'm just interested in creating users when someone logs in, and keeping things like the first name/last name up to date for those same users.

@strk I'd be happy to add to the docs, but I don't know what the option does (yet).

@tobias-- sorry for hijacking your issue, that was not my intent ;-) FWIW, I am also using an Active Directory server and my 1.1 configuration still works fine with 1.2.1. I also have registration disabled, and am using LDAP BindDN. If you are still having troubles I can provide more specifics about my config settings if that is any help.

@MCF commented on GitHub (Oct 19, 2017): Thanks for the response @lafriks, I was looking for what the option (checked) actually does. My use case is a large enterprise LDAP server with thousands of users, and a gitea server for a smaller dev team (30-40). I don't want all the people in the LDAP server as users on the gitea server, just those that have logged in. I've seen the discussion on the original pull request and it seems that this option creates users on the gitea server for everyone in the LDAP server. I'm just interested in creating users when someone logs in, and keeping things like the first name/last name up to date for those same users. @strk I'd be happy to add to the docs, but I don't know what the option does (yet). @tobias-- sorry for hijacking your issue, that was not my intent ;-) FWIW, I am also using an Active Directory server and my 1.1 configuration still works fine with 1.2.1. I also have registration disabled, and am using LDAP BindDN. If you are still having troubles I can provide more specifics about my config settings if that is any help.
GiteaMirror commented 2025-11-02 03:48:29 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Oct 19, 2017):

@MCF that's why there is user filter where you can limit users that are in some group etc. But that of course will limit them not only for sync but also only these users will be able to login. But in enterprise world that is normal practice to add users to group and only than they are able to access some resource.

@lafriks commented on GitHub (Oct 19, 2017): @MCF that's why there is user filter where you can limit users that are in some group etc. But that of course will limit them not only for sync but also only these users will be able to login. But in enterprise world that is normal practice to add users to group and only than they are able to access some resource.
GiteaMirror commented 2025-11-02 03:48:29 -06:00
Author
Owner
Copy Link

@MCF commented on GitHub (Oct 20, 2017):

@lafriks I see. Does it happen immediately or when the first "sync" background operation is run?

Sorry, last question, if you do not check the sync box does Gitea do any synching on a per user basis each time you log in? For example if a last name is changed on the LDAP server for an existing Gitea user will that be updated the next time they login to Gitea?

Thx for the details BTW.

@MCF commented on GitHub (Oct 20, 2017): @lafriks I see. Does it happen immediately or when the first "sync" background operation is run? Sorry, last question, if you do not check the sync box does Gitea do any synching on a per user basis each time you log in? For example if a last name is changed on the LDAP server for an existing Gitea user will that be updated the next time they login to Gitea? Thx for the details BTW.
GiteaMirror commented 2025-11-02 03:48:30 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Oct 20, 2017):

@MCF it syncs by default once in 24h but that can be changed in app.ini. there is also an option to initiate sync manually in admin panel. I'm not sure if it updates user info on login

@lafriks commented on GitHub (Oct 20, 2017): @MCF it syncs by default once in 24h but that can be changed in app.ini. there is also an option to initiate sync manually in admin panel. I'm not sure if it updates user info on login
GiteaMirror commented 2025-11-02 03:48:30 -06:00
Author
Owner
Copy Link

@robe2 commented on GitHub (Nov 29, 2017):

FWIW, my LDAP accounts did automatically create on first login and pulled in LDAP info as expected.

This was using the following:

gita 1.3.0rc2
With a debian remote open LDAP (not MS Active Directory so might behave differently)

My Authentication settings in LDAP were

using ldaps

and filter

(&(objectClass=inetOrgPerson)(uid=%s))

Though I do have allow user registration on, not sure that makes a difference.
I have Enable User Synchronisation

currently unchecked though going to experiment with that in a bit.

@robe2 commented on GitHub (Nov 29, 2017): FWIW, my LDAP accounts did automatically create on first login and pulled in LDAP info as expected. This was using the following: gita 1.3.0rc2 With a debian remote open LDAP (not MS Active Directory so might behave differently) My Authentication settings in LDAP were using ldaps and filter (&(objectClass=inetOrgPerson)(uid=%s)) Though I do have allow user registration on, not sure that makes a difference. I have **Enable User Synchronisation** currently unchecked though going to experiment with that in a bit.
GiteaMirror commented 2025-11-02 03:48:31 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Nov 29, 2017):

I also can not seem to be able to reproduce that

@lafriks commented on GitHub (Nov 29, 2017): I also can not seem to be able to reproduce that
GiteaMirror commented 2025-11-02 03:48:31 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Feb 10, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 10, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
GiteaMirror commented 2025-11-02 03:48:31 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Feb 24, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Feb 24, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.
GiteaMirror commented 2025-11-02 03:48:32 -06:00
Author
Owner
Copy Link

@webmutation commented on GitHub (May 6, 2020):

Hi, sorry for restarting this issue, but there is a similar use case in my organisation, users are on LDAP but cannot connect they need to be added manually. Is there a better way to handle this?

Use Case
User logs into gitea with LDAP credential -> Gitea account is automatically created.

@webmutation commented on GitHub (May 6, 2020): Hi, sorry for restarting this issue, but there is a similar use case in my organisation, users are on LDAP but cannot connect they need to be added manually. Is there a better way to handle this? Use Case User logs into gitea with LDAP credential -> Gitea account is automatically created.
GiteaMirror commented 2025-11-02 03:48:32 -06:00
Author
Owner
Copy Link

@kidac commented on GitHub (May 7, 2020):

I have the same issue. After digging into OpenLDAP and the class inetOrgPerson maybe the missing value for the sn attribute is the problem:

ldif file:

dn: cn=langsam3,ou=accounts,dc=kdac,dc=de
objectClass: inetOrgPerson
cn: langsam3
mail: langsam3@kdac.de

Message if I add the entry manual:

/usr/sbin/slapadd -l test.ldif
5eb3bc7e Entry (cn=langsam3,ou=accounts,dc=kdac,dc=de): object class 'inetOrgPerson' requires attribute 'sn'
slapadd: dn="cn=langsam3,ou=accounts,dc=kdac,dc=de" (line=1): (65) object class 'inetOrgPerson' requires attribute 'sn'

In gitea I am unable to find a way to set a value for the sn attribute while I am adding a new account.

@kidac commented on GitHub (May 7, 2020): I have the same issue. After digging into OpenLDAP and the class inetOrgPerson maybe the missing value for the sn attribute is the problem: ldif file: dn: cn=langsam3,ou=accounts,dc=kdac,dc=de objectClass: inetOrgPerson cn: langsam3 mail: langsam3@kdac.de Message if I add the entry manual: /usr/sbin/slapadd -l test.ldif 5eb3bc7e Entry (cn=langsam3,ou=accounts,dc=kdac,dc=de): object class 'inetOrgPerson' requires attribute 'sn' slapadd: dn="cn=langsam3,ou=accounts,dc=kdac,dc=de" (line=1): (65) object class 'inetOrgPerson' requires attribute 'sn' In gitea I am unable to find a way to set a value for the sn attribute while I am adding a new account.
GiteaMirror commented 2025-11-02 03:48:33 -06:00
Author
Owner
Copy Link

@strk commented on GitHub (May 8, 2020):

NOTE: I would NOT want users to be automatically created, so please if
it ever gets implemented make it optional and default to OFF.

@strk commented on GitHub (May 8, 2020): NOTE: I would NOT want users to be automatically created, so please if it ever gets implemented make it optional and default to OFF.
GiteaMirror commented 2025-11-02 03:48:33 -06:00
Author
Owner
Copy Link

@webmutation commented on GitHub (May 8, 2020):

@strk Is there a simpler way to do this? Like for example a bulk import of accounts we want active? We have around 300 developers and having to add them one by one... is lets say not a fun way to spend time 😄

@webmutation commented on GitHub (May 8, 2020): @strk Is there a simpler way to do this? Like for example a bulk import of accounts we want active? We have around 300 developers and having to add them one by one... is lets say not a fun way to spend time 😄
GiteaMirror commented 2025-11-02 03:48:33 -06:00
Author
Owner
Copy Link

@strk commented on GitHub (May 8, 2020):

On Fri, May 08, 2020 at 07:50:49AM -0700, DDd wrote:

@strk Is there a simpler way to do this? Like for example a bulk import of accounts we want active? We have around 300 developers and having to add them one by one... is lets say not a fun way to spend time 😄

"active" != "created".
The accounts do exist, all your 300 developers already have an account
created (on the LDAP side), just need to login at least once in Gitea
in order to be notified, if that's what you're after.

I now see this ticket was closed because nobody could reproduce,
and was reopened in
https://github.com/go-gitea/gitea/issues/2610#issuecomment-624646684

Gitea 1.9.5 still works for us with LDAP accounts.

@strk commented on GitHub (May 8, 2020): On Fri, May 08, 2020 at 07:50:49AM -0700, DDd wrote: > @strk Is there a simpler way to do this? Like for example a bulk import of accounts we want active? We have around 300 developers and having to add them one by one... is lets say not a fun way to spend time 😄 "active" != "created". The accounts do exist, all your 300 developers already have an account created (on the LDAP side), just need to login at least once in Gitea in order to be notified, if that's what you're after. I now see this ticket was closed because nobody could reproduce, and was reopened in https://github.com/go-gitea/gitea/issues/2610#issuecomment-624646684 Gitea 1.9.5 still works for us with LDAP accounts.
GiteaMirror commented 2025-11-02 03:48:34 -06:00
Author
Owner
Copy Link

@webmutation commented on GitHub (May 8, 2020):

actually wrong word, "activate" is what I wanted to say... yes users exist on LDAP, but they cannot login with their LDAP credentials until they are manually added to the gitea accounts.
In other words until they are manually activated they do not exist in the gitea authentication realm and require a manual operation by an admin. This is what we would prefer to avoid, since it is already connected to LDAP, why does it not behave like most LDAP authentication software and require the accounts to be manually created?!

To give you a counter example in nexus, if we activate a LDAP group, then everyone in that group can login to Nexus, no one needs to go there and activate per user or add them one by one.

@webmutation commented on GitHub (May 8, 2020): actually wrong word, "activate" is what I wanted to say... yes users exist on LDAP, but they cannot login with their LDAP credentials until they are manually added to the gitea accounts. In other words until they are manually activated they do not exist in the gitea authentication realm and require a manual operation by an admin. This is what we would prefer to avoid, since it is already connected to LDAP, why does it not behave like most LDAP authentication software and require the accounts to be manually created?! To give you a counter example in nexus, if we activate a LDAP group, then everyone in that group can login to Nexus, no one needs to go there and activate per user or add them one by one.
GiteaMirror commented 2025-11-02 03:48:34 -06:00
Author
Owner
Copy Link

@guillep2k commented on GitHub (May 9, 2020):

#8814 might be of interest. or not. Sorry, I've got confused. 😅

@guillep2k commented on GitHub (May 9, 2020): ~~#8814 might be of interest.~~ or not. Sorry, I've got confused. 😅
GiteaMirror commented 2025-11-02 03:48:35 -06:00
Author
Owner
Copy Link

@strk commented on GitHub (May 10, 2020):

@webmutation the behaviour you want is EXACTLY as the LDAP support is supposed to work, and I see it working on our systems (using Gitea 1.9.5) - what version of Gitea are you having problems with ? Can you confirm that 1.9.5 works (the original submission mentions Gitea 1.2.x)

@strk commented on GitHub (May 10, 2020): @webmutation the behaviour you want is EXACTLY as the LDAP support is supposed to work, and I see it working on our systems (using Gitea 1.9.5) - what version of Gitea are you having problems with ? Can you confirm that 1.9.5 works (the original submission mentions Gitea 1.2.x)
GiteaMirror commented 2025-11-02 03:48:35 -06:00
Author
Owner
Copy Link

@webmutation commented on GitHub (May 11, 2020):

Current version installed is 1.7.0. I will ask for an upgrade and see if that resolves the issue. Thank you, I will verify that it is working as expected, if not I will reopen the issue.

@webmutation commented on GitHub (May 11, 2020): Current version installed is 1.7.0. I will ask for an upgrade and see if that resolves the issue. Thank you, I will verify that it is working as expected, if not I will reopen the issue.
GiteaMirror commented 2025-11-02 03:48:35 -06:00
Author
Owner
Copy Link

@MCF commented on GitHub (May 11, 2020):

The behavior that strk describes above has worked in gitea for many years - long before version 1.7.0. It is possible that upgrading may either fix your problem or shed a little more light on it, but I think it is unlikely.

I'd look at your LDAP + gitea configuration. Check your LDAP server's logs carefully, check the gitea logs carefully. Might want to run gitea server from the command line and check the console output as it used to be the case that extra error information was only displayed on the console. Otherwise you could compile gitea from source and add extra debugging printouts around LDAP login and user creation. Gitea is relatively easy to compile from source.

@MCF commented on GitHub (May 11, 2020): The behavior that strk describes above has worked in gitea for many years - long before version 1.7.0. It is possible that upgrading may either fix your problem or shed a little more light on it, but I think it is unlikely. I'd look at your LDAP + gitea configuration. Check your LDAP server's logs carefully, check the gitea logs carefully. Might want to run gitea server from the command line and check the console output as it used to be the case that extra error information was only displayed on the console. Otherwise you could compile gitea from source and add extra debugging printouts around LDAP login and user creation. Gitea is relatively easy to compile from source.
GiteaMirror commented 2025-11-02 03:48:36 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jul 11, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Jul 11, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.
GiteaMirror commented 2025-11-02 03:48:36 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jul 26, 2020):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Jul 26, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/stale
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#1097
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?