Issue 8166 - translucent overlay - compatibility with other overlays that need write access
Summary: translucent overlay - compatibility with other overlays that need write access
Status: UNCONFIRMED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: overlays (show other issues)
Version: 2.4.40
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-08 08:07 UTC by thomcz@gmail.com
Modified: 2020-03-20 23:16 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description thomcz@gmail.com 2015-06-08 08:07:22 UTC
Full_Name: Thomas Keil
Version: 2.4.40
OS: Debian 8.0 Jessie
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (139.30.84.202)


This is a software enhancement request.

I have the following use case at hand:
My university provides a central LDAP directory which authenticates users but
does not contain group information. For my institute we want to set up our own
OpenLDAP server which relays the user authentication to the central directory
(via back_ldap) but additionally provides group information. This should be used
by a network of linux machines for user authentication, group management and
login filtering. For reasons of high availability we want to replicate our local
LDAP server using the builtin replication mechanism of OpenLDAP.

This seems to be a nice example for the use of the translucent backend.
Nevertheless group membership (for login filtering) can only be provided using
the memberof overlay which (so it seems) is not compatible with the translucent
overlay.
Furthermore the syncprov overlay needs to access the lastmod attribute which is
disabled for databases using the translucent overlay. Thus a local database
combined with the translucent overlay cannot be replicated at all.

To me it seems that these problems can be solved by allowing write access to the
local database for other overlays when used in combination with the translucent
overlay. It would make this overlay much more useful than it is right now since
it would allow to use this in large scale deployments as well (where replication
is essential). This is valid especially for cases where the local administration
has no write access to the central directory.