... | ... | @@ -2137,7 +2137,7 @@ using the [django-auth-ldap][] authentication plugin. |
|
|
[GOsa]: https://github.com/gosa-project/gosa-core
|
|
|
[LDAP account manager]: https://www.ldap-account-manager.org/lamcms/
|
|
|
|
|
|
### commandline tools
|
|
|
### Command-line tools
|
|
|
|
|
|
* [cpu][]: "Change Password Utility", with an LDAP backend, no
|
|
|
release since 2004
|
... | ... | @@ -2151,15 +2151,23 @@ using the [django-auth-ldap][] authentication plugin. |
|
|
[shelldap]: https://hg.sr.ht/~mahlon/shelldap
|
|
|
[ldapvi]: http://www.lichteblau.com/ldapvi/
|
|
|
|
|
|
### others
|
|
|
### Single-sign on
|
|
|
|
|
|
* [Keycloak][]: single-sign-on interface which talks with LDAP
|
|
|
* [FreeIPA][]: similar, except built on top of 389 DS, the Fedora
|
|
|
LDAP thing
|
|
|
|
|
|
A solution could be to deploy Keycloak or some SSO server on *top* of
|
|
|
the current LDAP server to provide other applications with a single
|
|
|
authentication layer. Then the underlying backend could be changed to
|
|
|
swap ud-ldap out if we need to, replacing bits of it as we go.
|
|
|
|
|
|
### Others
|
|
|
|
|
|
* [LDAP synchronization connector][]: "Open source connector to
|
|
|
synchronize identities between an LDAP directory and any data
|
|
|
source, including any database with a JDBC connector, another LDAP
|
|
|
server, flat files, REST API..."
|
|
|
* [Keycloak][]: single-sign-on interface which talks with LDAP
|
|
|
* [FreeIPA][]: similar, except built on top of 389 DS, the Fedora
|
|
|
LDAP thing
|
|
|
* [LDAPjs][]: pure Javascript LDAP client
|
|
|
* [GQLDAP][]: GTK client, abandoned
|
|
|
* [LDAP admin][]: Desktop interface, written in Lazarus/Pascal (!)
|
... | ... | |