Hi all,
my questions below are more about openldap pragmatics than technical issues; if they are off-topic, please point me somewhere else to ask. As I'm a newbie, please bear with me, if I get things completely wrong.
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.
Based on that I have got two questions:
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?
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 (??). So I tried that and simple binding works as expected, when directly binding to an entry with an attribute "userPassword" (i.e. without indirection through olcAuthzRegexp). To get SASL/PLAIN working, I have tried (without success up till now) to use saslauthd. Moreover the authentication path "client -> TLS/TCP/IP -> slapd (SASL/PLAIN) -> Unix Domain socket -> saslauthd -> localhost/TCP/IP -> slapd (simple bind)" seems a little over the top for my use case. So I am wondering, if hashed password storage is really such a good idea. What are the (security) implications of cleartext storage of passwords? Do you have document links discussing this in some depth?
Thanks in advance ...
Mit freundlichen Grüßen / With kind regards / Cordiali saluti,
Andreas
Please consider the environment before you print / Merci de penser à l'environnement avant d'imprimer / Bitte denken Sie an die Umwelt bevor Sie drucken
Bombardier Transportation GmbH. Vorsitzender des Aufsichtsrats / Chairman of Supervisory Board: Wolfgang Toelsner. Geschäftsführung / Management Board: Michael Fohrer (Vorsitzender/Chairman), Olaf Berghoff, Dr. Daniel Perlzweig, Konrad Wiebalck. Sitz der Gesellschaft / Principal Office: Berlin. Registergericht / Registration Court: Amtsgericht Charlottenburg, HRB 64838.
This e-mail message, and any attachments, may contain information that is confidential and/or privileged. They are intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosure, distribution or reproduction. No waiver whatsoever is intended by sending this e-mail. If you receive this e-mail in error please immediately inform the sender by return e-mail and delete this e-mail message along with all the attachments and destroy all copies.
Andreas,
c) I would like to have fine-grained control over whether an ldap user has access to a specific host or webapp or not.
To acheive this, I have an attribute attached to each user that describes what services a user can access or not. I have created the attribut AccountPermission that can hold multiple strings.
It works well for any service authenticating to LDAP that can support a filter (I use filters of the form (AccountPermission=Ubuntu) or (Accountpermission=web)...)
I only had one problem so far, it was with IBM Rational Team Concert (I think), because I had no way to declare a filter.
Best regards,
Olivier
Based on that I have got two questions:
- 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?
- 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 (??). So I tried that and simple binding works as expected, when directly binding to an entry with an attribute "userPassword" (i.e. without indirection through olcAuthzRegexp). To get SASL/PLAIN working, I have tried (without success up till now) to use saslauthd. Moreover the authentication path "client -> TLS/TCP/IP -> slapd (SASL/PLAIN) -> Unix Domain socket -> saslauthd -> localhost/TCP/IP -> slapd (simple bind)" seems a little over the top for my use case. So I am wondering, if hashed password storage is really such a good idea. What are the (security) implications of cleartext storage of passwords? Do you have document links discussing this in some depth?
Thanks in advance ...
Mit freundlichen Grüßen / With kind regards / Cordiali saluti,
Andreas
Please consider the environment before you print / Merci de penser à l'environnement avant d'imprimer / Bitte denken Sie an die Umwelt bevor Sie drucken
Bombardier Transportation GmbH. Vorsitzender des Aufsichtsrats / Chairman of Supervisory Board: Wolfgang Toelsner. Geschäftsführung / Management Board: Michael Fohrer (Vorsitzender/Chairman), Olaf Berghoff, Dr. Daniel Perlzweig, Konrad Wiebalck. Sitz der Gesellschaft / Principal Office: Berlin. Registergericht / Registration Court: Amtsgericht Charlottenburg, HRB 64838.
This e-mail message, and any attachments, may contain information that is confidential and/or privileged. They are intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosure, distribution or reproduction. No waiver whatsoever is intended by sending this e-mail. If you receive this e-mail in error please immediately inform the sender by return e-mail and delete this e-mail message along with all the attachments and destroy all copies.
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.
- 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.
- 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.
openldap-technical@openldap.org
-
Andreas Ames -
Michael Ströder -
Olivier