I have changed the email addresses for 3 users in Gitea, they had a different address than in LDAP
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 13 accounts in Gitea, all members of the Hackerhouse, Kosmos and/or Kredits organizations. Except for this user, https://gitea.kosmos.org/LemonAndroid, that starred 2 repos and followed Bumi. He hasn't logged in since creating the account though, should I delete it? Is it a friend of yours @bumi?
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
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";)
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 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=xmpp,ou=kosmos.org,cn=applications,dc=kosmos,dc=org (I haven't created a user for gitea yet)
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.
This is running on andromeda and working. I have also updated the directory structure in the wiki: https://wiki.kosmos.org/Infrastructure:LDAP
I found a good solution. LDAP accounts used to filter users will be moved be under cn=applications,dc=kosmos,dc=org, for example cn=xmpp,ou=kosmos.org,cn=applications,dc=kosmos,dc=org. Then everything under cn=users,dc=kosmos,dc=org are actual users
# applications, kosmos.org
dn: cn=applications,dc=kosmos,dc=org
objectClass: top
objectClass: organizationalRole
cn: users
# kosmos.org, applications, kosmos.org
dn: ou=kosmos.org,cn=applications,dc=kosmos,dc=org
objectClass: top
objectClass: organizationalUnit
ou: kosmos.org
# 5apps.com, applications, kosmos.org
dn: ou=5apps.com,cn=applications,dc=kosmos,dc=org
objectClass: top
objectClass: organizationalUnit
description: 5apps
ou: 5apps.com
# xmpp account, used by ejabberd to search for users and change passwords
dn: cn=xmpp,ou=kosmos.org,cn=applications,dc=kosmos,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: xmpp
userPassword: {SSHA512}snip
# xmpp account, used by ejabberd to search for users and change passwords
dn: cn=xmpp,ou=5apps.com,cn=applications,dc=kosmos,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: xmpp
userPassword: {SSHA512}snip
ACIs need to be set on the Organizational Units to allow the applications accounts to perform the searches
# 5apps.com, users, kosmos.org
dn: ou=5apps.com,cn=users,dc=kosmos,dc=org
changetype: modify
replace: aci
aci: (target="ldap:///cn=*,ou=5apps.com,cn=users,dc=kosmos,dc=org")(targetattr="cn
This has revealed a flaw in the new directory structure. If we remove the filtering altogether, LDAP read-only accounts for the wiki and xmpp become valid XMPP accounts.
Right now my solution is to turn these accounts from a person to a organizationalPerson. Then the filter would look like this (a person, but not an organizationalPerson). In LDAP an organizationalPerson is also a person since it's "subclassing" it.
(&(objectClass=person)(!(objectClass=organizationalPerson)))
The ACIs will also need to be updated to add the objectClass attribute to the list of allowed attributes for the read-only account, because they are not part of the list for now
# kosmos.org, users, kosmos.org
dn: ou=kosmos.org,cn=users,dc=kosmos,dc=org
changetype: modify
replace: aci
aci: (target="ldap:///cn=*,ou=kosmos.org,cn=users,dc=kosmos,dc=org")(targetattr="cn
Docs are on the wiki for the new directory structure: https://wiki.kosmos.org/Infrastructure:LDAP