Re: authentification

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

At 12:36 AM 9/6/00 +0200, Michael Weiser wrote:
>Hi again,
>
>another question regarding authentication: If I use ssfs to make my users
>athenticate via secure (e.g. ssl) connections, is there any chance that
>passwords get transmitted in clear across the wire?

Yes.  You cannot stop clients from sending data in the clear (password,
filter, DN).  You can however refuse to accept or act upon the data.

>Currently I got 
>something like that in my slapd.conf:
>
>defaultaccess: none
>
>access to cn="cn=.*,o=org,c=de" filter=(objectClass=person) attr=userPassword
>    by dn="cn=Manager,o=org,c=de" ssf=112 write
>    by self ssf=112 =w
>    by * ssf=112 =x

currently you need to grant auth access to "entry" as well.
This requirement will be dropped in 2.0.1.

>Now a user might decide to authenticate using normal ldap through port
>389. If I understood correctly, the password will be transmitted to the
>server in clear text who hashes it and the compares it with its stored one
>just to deny the user on base of the ssf.

Exactly.

>But what I want is that the user
>can only initiate a authentification across ssl-connections and normal
>ldap should never come so far transmitting a password. Can someone make me
>get it? ;)

You can configure the server to only listen for LDAP over SSL.
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).  

Note that if "cn=Manager,o=org,d=de" is your rootdn, then this
ACL (like all others) is ignored.  I generally recommend rootdn
only be set during initial loading of the directory... having
all users go through ACLs is a good idea.

Additional note: rootdn does not allow "disallows" nor
forgives "requires" nor dishonors "security" requirements.
These are applied across the board.

I recommend using "security" to set reasonable minimums,
something like:

security ssf=56 update_ssf=112

access to attr=userPassword
        by self ssf=112 =w
        by anon tls_ssf=112 =x

access to *
        by self write
        by users read