Eigenes Ldap setup

rouven0 commented

2023-09-23 16:09:06 +02:00

(Migrated from github.com)

Portunus sucks

👍 1

tanneberger commented

2023-09-23 16:50:27 +02:00

(Migrated from github.com)

Is there some nicer ldap frontend ?

rouven0 commented

2023-09-23 17:02:19 +02:00

(Migrated from github.com)

Is there some nicer ldap frontend ?

Not really. I'd personally just open the ldaps port to the outside and use some remote LDAP management client like https://directory.apache.org/studio/ or similar

> Is there some nicer ldap frontend ? Not really. I'd personally just open the ldaps port to the outside and use some remote LDAP management client like https://directory.apache.org/studio/ or similar

tanneberger commented

2023-09-24 01:11:56 +02:00

(Migrated from github.com)

This looks like vomit to be frank. What is actually the problem with portunus the looks or is the some key functionality missing ?

fugidev commented

2023-09-24 03:37:34 +02:00

(Migrated from github.com)

This looks like vomit to be frank. What is actually the problem with portunus the looks or is the some key functionality missing ?

I actually really like the web ui, but Portunus does have some major issues and is indeed missing important functionality, not only for our use case.

I think its general approach is far from ideal: As I understand it, Portunus sees its own database as the single source of truth, while the puppeteered OpenLDAP is merely supposed to serve a read-only copy of the data. Instead of relying on OpenLDAP as the backend, Portunus tries to reinvent the wheel and implement authentication and so on itself, just for its web ui. This is IMHO a lot of unnecessary effort, and it causes a list of problems:

it is by design impossible to modify anything from the LDAP side, e.g. let users change their own password using passwd
sha256 password hashes are the only ones it knows how to handle, so many of our migrated accounts can not even log in to the web ui (they can still use our services, because OpenLDAP can handle it just fine)
- this is obviously bad, as there is no way for them to change their password without asking an admin for help
- there is also no way to migrate to a different hashing algorithm, should it be necessary
Portunus only lets you use either insecure LDAP or LDAPS (patched by us)
- having both is useful, since dex pretty much requires LDAPS, while it is unnecessarily complicated to configure LDAPS in a sensible way for some services, which are running on the same host anyway
having e.g. an umlaut in your name (very common) silently breaks things, because the gecos field is not being ascii-escaped. Portunus happily accepts it, but OpenLDAP does not. (patched by us)
Portunus requires first and last names (patched by us)
- not all existing accounts fit that requirement
- not all humans fit that requirement, see this

I believe that using plain OpenLDAP as a base, with some (simple to use) client / management software for administration and possibly self service, would be a better approach that does not have those problems.

> This looks like vomit to be frank. What is actually the problem with portunus the looks or is the some key functionality missing ? I actually really like the web ui, but Portunus does have some major issues and is indeed missing important functionality, not only for our use case. I think its general approach is far from ideal: As I understand it, Portunus sees its own database as the single source of truth, while the puppeteered OpenLDAP is merely supposed to serve a read-only copy of the data. Instead of relying on OpenLDAP as the backend, Portunus tries to reinvent the wheel and implement authentication and so on itself, just for its web ui. This is IMHO a lot of unnecessary effort, and it causes a list of problems: - it is by design impossible to modify anything from the LDAP side, e.g. let users change their own password using `passwd` - sha256 password hashes are the only ones it knows how to handle, so many of our migrated accounts can not even log in to the web ui (they can still use our services, because OpenLDAP can handle it just fine) - this is obviously bad, as there is no way for them to change their password without asking an admin for help - there is also no way to migrate to a different hashing algorithm, should it be necessary - Portunus only lets you use either insecure LDAP or LDAPS (patched by us) - having both is useful, since dex pretty much requires LDAPS, while it is unnecessarily complicated to configure LDAPS in a sensible way for some services, which are running on the same host anyway - having e.g. an umlaut in your name (very common) silently breaks things, because the gecos field is not being ascii-escaped. Portunus happily accepts it, but OpenLDAP does not. (patched by us) - Portunus requires first and last names (patched by us) - not all existing accounts fit that requirement - not all humans fit that requirement, see [this](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/) I believe that using plain OpenLDAP as a base, with some (simple to use) client / management software for administration and possibly self service, would be a better approach that does not have those problems.

👍 1

rouven0 commented

2023-09-24 09:51:55 +02:00

(Migrated from github.com)

We could try to spin up https://github.com/dnknth/ldap-ui as web ui. This looks quite promising and uses openldap as backend

