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.
Yet the server has access to a webservice of the database. This webservice is given the username and a password and it gives back a vlue of 0, if the user is authenticated, of 1, if the user could not be authenticated and of 2, if the authentication request was submitted by an ip-Adress not authorised to do so.
The usernames are the same on the local LDAP and the database.
My first idea was to use the perl backend to "catch" the passwords during the bind process and implement the bind in perl. Yet I doubt, this is possible.
My next idea was to put the whole subtree under the perl backend and do a rewrite (slapo-rwm) for everything onto a different subtree which would be created similar to the first subtree. The perl Module would only implement 'bind' and 'compare' which are easy to implement in the perl code and return 'unwilling to perform' on any other request, because it can't be implemented by means of the webservice and isn't needed anyway. That way the passwords are not stored on the LDAP-Server and everything should work.
Do you all think this is possible/wise? Is there a better/easier way to reach the goal?
Regards
Simon
Simon Maier wrote:
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
How is the naming defined in the directories? If name spaces are distinct I'd use back-ldap to search user entries during authentication and use the DNs of the central LDAP directory in the access control of the Groupware directory (e.g. directly in ACLs or in group entries).
Ciao, Michael.
-----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?
[...]
Cheers,
-Matt
Matthew Hardin Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-software@openldap.org
-
Matthew Hardin -
Michael Ströder -
Simon Maier