[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Question about multiple Backends

> -----Original Message-----
> From: openldap-software-bounces+mhardin=symas.com@OpenLDAP.org
> [mailto:openldap-software-bounces+mhardin=symas.com@OpenLDAP.org] On
> Behalf Of Simon Maier
> Sent: Thursday, January 11, 2007 8:32 AM
> To: openldap-software@openldap.org
> Subject: Question about multiple Backends
> Hi,
> I have a tricky Question, at least I think it ist. At the computing
> center of our university we use a groupware (openxchange). This
> gropware needs a LDAP server with write access. For this reason it
> can't be integrated into the centralised LDAP of the university. Still
> it's the idea, that the users are authenticated against the central
> password store. The problem is the passwords should not be synchronised
> with the centralised database/LDAP-server for security reasons. For the
> same reasons the use of the ldap backend + slapo-translucent +
> slapo-rwm is not possible. The third reason for this is, thata the
> users on this server are only a subset (around 60) of the users on the
> centralised Directory (around 10 000) and it will stay that way.

Maybe I'm missing something, but nothing you've said so far precludes the
use of slapo-translucent. Situations such as this are the reason we
developed the translucent overlay in the first place. Your requirements do
seem contradictory, though: you say that you want users authenticated
against the central password store, yet you the say that the "the passwords
should not be synchronized with the centralised database/LDAP-server for
security reasons." This seems nonsensical- slapo-translucent doesn't
"synchronize" anything. The passwords, such as they are, remain on the
remote LDAP server and should stay there. The slapo-translucent overlay +
back-ldap will pass along the bind request to the remote LDAP server and act
based on its reply. If link security is an issue, encrypt the connection to
the remote directory with SSL. If write access to the password attribute is
permitted by the remote directory, but you don't want a user to use your
groupware app to change it, you can block write access with an ACL.

If I'm missing the point, would you please clarify? 



Matthew Hardin
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: