Enable LDAP support on Gitea #139

New Issue

greg · 2020-02-20T16:02:52Z

greg commented

2020-02-20 16:02:52 +00:00

Remove all the users without repos & comments (some users don't have repos but have commented in some issues)
Deal with users' email addresses (some are different between LDAP and Gitea right now)
Run a development Gitea and enable LDAP support on it to do experiments
Figure out how to allow whether or not a user can create a Gitea organization
Prepare users LDIF file with autogenerated passwords in LDAP for people without an account (4 users)
Make a list of users and group them by state (Gitea users that already have a LDAP account, LDAP users that do not have a Gitea account yet, Gitea users that do not have a LDAP account)
~~Update the Gitea app.ini to disable Gitea organization creation by default~~ The setting to disable Gitea organization creation by default was already in our production config
Add the admin attribute to LDAP users that need to be Gitea admins
Create new users with autogenerated passwords in LDAP for people without an account
Write an email for users with a Gitea account (with auto-generated password for the users without an existing LDAP account)
Set a time and date for the migration: Thursday 4 March at 15:45 CET (https://everytimezone.com/s/706beb65).
Send the emails at least 24 hours in advance
Create the Authentication Source in production (disabled)
Enable the Authentication Source in production

No need for a filtered role, all accounts should have access to Gitea.

* [x] Remove all the users without repos & comments (some users don't have repos but have commented in some issues) * [x] Deal with users' email addresses (some are different between LDAP and Gitea right now) * [x] Run a development Gitea and enable LDAP support on it to do experiments * [x] Figure out how to allow whether or not a user can create a Gitea organization * [x] Prepare users LDIF file with autogenerated passwords in LDAP for people without an account (4 users) * [x] Make a list of users and group them by state (Gitea users that already have a LDAP account, LDAP users that do not have a Gitea account yet, Gitea users that do not have a LDAP account) * [x] <strike>Update the Gitea `app.ini` to disable Gitea organization creation by default</strike> The setting to disable Gitea organization creation by default was already in our production config * [x] Add the admin attribute to LDAP users that need to be Gitea admins * [x] Create new users with autogenerated passwords in LDAP for people without an account * [x] Write an email for users with a Gitea account (with auto-generated password for the users without an existing LDAP account) * [x] Set a time and date for the migration: Thursday 4 March at 15:45 CET (https://everytimezone.com/s/706beb65). * [x] Send the emails at least 24 hours in advance * [x] Create the Authentication Source in production (disabled) * [x] Enable the Authentication Source in production No need for a filtered role, all accounts should have access to Gitea. [Gitea authentication docs](https://docs.gitea.io/en-us/authentication/#ldap-lightweight-directory-access-protocol)

greg referenced this issue

2020-02-20 16:03:08 +00:00

Switching services to unified accounts with LDAP #126

greg self-assigned this 2020-02-28 11:56:08 +00:00

greg commented

2020-02-28 12:25:18 +00:00

I got LDAP authentication to add user accounts to a test Gitea setup (docker-compose).

I used the following settings:

Authentication Type: LDAP (via BindDN)
Security Protocol: LDAPS
Host: ldap.kosmos.org
Port: 636
Bind DN: uid=gitea,ou=kosmos.org,cn=applications,dc=kosmos,dc=org
Bind Password: secret
User Search Base: ou=kosmos.org,cn=users,dc=kosmos,dc=org
User Filter: (&(objectClass=person)(cn=%s))
Username Attribute: cn
Email Attribute: mail

Enable User Synchronization: true

~~Right now I cannot login through LDAP, I'm figuring out what is missing.~~ Then I will add an attribute for Gitea admin users. By default the users created from LDAP can create Gitea organizations.

I got LDAP authentication to add user accounts to a test Gitea setup (docker-compose). I used the following settings: ```txt Authentication Type: LDAP (via BindDN) Security Protocol: LDAPS Host: ldap.kosmos.org Port: 636 Bind DN: uid=gitea,ou=kosmos.org,cn=applications,dc=kosmos,dc=org Bind Password: secret User Search Base: ou=kosmos.org,cn=users,dc=kosmos,dc=org User Filter: (&(objectClass=person)(cn=%s)) Username Attribute: cn Email Attribute: mail Enable User Synchronization: true ``` <strike>Right now I cannot login through LDAP, I'm figuring out what is missing.</strike> Then I will add an attribute for Gitea admin users. By default the users created from LDAP can create Gitea organizations.

greg commented

2020-02-28 12:47:24 +00:00

I can now login in my test Gitea instance, the issue was missing ACIs on users that allow them to read and search their own attributes. The way Gitea has implemented LDAP support using BindDN requires it

greg commented

2020-02-28 13:19:49 +00:00

Got admin users to work. Added admin: true to my user, created a user for Gitea and an admin role

# gitea account, used by gitea to search for users
dn: uid=gitea,ou=kosmos.org,cn=applications,dc=kosmos,dc=org
objectClass: simpleSecurityObject
objectClass: account
uid: gitea
userPassword: secret

# admin role, for Gitea admins
dn: cn=admin_role,ou=kosmos.org,cn=users,dc=kosmos,dc=org
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: admin_role
nsRoleFilter: (&(objectclass=person)(admin=true))
Description: filtered role for admins

Relevant ACIs for users to search and get their own attributes:

# users, kosmos.org
dn: dc=kosmos,dc=org
changetype: modify
replace: aci
[snip]
aci: (target="ldap:///dc=kosmos,dc=org")(targetattr="*") (version 3.0; acl "user-read-search-own-attributes"; allow (read,search) userdn="ldap:///self";)
[snip]

Relevant ACIs for the gitea user:

# kosmos.org, users, kosmos.org
dn: ou=kosmos.org,cn=users,dc=kosmos,dc=org
changetype: modify
replace: aci
[snip]
aci: (target="ldap:///cn=*,ou=kosmos.org,cn=users,dc=kosmos,dc=org")(targetattr="userPassword") (version 3.0; acl "xmpp-kosmos-change-password"; allow (write) userdn="ldap:///uid=xmpp,ou=kosmos.org,cn=applications,dc=kosmos,dc=org";)

Got admin users to work. Added `admin: true` to my user, created a user for Gitea and an admin role ```ldif # gitea account, used by gitea to search for users dn: uid=gitea,ou=kosmos.org,cn=applications,dc=kosmos,dc=org objectClass: simpleSecurityObject objectClass: account uid: gitea userPassword: secret # admin role, for Gitea admins dn: cn=admin_role,ou=kosmos.org,cn=users,dc=kosmos,dc=org objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: admin_role nsRoleFilter: (&(objectclass=person)(admin=true)) Description: filtered role for admins ``` Relevant ACIs for users to search and get their own attributes: ```ldif # users, kosmos.org dn: dc=kosmos,dc=org changetype: modify replace: aci [snip] aci: (target="ldap:///dc=kosmos,dc=org")(targetattr="*") (version 3.0; acl "user-read-search-own-attributes"; allow (read,search) userdn="ldap:///self";) [snip] ``` Relevant ACIs for the gitea user: ```ldif # kosmos.org, users, kosmos.org dn: ou=kosmos.org,cn=users,dc=kosmos,dc=org changetype: modify replace: aci [snip] aci: (target="ldap:///cn=*,ou=kosmos.org,cn=users,dc=kosmos,dc=org")(targetattr="userPassword") (version 3.0; acl "xmpp-kosmos-change-password"; allow (write) userdn="ldap:///uid=xmpp,ou=kosmos.org,cn=applications,dc=kosmos,dc=org";) ```

greg commented

2020-02-28 13:23:57 +00:00

There is a cron job in Gitea to synchronize users from an external source such as Gitea. By default it runs every 24 hours, and does not run on startup. It only runs if the auth source has "User Synchronization" enabled on it: example config.

Alternatively, when a user successfully logs in for the first time from an LDAP account, the user is automatically created in the Gitea database if it did not exist already

There is a cron job in Gitea to synchronize users from an external source such as Gitea. By default it runs every 24 hours, and does not run on startup. It only runs if the auth source has "User Synchronization" enabled on it: [example config](https://github.com/go-gitea/gitea/blob/8d2059a20184842d9a7a573d285956dd998d42c4/custom/conf/app.ini.sample#L843). Alternatively, when a user successfully logs in for the first time from an LDAP account, the user is automatically created in the Gitea database if it did not exist already

greg commented

2020-02-28 14:48:55 +00:00

I have renamed my own user (from the user settings page from gregkare to greg.

I have also performed a spring cleanup on the user accounts. Now we have 12 accounts in Gitea, all members of the Hackerhouse, Kosmos and/or Kredits organizations.

I have renamed my own user (from the [user settings page](https://gitea.kosmos.org/user/settings) from gregkare to greg. I have also performed a spring cleanup on the user accounts. Now we have 12 accounts in Gitea, all members of the Hackerhouse, Kosmos and/or Kredits organizations.

greg commented

2020-02-28 15:28:15 +00:00

I have changed the email addresses for 3 users in Gitea, they had a different address than in LDAP

raucao commented

2020-02-28 15:45:54 +00:00

By default the users created from LDAP can create Gitea organizations

We need to turn that off, because we agreed that org creation requires a separate donation (or proof of Kosmos contributions).

> By default the users created from LDAP can create Gitea organizations We need to turn that off, because we agreed that org creation requires a separate donation (or proof of Kosmos contributions).

raucao commented

2020-02-28 15:46:38 +00:00

BTW, I think the task list is out of date, from reading your comments from today...

greg commented

2020-02-28 16:15:04 +00:00

I found the setting to disable organization creation by default (8d2059a201/custom/conf/app.ini.sample (L548)). It needs to be added to our app.ini

I found the setting to disable organization creation by default (https://github.com/go-gitea/gitea/blob/8d2059a20184842d9a7a573d285956dd998d42c4/custom/conf/app.ini.sample#L548). It needs to be added to our `app.ini`

👍 1

greg commented

2020-03-02 16:21:35 +00:00

I have made a private list that sorts the users in three different categories:

Gitea users that already have a LDAP account (8)
LDAP users that do not have a Gitea account (7)
Gitea users that do not have a LDAP account (4)

I have updated the checklist. We have to write a different email for each category

I have made a private list that sorts the users in three different categories: * Gitea users that already have a LDAP account (8) * LDAP users that do not have a Gitea account (7) * Gitea users that do not have a LDAP account (4) I have updated the checklist. We have to write a different email for each category

raucao commented

2020-03-02 16:35:02 +00:00

We do not have to write an email for people who didn't have Gitea accounts yet. I think that email should be a single one to all users, when we have a page explaining their unified account and which services they have access to. (They should also know about the wiki for example.)

We do not have to write an email for people who didn't have Gitea accounts yet. I think that email should be a single one to *all* users, when we have a page explaining their unified account and which services they have access to. (They should also know about the wiki for example.)

greg commented

2020-03-04 13:12:00 +00:00

I created a pad for the emails: https://cryptpad.fr/code/#/2/code/edit/cLRIbvVL0lh7BWBG+Qxhpzsw/

Could I get some feedback or corrections?

I created a pad for the emails: https://cryptpad.fr/code/#/2/code/edit/cLRIbvVL0lh7BWBG+Qxhpzsw/ Could I get some feedback or corrections?

raucao commented

2020-03-04 13:52:04 +00:00

I have edited the emails quite a bit. Looks good to me now.

greg commented

2020-03-05 15:35:07 +00:00

Running in production, closing this one!

We ran into an issue and had to switch the existing user accounts to the LDAP auth source, with the "Authentication Sign-In Name" for each account being the username

Running in production, closing this one! We ran into an issue and had to switch the existing user accounts to the LDAP auth source, with the "Authentication Sign-In Name" for each account being the username

greg closed this issue

2020-03-05 15:35:08 +00:00

galfert commented

2020-03-05 15:41:25 +00:00

Nice. Great work 👍

Nice. Great work :+1:

raucao commented

2020-03-05 16:17:44 +00:00

W00t w0000t!

group-five.gif

500 KiB

Sign in to join this conversation.