first post of april, and its on april fools day. very funny indeed. anyways, i experimented with ldap through lldap, i installed it through the debian packages. this was done through a proxmox ve script. at first i deployed it and put it behind npm. i did not really think much of it since i did not know where to slot ldap into my environment. everything is managed within its own app, meaning each application has its own username and password. there is no ‘centralized’ management of users. i sort of created some management by authentik and keycloak, but those were only for the services that supported saml and oidc.

the other services that do not support it, well they had to stay on their own user management system. i really thought about it, if i really needed ldap. it would be nice to have central management of users, but realistically, it would add more complexity that was unneeded for my ‘organization’ requirements. but nonetheless i did try it out. upon deployment, i created a new admin user and that was it.

further research and looking through the file system, i found the configuration directory, which is under:
/etc/lldap

in this directory is the .toml file, which is used to configure the ldap server. it configures the admin credentials, the dn, smtp mail, and server security. i only configured it for my needs, so i set the admin credentials, changed the jwt password, changed the dn to my personal domain name, and added smtp credentials.

it seems that it takes the updates right away, but i always ensure to do a reboot. once configuring this, i went into keycloak and added a user federation source. the configuration for keycloak is on lldap’s github, but it is pretty straight forward. following the steps, i was able to get the ldap to be recognized, but the authentication part got me messed up. for some reason, even after specifying the ou of the user, it still did not work. so i put in the actual defaults and changed the dc to my domain name, and it worked just fine. i suppose keeping the ou to ‘people’ is what made it work.

once ldap was successfully recognized and authenticated to, it synced the users just fine. the groups required an additional mapper to be configured. as it is an ldap server, it is read only, meaning users existing in keycloak or whaterver idp, it will not be imported to lldap.

when i had to where i liked it, i just removed the user federation as i did not see a use case for ldap. i think it will be useful in the future, maybe, but until then, my user management will reside in keycloak. main reason being is that i can manage keycloak through the rest api with ansible playbooks. and i am not sure how i would automate lldap user creation. i think in the eyes of a small business, managing users through keycloak or whatever idp is fine. if the user base does increase, lldap can make its case.

i already have a defined process of managing user provisioning, so i am good for now. i know it works well and why change what already is not broken. the only thing is that i am running two different idps at the moment, so management is already complex, but i say that it is worth it. splitting local sso and public sso. keycloak seems more enterprise ready out of the box, while authentik looks great as a user friendly small business solution. regardless, i can see it being used for any application, it comes down to what the organization/business needs. good to know both at some functional level.