mhaehnel commented

2023-09-24 12:28:13 +02:00

(Migrated from github.com)

Why not use lam as we did on Kaki, if you just want a nice frontend for (Open-)LDAP? I actually like it and use it privately as well. Plus it has a long maintenance history, so it is not likely to go away anytime soon.

Why not use [lam](https://www.ldap-account-manager.org/) as we did on Kaki, if you just want a nice frontend for (Open-)LDAP? I actually like it and use it privately as well. Plus it has a long maintenance history, so it is not likely to go away anytime soon.

👀 1

rouven.seifert commented

2024-05-13 15:48:02 +02:00

Owner

Die Natur, dass Portunus bei jedem Neustart alle Nutzer neu anlegt macht das Keycloak kaputt.

rouven.seifert commented

2024-09-04 14:15:05 +02:00

Owner

Hier initiale Nix-Config, welche nicht funktioniert:

  services.openldap = {
    enable = true;
    urlList = [ "ldap:///" ];
    settings = {
      attrs = {
        olcLogLevel = "conns config";
      };
      children = {
        "cn=schema".includes = [
          "${pkgs.openldap}/etc/schema/core.ldif"
          # attributetype ( 9999.1.1 NAME 'isMemberOf'
          # DESC 'back-reference to groups this user is a member of'
          # SUP distinguishedName )
          "${pkgs.openldap}/etc/schema/cosine.ldif"
          "${pkgs.openldap}/etc/schema/inetorgperson.ldif"
          "${pkgs.openldap}/etc/schema/nis.ldif"
          # "${pkgs.writeText "openssh.schema" ''
          # 	attributetype ( 9999.1.2 NAME 'sshPublicKey'
          # 		DESC 'SSH public key used by this user'
          # 		SUP name )
          # ''}"
        ];

        "olcDatabase={1}mdb".attrs = {
          objectClass = [ "olcDatabaseConfig" "olcMdbConfig" ];

          olcDatabase = "{1}mdb";
          olcDbDirectory = "/var/lib/openldap/data";

          olcSuffix = "dc=ifsr,dc=de";

          /* your admin account, do not use writeText on a production system */
          olcRootDN = "cn=portunus,dc=ifsr,dc=de";
          olcRootPW = "{CRYPT}$y$j9T$xdf4HigfhmQWXn.bw9MgH/$91evhYAV1GP7olNCkQoCpUZrghh5P8dDXcZdAtpiD32";

          olcAccess = [
            /* custom access rules for userPassword attributes */
            ''{0}to attrs=userPassword
                by self write
                by anonymous auth
                by * none''

            /* allow read on anything else */
            ''{1}to *
                by * read''
          ];
        };
      };
    };
  };

Hier initiale Nix-Config, welche nicht funktioniert: ```nix services.openldap = { enable = true; urlList = [ "ldap:///" ]; settings = { attrs = { olcLogLevel = "conns config"; }; children = { "cn=schema".includes = [ "${pkgs.openldap}/etc/schema/core.ldif" # attributetype ( 9999.1.1 NAME 'isMemberOf' # DESC 'back-reference to groups this user is a member of' # SUP distinguishedName ) "${pkgs.openldap}/etc/schema/cosine.ldif" "${pkgs.openldap}/etc/schema/inetorgperson.ldif" "${pkgs.openldap}/etc/schema/nis.ldif" # "${pkgs.writeText "openssh.schema" '' # attributetype ( 9999.1.2 NAME 'sshPublicKey' # DESC 'SSH public key used by this user' # SUP name ) # ''}" ]; "olcDatabase={1}mdb".attrs = { objectClass = [ "olcDatabaseConfig" "olcMdbConfig" ]; olcDatabase = "{1}mdb"; olcDbDirectory = "/var/lib/openldap/data"; olcSuffix = "dc=ifsr,dc=de"; /* your admin account, do not use writeText on a production system */ olcRootDN = "cn=portunus,dc=ifsr,dc=de"; olcRootPW = "{CRYPT}$y$j9T$xdf4HigfhmQWXn.bw9MgH/$91evhYAV1GP7olNCkQoCpUZrghh5P8dDXcZdAtpiD32"; olcAccess = [ /* custom access rules for userPassword attributes */ ''{0}to attrs=userPassword by self write by anonymous auth by * none'' /* allow read on anything else */ ''{1}to * by * read'' ]; }; }; }; }; ```

Eigenes Ldap setup #72