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


At 03:54 PM 8/30/00 -0500, David Cahlander wrote:
>Thanks for the insight into the openldap design for DIGEST-MD5.
>Perhaps this does not apply to openldap 2.0:
>1. If a directory is replicated, do you also need to replicate the
>DIGEST-MD5 database (to other machines)?

Yes, the SASLdb needs to be replicated... or a more appropriate
mechanism (e.g. GSSAPI) used.  [password-based mechanisms are not
well suited to distributed environments]

>2. When Cyrus authenticates a user, how does this get mapped to
>the authentication of a particular DN?  i.e. how does the Cyrus
>authentication of "kurt" get mapped to authentication of
>    cn=Manager,o=openldap,dc=org

We map the authentication id "kurt" and the realm "OPENLDAP.ORG"
to the DN "uid=kurt + realm=OPENLDAP.ORG".  For realm-less mechanisms,
the DN would be just "uid=kurt".  No entry is associated with this
DN.  The DN is used for access control purposes.

>3. Does this design preclude operation with multiple machines?

Yes.  SASLdb is not designed to be replicated.

Note that we could have implemented in directory storage using
Cyrus's existing callback mechanism.  However, it is more
desirable to share secrets with other applications via SASLdb
then to have distributed secrets only usable by the LDAP
servers.  As I previously noted, we're working with Cyrus folks
to provide a plugable (without rebuilding each application)
mechanism for access to authentication secrets.  This will
allow the sharing of secrets between multiple applications
over multiple systems.

For now (and likely in the future), use of Kerberos V and GSSAPI
is highly recommended in multiple application / distributed