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.
--
Regards,
Hallvard
