Re: [nssldap] Starttls and SSL

[Guillaume Rousse <Guillaume.Rousse [at] inria.fr>]

Le 21/01/2011 23:22, ldap a écrit :
> I guess this behavior is expected since the server is listening on 389
> and it is up to the client to initialize the starttls session, but I was
> wondering if there was a way to force the server to only use starttls on
> 398 and not rely on the the client to set up starttls?   One option
> would be to only have the server start on 636 and not have it listen on
> 389, but we would like to keep the same functionality if possible.  Am I
> missing something obvious? The only option that I see as a possiblity is
> the TLSVerifyClient { never | allow | try | demand } in slapd.conf. 
> But, it's unclear to me if this will provide the desired effect.
You can not force clients to use encryption, but you can use ACLs to
ensure content is only accessible through encrypted connexion.

For instance, this prevent authentication to work unless for local
access, or through encrypted connnection with a minimum strength level:

access to dn.subtree="dc=futurs,dc=inria,dc=fr" attrs=userPassword
    by anonymous ssf=56 auth
    by anonymous peername.ip=127.0.0.1 auth
    by * none

Warning, this does not prevent clients to send a password unencrypted,
it just make it useless.

You may also hide all other attributes, but usually, only passwords are
considered sensitive enough for such kind of measure. A user home
directory or uid is usually a public information.
-- 
BOFH excuse #217:

The MGs ran out of gas.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature