Re: [ldapext] DBIS - new IETF drafts
Mark R Bannister <dbis@proseconsulting.co.uk> Wed, 08 January 2014 21:15 UTC
Return-Path: <dbis@proseconsulting.co.uk>
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 1BC7F1A1DFA for <ldapext@ietfa.amsl.com>; Wed, 8 Jan 2014 13:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 7JjnhjNHpogp for <ldapext@ietfa.amsl.com>; Wed, 8 Jan 2014 13:15:32 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 930C81A1521 for <ldapext@ietf.org>; Wed, 8 Jan 2014 13:15:31 -0800 (PST)
Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1W10TB-0000nt-Ez; Wed, 08 Jan 2014 21:15:22 +0000
Message-ID: <52CDBFD2.10905@proseconsulting.co.uk>
Date: Wed, 08 Jan 2014 21:14:58 +0000
From: Mark R Bannister <dbis@proseconsulting.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Arthur de Jong <arthur@arthurdejong.org>, ldapext@ietf.org
References: <1389133522.4574.30.camel@sorbet.thuis.net>
In-Reply-To: <1389133522.4574.30.camel@sorbet.thuis.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
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: Wed, 08 Jan 2014 21:15:34 -0000
On 07/01/2014 22:25, Arthur de Jong wrote: > 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. Hi Arthur, Yes as you'll see from my recent reply to Simo, the case sensitivity issue was one of the problems I faced at a large installation, and it had been solved in that case by inventing a custom schema. It seemed quite strange to me that RFC2307 should have differed like this from NIS in the first place. Case sensitivity was one of the first problems I wanted DBIS to rectify. > 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). Indeed, I'm sure various technologies use the term. > 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. Also as I mentioned in my previous reply, people are free to choose a more secure password scheme, and Kerberos seems to be the one I've come across more often than not in recent years. However, had I completely omitted the userPassword and authPassword attributes then I would not be providing an easy migration path for those people already making use of them. > 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. DBIS actually represents timestamps using the Generalized Time syntax, which I think is a better choice than an integer as in RFC2307bis. Durations remain as integers, currently number of days (to align with NIS on Solaris and Linux), but unless someone has a good reason not to I think these should become number of seconds as Howard suggested and can be translated accordingly by the Solaris and Linux DUAs. > 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). Yes this was another aspect I wanted to simplify. RFC2307bis does not make it easy to express group membership. > 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. Given the way that configuration maps work in DBIS, it was no longer possible for me to represent them as DNs anyway, as someone could specify a DN that may or may not fall under the control of one or other configuration maps, and the DUA would not know what transformation rules to apply, if any. You could even have specified a DN from another domain! It made no sense to use DNs when expressing group membership, simple group names are quite sufficient. > 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. Local caching should reduce the number of lookups. > 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. There won't be different interpretations, just two different ways to express group membership. This keeps options open for people who, for security reasons, may want group membership to be defined solely in the user account object (which is easier for a human to read), or solely with the group account object (for delegated administration). They can then apply ACIs to ensure that their preferred route was the only one available. We might add a flag somewhere to say which one it is, that would help performance by not performing redundant search operations if local security policy has mandated one approach and not the other. > 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. Nested groups are very important especially in large enterprises, and really do assist with data management. Yes we'll get more search operations, but I don't think this will be a problem. I should be able to prove this will work in my reference implementation. > 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. Caching is very important, and something that has great focus within the reference implementation I am currently developing. I hope to have something working in the next few months, after which you'll be able to download it and have a play. I'm writing a multi-threaded caching daemon called dbis_cachemgr in Python that takes queries over a socket and is responsible for managing and caching the results of the appropriate LDAP search operations, and then I'll develop a simple nss_dbis library in C that translates NSS calls to an appropriate command that is sent to dbis_cachemgr. > 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. > Thanks I had a look at your code already. I may be able to re-use some of it, possibly the NSS layer, however quite a lot of it becomes redundant or would have to be rewritten for DBIS. I think the architecture I have designed in dbis_cachemgr will scale better on busy enterprise servers and will handle LDAP server outages more gracefully, as I have worker threads that can operate on many connections simultaneously while sharing a pool of LDAP connections. Best regards, Mark.
- [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