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

Re: Password storage policy and DIT organisation



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.

--