Gitea: User accounts not automatically created via LDAP login

[tobias--]

• 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))

[strk]

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.

[tobias--]

@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.

[MCF]

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.

[lafriks]

@MCF sync is just single checkbox when adding auth source

[strk]

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

[MCF]

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.

[lafriks]

@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.

[MCF]

@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.

[lafriks]

@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

[robe2]

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.

[lafriks]

I also can not seem to be able to reproduce that

[stale[bot]]

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]]

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

[webmutation]

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.

[kidac]

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: [email protected]

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.

[strk]

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

[webmutation]

@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 😄

[strk]

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.

[webmutation]

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.

[guillep2k]

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

[strk]

@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)

[webmutation]

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.

[MCF]

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.

[stale[bot]]

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]]

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