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


A loose thought - haven't really thought it through, and don't
know exactly how SSFs are used today either:

I'm wondering if we need one or two "Bind DN SSF"s which describe
how reliable a Bind DN is - how secure the server-side
authentication system is, as well as the Bind method and
connection security at the time of the Bind.  Then one can set
access controls, 'security' directive, and a new 'rootdn-ssf'
directive which requires a certain quality of the rootdn/pw.
Possibly rootdn-ssf should be nonzero by default, or nonzero by
default for cn=config.

The ultimate example of an insecure Bind DN is probably
    database config
    rootdn   cn=foo,cn=nil  # config's rootdn is very powerful
    database null
    suffix   cn=nil
    bind     on             # accept any password for any DN
which hopefully doesn't happen outside tests.  (That's why this
occurred to me, I'd like to support cd tests/ && ./run -b null.
Not when one could accidentally write a test like this, though.)

There are other reasons the quality of the authentication or
password store might differ - different authentication methods, a
sloppily-written back-perl instance, whatever.  So as a source of
the Bind DN SSF one would configure SSFs to subsystems used for
authentication - databases, SASL, etc.