[Date Prev][Date Next]
Re: rootpw in slapd.conf read from file (ITS#1113)
First, I don't understand the need for multiple applications
to have knowledge of the password which the directory manager
(a human) uses to administer the directory (namely for
bootstrapping the server)
For security, each application entity which needs access to the
directory should have a separate account so that controls can
be applied on a per application basis. Using the rootpw in
multiple applications means that successful attacker of any
of these applications gets complete access to the directory.
For security, the server should have a separate copy of the
share secret from the user which it maintains in a non-reusable
form. That is, if the server is hacked, one only gets a
non-reusable value, not a reusuable value. This protects other
applications/services which might be sharing the same value.
For security, rootpw should be disabled! It's actually not
needed anymore in 2.0 (as slapadd(8) can be used to bootstrap
the directory). On all directory servers I manage, it is set
to a bogus scheme.
From a design point of view, the password scheme stuff is getting
a bit out of control and I'm quite apprehensive of adding new
schemes. I'm currently looking at ways of support alternative
schemes without having to modify OpenLDAP. Support for Cyrus's
At 01:36 PM 5/2/01, firstname.lastname@example.org wrote:
>> This like likely can be resolved by using the include directive.
>Well, the include directive wolud require "rootpw <cred>" in the included
>file, while many codes (sendmail, samba-tng and so) simply ask
>for the <cred> part (and optionally strip a trailing newline).
Sendmail reads a password from a file? For what purpose? Which
I have no familiarity with samba-tng... but I would be surprised
if it was tied to OpenLDAP's implementation.
>For both security, atomicity of credentials and ease of configuration,
>I've been adding the same change to a number of ldap-enabled
>applications we're deploying, including apache's auth_ldap and more.
>I agree some kerberos or so would obsolete this change, but kerberos
>is too much for many customers (and a headache for me ...:)