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.
smime.p7s
Description: S/MIME Cryptographic Signature
