Re: authentification

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:28 AM 9/6/00 +0200, Michael Weiser wrote:
>> However, LDAP over SSL is deprecated (in favor of Start TLS) as it
>> is not a Standard Track mechanism.  You may run into clients which
>> only support Start TLS.   The current solution is to disable simple
>> bind unless TLS is present (by using an TLS SSF ACL) and then to
>> only to deploy clients which support relatively strong authentication
>> (GSSAPI or TLS+simple or DIGEST-MD5).  
>Currently I'm using a generic ssf as you can see above. This leaves some
>more options than just tls which I hope enables users to seamlessly use
>other authentication/transport security methods like StartTLS once they
>get available.

tls_ssf applies to either StartTLS or LDAP over SSL.
transport_ssf only applies to AF_LOCAL sessions.
sasl_ssf applies to SASL negotiated layers.
ssf is the max of these three values.

Simple bind only makes sense when using TLS (StartTLS or LDAP over SSL)
or AF_LOCAL sessions.  Most folks don't run AF_LOCAL, so I didn't
allow it in my example.  I explicitly didn't use SSF as this includes
any SASL negotiated layers.  It makes little sense to use simple bind
after successfully using SASL.

>Is that assumption right? Does it open any backdoors like
>allowing clients to use weak authentication and then switch to secure
>transport or authenticating securely and then using an unencrypted
>channel?

One of the reasons why there is three independent SSFs is that
LDAP requests are independent of each other.  This gives you
the flexibility to disallow certain combinations of behaviors
(especially those which make little or no sense... such as
StartTLS after authentication).

I also note that we may add additional require and disallow
flags.  I could see "disallow StartTLS_post_bind" as being
worthwhile.   If you have thoughts on this, feel free to
submit an ITS with specific requests (code welcomed as well).

>BTW: As far as I understand StartTLS it's a mechanism for coordinate the
>establishing of a tls connection which then runs normally.

Basically, yes, Start TLS operation is used to coordinate TLS negotiation.
This is the Standard Track mechanism for providing TLS-based security
services (RFC2830).

>Are there any
>mechanisms for enhancing the *normal* LDAP authentication, like some
>cryptographic challenge-response method?

Yes, SASL bind (RFC 2829).

>BTW2: If I run ldapsearch -ZZ I get
>
>ldap_start_tls: Success

This indicates that the server agreed to attempt to Start TLS
but the client was unable to.  As the Start TLS was critical,
ldapsearch stopped processing.  Obviously, error reporting needs
work.

>an nothing else. But if I do a ldapsearch -Z I get
>
>WARNING: could not start TLS

Same as above, excepting the failure to Start TLS was ignored
as it "non-critical".

>Are these the StartTLS problems you mentioned on -devel?

The report issue was amongst many issues discussed on the devel
list.  The key functional issues (which spanned both StartTLS
and ldaps://) were resolved (and included in 2.0.1) (as noted
in CHANGES).

>Oha, so the rootdn configured in slapd.conf stands outside of normal acl 
>checking but honours configured requires/securities/disallows?

Basically, yes.  More correctly the rootdn is immune to ACLs and
the authentication identity has no impact DN is immune to disallow,
require, or security directives.

>So I'll try
>deleting the rootdn from slapd.conf to make the server use the directory
>one as you suggest. Or did I miss the point?

Basically, yes.  rootdn is a backdoor.  It exists to get around
a chicken-and-egg problem.  Once you've gone past this problem
(by hatching initial entries), the rootdn is no longer needed.

Kurt