[Date Prev][Date Next]
Re: Synchronize LDAP with DCE ?
At 07:15 AM 6/29/99 -0700, Booker Bense wrote:
>On Fri, 25 Jun 1999, Kurt D. Zeilenga wrote:
>> Note: overloading userPassword with the kerberos may not actual be wise.
>- IMHO, this is a really bad idea. One of the really nice advantages
>of the current krbName approach is that it effectively gives you a
>convient "group" or role mechanism. i.e. an ldap DN can have many
>krbNames. Also, there are potential uses for krbName beyond kerberos
>- Overloading UserPassword with SASL mechanisms doesn't make
>a whole lot of sense to me.
We're not overloading userPassword with SASL mechanisms. We
are encrypting userPassword. SASL is orthogonal to the encryption
of the userPassword value as stored in the directory.
For security reasons, a server should not maintain knowledge
of cleartext passwords. I would hope no SASL mechanism which
required such knowledge.
>Doing this kind of embedding makes ACL's even more difficult.
userPassword (encrypted or not) should be protected. This
protection may be based upon authentication method, SASL mechanism,
and/or wether or not the wire in encrypted.
>In this one case ( unix pwds ) I guess
>it makes some sense, but as a general principal, I think it's a
>REALLY BAD IDEA.
I disagree. Storing and providing cleartext passwords is
dangerous. SASL can be used to provide secure authentication
but such does not reduce the need to store and provide an
encrypted userPassword values. cleartext passwords are evil
and should be avoided. (I highly recommend --disable-cleartext).
As far as ACL goes, the use of SASL bind does NOT imply
secure authentication nor transport. And simple bind does
NOT imply insecure authentication and transport. The
server's ACL mechanism should support simple who clauses:
as well as detail who clauses:
This would allow:
by auth=insecure none # disallow insecure auth
by trans=insecure compare # only auth if insecure trans
by trans=secure self write # self write if trans is secure
by * none # default none