Re: [ldapext] DBIS - new IETF drafts
Michael Ströder <michael@stroeder.com> Fri, 10 January 2014 15:19 UTC
Return-Path: <michael@stroeder.com>
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 960851AE0AA for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 07:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.839
X-Spam-Level:
X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 kthiknDzutet for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 07:19:25 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 811D11AE06F for <ldapext@ietf.org>; Fri, 10 Jan 2014 07:19:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id B9DFD6075E; Fri, 10 Jan 2014 16:19:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AyDv6Et3Zho; Fri, 10 Jan 2014 16:19:07 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Str??der", Issuer "CA Cert Signing Authority" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id F11F4607FF; Fri, 10 Jan 2014 15:19:05 +0000 (UTC)
Message-ID: <52D00D56.9090304@stroeder.com>
Date: Fri, 10 Jan 2014 16:10:14 +0100
From: Michael Ströder <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
MIME-Version: 1.0
To: Mark R Bannister <dbis@proseconsulting.co.uk>, ldapext@ietf.org
References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <52CB194D.3090009@proseconsulting.co.uk> <52CB1DE3.6040000@highlandsun.com> <52CB2194.30907@proseconsulting.co.uk> <52CB26C6.1070406@highlandsun.com> <52CDB3FC.2000205@proseconsulting.co.uk> <52CEB72F.9050000@stroeder.com> <52CFF9B0.6020408@proseconsulting.co.uk>
In-Reply-To: <52CFF9B0.6020408@proseconsulting.co.uk>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms020109040206000906070903"
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: Fri, 10 Jan 2014 15:19:28 -0000
Mark R Bannister wrote: > On 09/01/2014 14:50, Michael Ströder wrote: >> Mark R Bannister wrote: >>> I don't personally like the idea >>> of having per-user shadow attributes, however some might see it as a feature >>> and there may be some edge cases where this is exactly what is required. >> AFAICS today nobody is seriously using LDAP with shadow attributes anymore. > > Please provide me some empirical evidence that this assertion is true. Not numbers but my impression from lurking on various directory-related mailing lists. >>> draft-behera-ldap-password-policy-10 is already widely deployed, you say? >>> Then it must go higher up in my reading list. >> Yes, it's the only standard considered widely deployed. You have to know it. > > Thanks. Do we have any idea how widely adopted it is? Currently everybody who wants to use LDAP password policy has to use it. It's the only standard I know of for which is at least some client support implemented. >>> Indeed, I agree, as stated earlier on I would whole-heartedly recommend >>> against having user-specific policy settings. However, providing the facility >>> as an option for those who want to make minimal changes to their NIS >>> environment is harmless. >> If I replace NIS with LDAP I already have two options: >> 1. Simply use RFC 2307(bis) for a naive transition >> 2. Do a migration to really meaningful LDAP schema >> >> IMHO with 2. I can drop all NIS specific things anyway. You have to decide >> whether DBIS is just an improvement for 1. or a real innvotation for 2. > > It's 2. Show me something I've done that's not "really meaningful" and we'll > look at improving it. Well, if you claim that you will implement a NIS/DBIS gateway you don't have to define user-specific policy settings. You can map anything you want in your gateway provided there's a reference from the user entry to the policy entry. I'd go for a DN reference so you can make use of deref control. Ciao, Michael.
- [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