Moving from LDAP (simple) to LDAP Bind

Hi,

I need some help in sorting out an issue with my user accounts.
I run gitea for a small team in-house, and had it working with LDAP (simple) for a long time.

I wanted to ditch creating accounts manually and pull from the security groups in Active Directory.

I have since got LDAP (Bind) to work so that it synchronizes fully with the local Active Directory.

I’m now having an issue where the original accounts username were created with FirstNameLastNameInitial (no space was allowed) but in the Active Directory it is FirstName(Space)LastName. The sync external user data did not change the username field, newer accounts are created correctly from the sync.

I am left with old accounts with usernames like JohnS and newer ones like John Smith.

So I looked through the gitea.db and noticed the user table and spotted the lower_name & name fields.
I edited this to match how the accounts had been entered by the external sync and thought great its all working.
Except when i go to the users that I changed, and click on their local repositories it comes back as an error 500.

If I revert the change back, the user repositories are working except the user account gets de-activated after running the external sync command from the dashboard.

What am I doing wrong!!

I’ve manage to find my answer, turns out that the lower_name & name fields in the user table of the database are used to point to a folder on the file system. So renaming the folder fixed the error 500 I was receiving on the gitea site.

2 Likes

I’m trying to achieve the same. Since you have some experience, would you mind helping me out. First looking inside my database I was hoping to have a populated extrernal_user_login. My table is empty. So where 0should I start looking, nothing is showing up in the log even though I configured my log level to Debug.

Any pointers would be appreciated.

Martin

@Rockyboa
Hi Martin,

Before delving into the database - do all your user accounts work and synchronize to your LDAP?
Have you got a list of users populated from the search match you entered into the LDAP (Bind) fields.

Are you using the Dashboard/Maintenance Operation “synchronize external user data” from the Site Administration pull down menu of your admin account?

Hi Roger,

No I don’t think my user synchronise with my LDAP, which his a Windows 2016 AD DC. The only think I see when I run the synchronise external data is that green popup box at the top stating that the process as started.

Should the user account from the Site Administration pull down menu populate with my LDAP account? The only account showing are the local ones.

To ease my setup, I revert back to unencrypted port 389. I’m suspecting my user filter to be wrong. I took the straight example from the documentation, i.e. (&(objectCategory=Person)(memberOf=CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=aeponyx,DC=com)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))).

Maybe this should be adjusted a bit more accordingly to my env.

Martin

Hi Martin,

I believe your user filter is wrong too…

This is how I setup my Authentication Source (LDAP Bind) with Windows Server 2008 (SBS 2011).

Some assumptions on Windows Server:
I use an user account with read-only attributes solely for accessing the LDAP
I have a security group for Git Access
I have a security group for Git Admins

Verify your match strings with Active Directory Users and Computers on Windows Server.

Authentication Type: LDAP (via BindDN)
Authentication Name: LDAP (BindDN)
Security Protocol: Unencrypted
Host: 192.168.1.20
Port: 389
Bind DN: CN=Admin_RO,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=xxxx,DC=local
Bind Password: ••••••••••
User Search Base: OU=SBSUsers,OU=Users,OU=MyBusiness,DC=xxxx,DC=local
User Filter: (&(objectCategory=Person)(memberOf=CN=Git Access,OU=Security Groups,OU=MyBusiness,DC=xxxx,DC=local)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
Admin Filter: (&(objectCategory=Person)(memberOf=CN=Git Admins,OU=Security Groups,OU=MyBusiness,DC=xxxx,DC=local)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
Username Attribute: sAMAccountName
First Name Attribute: givenName
Surname Attribute: sn
Email Attribute: mail

Check - Fetch Attributes in Bind DN Context
Check - Enable User Synchronisation
Check - This Authentication Source is Activated

This should get your users based on your Windows security groups to now populate your Gitea instance. After this make sure your Gitea users accounts are using the new authentication source instead of using the local source.

See how you get on with this…

Hi Roger,

First thank you, I finally hasd some time to play with this. It is now working as expected. Couple question remains, is there a log output of those synchronisation onn the Gitea server?

Secondly, I also created a read only ldap user that I made a member of a ldap read only security group, made it its primary group and remove Domain User group from this account, would you consider this safe enough or I can go further security wise?

Thank you again.

Martin

Hi Martin,

Glad you have it working…

The log entries should be within your normal log file (gitea.log). My log file is set to Trace and I see the daily synchronizations recorded.

Security wise - I only run internally and for now its good enough for myself. I’m no IT security expert so I have to rely on google searches or from IT audits to be shown the best practices.

1 Like