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: > > 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. --
