Skip to content

ApacheDS

Directory service for central authentication and authorization. The key feature of this service is the implementation of the LDAP protocol, which can be consumed by most services.

Project website: https://directory.apache.org/apacheds/

Hierarchy structure

Service accounts

Path: ou=bind,ou=ecg

Provide bind users for client services (e.g. Nextcloud, gitea)

User accounts and mailbox shadow entries

Path: ou=users,ou=ecg

Provides two types of entries:

  • users: representing the ECG members
  • mailbox shadow entries: acting as a shadow account for email boxes of certain ECG groups. Their purpose is to have an account for additional email boxes that as accessible via the LDAP protocol and thus allows us finer grained processes around account overview and password control.

The two types can be distinguished by the following rules:

  • users have a givenName attribute

    Example search query: ldapsearche "(givenName=*)"

  • mailbox shadow accounts have no givenName attribute. Also the values of dn, sn and displayName MUST contain the same value (but only for the sake of discriminability).

    Example search query: ldapsearche "(!(givenName=*))"

Groups

Path: ou=users,ou=ecg

Contains all types of groups:

  • functional (e.g. FED_DE_LC_Berlin)
  • technical (e.g. admin_gitea)

Attributes

Users

  • objectClass: currently inetOrgPerson is used as the default type
  • uid: generated following a defined convention (TBD: where is that documented?)
  • givenName: The given name of the member. Non restrictions here regarding special characters
  • cn and displayName: The human readable display name of that member

  • description: The private email address of that member.

    Purpose: second factor secret for password recovery

  • mail: The ECG email address

  • employeeNumber: The member id of the old (pre migration) user backoffice. Currently not used anywhere. Not sure whether this might be used in the future.
  • userPassword: for authentication in client services

Groups

  • cn: They follow a defined naming convention (TBD: where is that documented?)

Design decisions

  • root node ou=ecg: The initial value predefined by Hostsharing was ou=ecogood,ou=org. That was semantically fine, but practically too long for no reason. They were asked to changed that into o=ecg. The provider failed to implement that and ended up with the current value. Later investigation showed that this didn't happen due to technical limits. Probably the provider failed by renaming the existing partition instead of creating a sane configuration from scratch.

Alternative hierarchy structure

This is an alternative approach which is developed to overcome all historical shortcomings and provide a clear and sane structure.

The only reason that prevents from a migration is the lack of a user management software, that is sustainable from the ECG's point of view. Currently we are using the LDAPadmin. As this tool is far from optimal, it's still working mostly reliable and has support from the provider Hostsharing.

  • o=ecg
    • ou=users
      • ou=members: members of the ECG in terms of humans
      • ou=functional: backing accounts for the group email boxes (presse, etc.)
      • ou=technical: e.g. nc.folderadmin
      • ou=service: bind users for client services like gitea or Nextcloud
    • ou=groups
      • functional: all functional and potentially self managed groups that represent group entities from the ECG like FED_DE_LC_Berlin
      • admins: administrator group per service like nextcloud, wiki

The currently existing mailbox shadow entries shall be mapped in a one-by-one relation to the groups. This would vastly simplify the maintenance of these two entities.

Rededicated attributes

Some attributes have been rededicated in their purpose differently as originally defined. They are grouped by their owning service

Gitea

  • manager: contains uid=git,ou=bind,ou=ecg when the user shall have admin permissions in Gitea

Account service backend

Currently this service tries to cope without an additional separate storage tier. All required values that need to be written are stored in appropriate LDAP entries. Some fields have to be rededicated for that reason.

  • businessCategory: Backup of the userPassword used for the impersonation feature
  • carLicense: Private token for a password reset.
  • stateOrProvinceName: Password reset link creation timestamp