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

Re: Password storage policy and DIT organisation



Andreas Ames wrote:
> What I want to achieve using slapd:
> 
> a) A centralised authentication service for system accounts of a handful of Linux
> hosts (libpam-ldapd) and some apache-based webapps (mod_authnz_ldap).
> b) Every user has a single password stored in exactly one place in the DIT
> (single-sign on is not topical in my environment).
> c) I would like to have fine-grained control over whether an ldap user has access to a
> specific host or webapp or not.

You have to decide whether the hosts and web apps filter which users get access or
whether you want to implement service-specific views.

> 1. DIT organisation
> 
> Let's assume my suffix is dc=foo.  I plan to have ou=Users,dc=foo for storing ldap
> users with their (unique) passwords and ou=Services,dc=foo to have account information
> for each of my services; e.g. ou=host1,ou=services,dc=foo to provide posix account
> information for host1, or ou=webapp1,ou=services,dc=foo for mod_authnz_ldap related
> information regarding webapp1 etc.  I plan to use olcAuthzRegexp to authenticate users
> below ou=host1,ou=services,dc=foo or ou=webapp1,ou=services,dc=foo against ldap users
> in ou=Users,dc=foo.  Is this a sensible setup or are there better hierarchies to
> achieve my goals?

If I understand you correctly: Even if olcAuthzRegexp would work that way you would have
to add user account entries multiple times for your kind of host-/service-based grouping.
Better approach is to work with reference attributes.

Also granting the right to access a host to the user directly gets cumbersome pretty
quickly. Better use some flexible indirection via group entries.

> 2. Password storage policy
> 
> (NB: I am using TLS with a self-signed certificate.)  Theoretically I would prefer to
> store hashed passwords.  If I understand correctly, olcAuthRegexp only works with SASL
> and hashed passwords can only possibly work with the PLAIN mechanism (??).

Forget about SASL and use strongly hashed password. Most clients do not have SASL support
at all. BTW: Using SASL/PLAIN directly also requires plain-text password unless you pass
the password checking to an external demon.

Ciao, Michael.

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