(I take this point to openldap-technical@openldap.org since it discusses OpenLDAP-specific things.)
Howard Chu wrote:
The discussion of caching here http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such example
- this is purely a client-side implementation issue. Also you give nscd as an
example, and nscd has been thoroughly discredited and is well known to be unsuitable for real use. Critical deployments can use a local LDAP server with a replica of the central data, to avoid error-prone caching implementations. This is a commonly recommended approach when using OpenLDAP nssov, for example.
I really wonder how this replication approach works in practice without disclosing too much data on a system more exposed to attacks from the outside.
In theory one could implement partial replication based on systems's bind identity. But in practice I have some doubts because in a really paranoid setup you don't even want to disclose replication meta data and intermediate entries of the tree structure.
Ciao, Michael.
On 06/01/2014 22:03, Michael Ströder wrote:
(I take this point toopenldap-technical@openldap.org since it discusses OpenLDAP-specific things.)
Howard Chu wrote:
The discussion of caching here http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such example
- this is purely a client-side implementation issue. Also you give nscd as an
example, and nscd has been thoroughly discredited and is well known to be unsuitable for real use. Critical deployments can use a local LDAP server with a replica of the central data, to avoid error-prone caching implementations. This is a commonly recommended approach when using OpenLDAP nssov, for example.
I really wonder how this replication approach works in practice without disclosing too much data on a system more exposed to attacks from the outside.
In theory one could implement partial replication based on systems's bind identity. But in practice I have some doubts because in a really paranoid setup you don't even want to disclose replication meta data and intermediate entries of the tree structure.
Ciao, Michael.
I would prefer to have the option of using a caching implementation that was not error-prone, rather than a local LDAP server with replication. This is because setting up local LDAP servers with replication are not necessarily straightforward, deciding where to implement them becomes troublesome in a large estate, where they are not implemented you may very get poor performance, and not all LDAP servers are supported in a local deployment. Not to mention the security implications that Michael mentions above.
Best regards, Mark.
openldap-technical@openldap.org
-
Mark R Bannister -
Michael Ströder