Open 389-ds-bot opened 4 years ago
Comment from mreynolds (@mreynolds389) at 2019-06-13 17:18:50
Metadata Update from @mreynolds389:
Comment from mreynolds (@mreynolds389) at 2020-05-06 16:41:13
Metadata Update from @mreynolds389:
Comment from mreynolds (@mreynolds389) at 2020-05-06 16:41:34
Metadata Update from @mreynolds389:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50436
Issue Description
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