5 ms·

Here's a new one (that I haven't personally used): https://github.com/kakwa/ldapcherry https://github.com/kakwa/ldapcherry

h1d 8y ago
You said many many UI but that one looks to be very basic which anyone can build in a day. I really find it hard to manage LDAP without a intuitive clean UI and wonder why there aren't much demand for it.
- funkaster 8y ago
  my guess is that many people/orgs they don't use LDAP directly: it's used as the backend to manage permissions, groups, metadata, etc. They prob use their own system that relies on LDAP to manage the details of their org.
- kakwa_ 8y ago
  Not really in a day. You could probably hack something in day, hardcoding things like schemas, fields, and things like that. But having something that is reusable requires more work than a day. Just as an example, even handling ssl/tls is far from trivial (plain ssl vs startls, with certificate validation or not, with a custom CA or not), it took me easily a few days to understand the options python-ldap provides, expose the options in a clear manner in the config file, deal with errors to provide meaningful logs and properly test everything.
kakwa_ 8y ago
And if you are a user, a new version with numerous fixes (including security ones) was just released. Disclaimer: I'm the author of ldapcherry. My motivation was indeed that the go to solution is phpLdapAdmin, which is basically ldapsearch/modify in a web UI. It's a bit too rough and open for general users IMHO. Hopefully ldapcherry provides something simpler and a bit prettier for the users. Also, it's quite common for IT environments to have an ldap server (OpenLdap or 389 directory) and Active Directory (or samba 4 in AD mode). A secondary goal was to manage both at the same time. ldapcherry works both with AD and ldap, creating/modifying a given user in both directories. And it can actually be extended to support other backends. A third motivation was to be able to manage "roles". It's quite common to have ldap/AD groups triggering access to one specific resource (ssh into prod servers with or without root access, access to the git repositories, access to log indexer, etc). But requesting each group individually is a pain, and you end-up with a wild variety of groups set even between members of a given team. That's why ldapcherry has a notion of "roles" (group of groups): for example you click the "sysadmin" role and it will put you in the groups that grant you access to ssh, monitoring, logs, etc. That being said, it has some limitations: * The groups/roles are statically defined in a yaml file, so it's not really dynamic * There is no real tooling to audit/normalize the backends content (for example after a role definition change) * There is no mechanism to temporary delegate a role to a person * There is only one "big" admin group, no notion of "this role can be set by this group, and this other role by this other group" * There is no request/notification mechanism when a user requests approval for being member of a role * I'm not completely sure how I could handle forgotten password for users more cleanly * I'm not sure how the UI would look with hundreds of roles (probably not great since all roles will be displayed...) These are clear limitations that makes ldapcherry not suited for large organizations, but it should work OK for small ones. Also, right now, ldapcherry is mostly stateless. It doesn't need a DB, you just configure it and plug it to your ldap/AD, which means it's fairly simple to deploy. If I were to implement the previously mentioned items, it would probably require a DB, which would increase complexity, and I'm reluctant to do so. Maybe a pluggable module could do the trick, but I would have to create an API for such module in the existing code. Lastly I'm a lone developer with limited skills, and this is a side project, so I don't always have the motivation/time to work on it. I think these few explanations kind of illustrate why there is no decent ldap web UI ^^.

h1d 8y ago

You said many many UI but that one looks to be very basic which anyone can build in a day. I really find it hard to manage LDAP without a intuitive clean UI and wonder why there aren't much demand for it.

funkaster 8y ago
my guess is that many people/orgs they don't use LDAP directly: it's used as the backend to manage permissions, groups, metadata, etc. They prob use their own system that relies on LDAP to manage the details of their org.
kakwa_ 8y ago
Not really in a day. You could probably hack something in day, hardcoding things like schemas, fields, and things like that. But having something that is reusable requires more work than a day. Just as an example, even handling ssl/tls is far from trivial (plain ssl vs startls, with certificate validation or not, with a custom CA or not), it took me easily a few days to understand the options python-ldap provides, expose the options in a clear manner in the config file, deal with errors to provide meaningful logs and properly test everything.

kakwa_ 8y ago

And if you are a user, a new version with numerous fixes (including security ones) was just released. Disclaimer: I'm the author of ldapcherry. My motivation was indeed that the go to solution is phpLdapAdmin, which is basically ldapsearch/modify in a web UI. It's a bit too rough and open for general users IMHO. Hopefully ldapcherry provides something simpler and a bit prettier for the users. Also, it's quite common for IT environments to have an ldap server (OpenLdap or 389 directory) and Active Directory (or samba 4 in AD mode). A secondary goal was to manage both at the same time. ldapcherry works both with AD and ldap, creating/modifying a given user in both directories. And it can actually be extended to support other backends. A third motivation was to be able to manage "roles". It's quite common to have ldap/AD groups triggering access to one specific resource (ssh into prod servers with or without root access, access to the git repositories, access to log indexer, etc). But requesting each group individually is a pain, and you end-up with a wild variety of groups set even between members of a given team. That's why ldapcherry has a notion of "roles" (group of groups): for example you click the "sysadmin" role and it will put you in the groups that grant you access to ssh, monitoring, logs, etc. That being said, it has some limitations: * The groups/roles are statically defined in a yaml file, so it's not really dynamic * There is no real tooling to audit/normalize the backends content (for example after a role definition change) * There is no mechanism to temporary delegate a role to a person * There is only one "big" admin group, no notion of "this role can be set by this group, and this other role by this other group" * There is no request/notification mechanism when a user requests approval for being member of a role * I'm not completely sure how I could handle forgotten password for users more cleanly * I'm not sure how the UI would look with hundreds of roles (probably not great since all roles will be displayed...) These are clear limitations that makes ldapcherry not suited for large organizations, but it should work OK for small ones. Also, right now, ldapcherry is mostly stateless. It doesn't need a DB, you just configure it and plug it to your ldap/AD, which means it's fairly simple to deploy. If I were to implement the previously mentioned items, it would probably require a DB, which would increase complexity, and I'm reluctant to do so. Maybe a pluggable module could do the trick, but I would have to create an API for such module in the existing code. Lastly I'm a lone developer with limited skills, and this is a side project, so I don't always have the motivation/time to work on it. I think these few explanations kind of illustrate why there is no decent ldap web UI ^^.