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)
* [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)
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.
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
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
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";)
```
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
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.
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).
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`
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
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.)
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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Update the GiteaThe setting to disable Gitea organization creation by default was already in our production configapp.inito disable Gitea organization creation by defaultNo need for a filtered role, all accounts should have access to Gitea.
Gitea authentication docs
I got LDAP authentication to add user accounts to a test Gitea setup (docker-compose).
I used the following settings:
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 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
Got admin users to work. Added
admin: trueto my user, created a user for Gitea and an admin roleRelevant ACIs for users to search and get their own attributes:
Relevant ACIs for the gitea user:
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
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 changed the email addresses for 3 users in Gitea, they had a different address than in LDAP
We need to turn that off, because we agreed that org creation requires a separate donation (or proof of Kosmos contributions).
BTW, I think the task list is out of date, from reading your comments from today...
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.iniI have made a private list that sorts the users in three different categories:
I have updated the checklist. We have to write a different email for each category
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.)
I created a pad for the emails: https://cryptpad.fr/code/#/2/code/edit/cLRIbvVL0lh7BWBG+Qxhpzsw/
Could I get some feedback or corrections?
I have edited the emails quite a bit. Looks good to me now.
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
Nice. Great work 👍
W00t w0000t!