Re: [ldapext] DBIS - new IETF drafts
Arthur de Jong <arthur@arthurdejong.org> Tue, 07 January 2014 22:25 UTC
Return-Path: <arthur@arthurdejong.org>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC1C1AE212 for <ldapext@ietfa.amsl.com>; Tue, 7 Jan 2014 14:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.195
X-Spam-Level:
X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79TpLitbh4Ff for <ldapext@ietfa.amsl.com>; Tue, 7 Jan 2014 14:25:34 -0800 (PST)
Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id D427F1AE20E for <ldapext@ietf.org>; Tue, 7 Jan 2014 14:25:33 -0800 (PST)
Received: from arthurenhella.demon.nl (arthurenhella.demon.nl [83.160.165.27]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id s07MPOiL001082; Tue, 7 Jan 2014 23:25:24 +0100 (CET) (envelope-from arthur@arthurdejong.org)
Received: from [192.168.12.4] (sorbet.thuis.net [192.168.12.4]) by arthurenhella.demon.nl (Postfix) with ESMTP id 41ABCCB0B; Tue, 7 Jan 2014 23:25:22 +0100 (CET)
Message-ID: <1389133522.4574.30.camel@sorbet.thuis.net>
From: Arthur de Jong <arthur@arthurdejong.org>
To: Mark R Bannister <dbis@proseconsulting.co.uk>, ldapext@ietf.org
Date: Tue, 07 Jan 2014 23:25:22 +0100
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-hyrQtB4Ql9acFPKQOEho"
X-Mailer: Evolution 3.8.5-2+b1
Mime-Version: 1.0
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Virus-Status: Clean
Subject: Re: [ldapext] DBIS - new IETF drafts
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2014 22:27:05 -0000
Hi, I'm the maintainer of nss-pam-ldapd, a PAM and NSS module that extracts information from LDAP to map to Unix users, groups, and other maps defined in RFC2307. I quickyly went through draft-bannister-dbis-mapping-02.txt and draft-bannister-dbis-passwd-01.txt and would like to add a few comments (not very well organised, sorry). For me, it is very interesting that the work is being done to to correct some of the mistakes in RFC2307. I particularly like the idea of making the attributes case sensitive and ensuring that values can appear only once. Leaving out the case sensitivity filters from implementations should make them a lot simpler. Mixing case sensitive and non-cases sensitive interpretations of the same values can have security implications. The use of the term overlay may be confusing to users because that is also used as one of the types of loadable modules of the OpenLDAP LDAP server (slapd). I don't have a better alternative, sorry (the mechanism is interesting though). I personally wouldn't worry too much about the format of password hashes. In an centralised network it would seem wiser to use a centralised mechanism to authenticate users which already have plenty of solutions available (LDAP bind authentication, Kerberos, etc.). Exposing password hashes throughout the network is somewhat analogous to putting password hashes in /etc/passwd instead of /etc/shadow. I agree with Howard Chu that there must be a better format to store timestamps and durations (mostly for shadow information) in. Something that is interoperable with other systems. I personally like the use of flat names to describe group membership. It makes the semantics much simpler than dealing with things like the member or uniqueMember attribute (at least from a client implementation perspective). The use of distinguished names may seem more logical from an LDAP structure point of view, but you will have to dereference any DN to a user name for building up a group entry resulting in potentially a lot of search operations to get complete data. I was recently pointer to draft-masarati-ldap-deref-00 which I've just implemented in nss-pam-ldapd. This would reduce the number of required lookups but this draft isn't widely implemented (I think nss-pam-ldapd is the second Open Source client application to use it). On the other hand, the use of exactPrimary will also require another lookup because POSIX getpwent() expects to return a numerical group id. I haven't ready it fully yet but the combination of exactGroup in posixUserAccount and exactUser in posixGroupAccount will leaver room for different interpretations for which users belong to which group, depending on which way you look. Adding nested groups to the mix will make it more difficult to maintain consistency. I would say that it is better to have one way of specifying group membership and not two. Nested groups are also an interesting concept and I can see the value from a data management perspective but it will again result in multiple LDAP search operations, especially for queries to determine the groups that contain a specific user (initgroups() implementations). If a user is found to be a member of 10 groups in the first pass, for each of the 10 groups it needs to be determined whether these groups are again member of some other groups. Some of these performance issues can be addresses with caches but since caches are one of the only two difficult things in computer science doing without them is better. Let's keep things simple. Also, you may be interested in looking at the nss-pam-ldapd code. It seems to have a somewhat similar design as the ideas described in the DBIS Reference Implementation. There is even a work-in-progress Python implementation that you could replace with a DBIS implementation. Anyway, that's it for now. Perhaps I'll take a further look in a few days. -- -- arthur - arthur@arthurdejong.org - http://arthurdejong.org/ --
- [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Arthur de Jong
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Ludovic Poitou
- Re: [ldapext] DBIS - new IETF drafts Clément OUDOT
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Charlie
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Neal-Joslin, Robert (3PAR Engineering)
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Charlie
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister