OpenLDAP has a proxy backend, and it has been suggested we could provide one also. This could be useful in situations today where cloud vendors offer LDAP interfaces to allow an office to have an onsite cache.
This could be implemented by a caching system for the chaining db (which may exist? Reading the docs I don't obviously see it, but if it does exist, I'd love to know). Or it could be a unique backend implementation in parallel to ldbm/chaining.
We should consider that AD is a target, so schema validation would probably not possible. Additionally, we may not be able to read the password hashes from the remote, so we would catch-and-proxy binds, then cache the userPassword in our own internal method on our cache entry.
It would potentially valuable to think about how to implement this effectively for these customer cases. Even more so as RHEL/SUSE are removing OpenLDAP, this feature is another area where we can then act as a complete replacement for OpenLDAP.
cc @darix
Metadata Update from @mreynolds: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Issue set to the milestone: FUTURE
Metadata Update from @mreynolds: - Issue priority set to: normal
Metadata Update from @mreynolds: - Issue tagged with: openldap
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/3494
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.