[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Password storage policy and DIT organisation
- To: Andreas Ames <andreas.ames@rail.bombardier.com>
- Subject: Re: Password storage policy and DIT organisation
- From: Olivier <Olivier.Nicole@cs.ait.ac.th>
- Date: Wed, 26 Apr 2017 11:16:02 +0700
- Cc: openldap-technical@openldap.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.ait.ac.th; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:in-reply-to:subject:subject:from:from :received:received:received; s=selector1; t=1493180163; x= 1494994564; bh=v8n2wri7xrGGS2LWKV9O5AKOdfw1ZlC6fuSrHZInB50=; b=I Ypgo8hDYnWontapFc8D7h5pnfAjCCaRkJmMFHuWXb+32UXqaWpLbK1gNB1miOZgO /ZIbOu2cV0dVJ6ERhq+nR5HfSNPWhZeeW4NmxP5uz88Qvm3MujWwzNrsKieyJZ9F UwIEZoSlsmtZHz7+KEUhlqZQDDjRy3edRLOd1A/HrE=
- In-reply-to: <AM4PR0301MB2210BBACE8D6A8D1AB9D8400DC1E0@AM4PR0301MB2210.eurprd03.prod.outlook.com> (message from Andreas Ames on Tue, 25 Apr 2017 09:57:19 +0000)
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.
--