From nobody Sun Feb 1 14:33:21 2015 Return-Path: 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 AF5E31A1B71 for ; Sun, 1 Feb 2015 14:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 LQCF0QP9p44o for ; Sun, 1 Feb 2015 14:33:15 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id C22F31A1B6C for ; Sun, 1 Feb 2015 14:33:14 -0800 (PST) Received: from host86-178-119-20.range86-178.btcentralplus.com ([86.178.119.20] helo=[192.168.1.67]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1YI34q-0000yK-No; Sun, 01 Feb 2015 22:33:13 +0000 Message-ID: <54CEA9A4.1020709@proseconsulting.co.uk> Date: Sun, 01 Feb 2015 22:33:08 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Simo References: <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <1422454472.32747.38.camel@ssimo.org> In-Reply-To: <1422454472.32747.38.camel@ssimo.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: Cc: ldapext@ietf.org, =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= Subject: Re: [ldapext] LDAP work at IETF... X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 22:33:17 -0000 On 28/01/2015 14:14, Simo wrote: > On Tue, 2015-01-27 at 20:50 +0000, Mark R Bannister wrote: >> On 27/01/2015 15:47, Michael Ströder wrote: >>> Mark R Bannister wrote: >>>> The following internet drafts are intended to replace RFC2307 and RFC2307bis. >>>> [..] >>>> draft-bannister-dbis-mapping >>>> draft-bannister-dbis-netgroup >>>> draft-bannister-dbis-passwd >>>> draft-bannister-dbis-hosts >>>> draft-bannister-dbis-devices >>>> draft-bannister-dbis-automounter >>>> draft-bannister-dbis-custom >>>> [..] >>>> I would prefer to see RFC2307bis removed from the list to be considered above, >>>> and replaced by the DBIS drafts. >>> This probably won't happen because there are so many RFC2307(bis) deployments >>> out there which cannot easily be migrated. >> DBIS supports maps defined in legacy RFC2307 or RFC2307bis format, as >> well as using the new format. Migration is designed to be extremely >> easy. In fact, it took me next to no time at all to start using >> directory entries defined in RFC2307 format from a DBIS installation, it >> really is just a matter of defining a few configuration maps that do the >> class and attribute remappings, and they are mostly standard. See >> https://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/ >> >>> Also I have my own schema built on top of RFC2307bis (not published yet) which >>> differs much from DBIS for very good reasons. I aim to present it at LDAPcon >>> 2015 in Edinburgh (in case the program comittee agrees). A preview version of >>> that is already in production for almost a year in a large data center. >>> >>> So my suggestion would be to brush up RFC2307bis as much as possible (taking >>> care of Kurt's IANA comments) so that you can base DBIS on that, as I will >>> base my system on top of that. >>> >>> How does that sound to you? >>> >>> Ciao, Michael. >>> >> DBIS is not a superset nor a child schema that inherits from RFC2307bis, >> nor is it built on top of RFC2307bis - it is a complete replacement and >> was designed as such. RFC2307 and RFC2307bis can be completely retired >> and DBIS put in their place and there would be no omissions. It's an >> evolution that began life by taking RFC2307bis and splitting it into >> logic units (separate internet drafts) that make for a less unwieldy >> document and make it easier for others to extend. Then I standardised >> the client-side configuration, fixed some of the NIS incompatibilities >> that had been inherited from RFC2307, added a few much needed enterprise >> features, and that's it: a modern, modular, extensible, enterprise-ready >> RFC2307bis under another name ("2307bis" wasn't a very friendly name, >> after all, and I wasn't going to call my improvements "2307ter", but >> they could have been called that, because realistically that's what they >> are). >> >>> So my suggestion would be to brush up RFC2307bis as much as possible (taking >>> care of Kurt's IANA comments) so that you can base DBIS on that, as I will >>> base my system on top of that. >>> >>> How does that sound to you? >>> >>> Ciao, Michael. >>> >> I don't see a reason to try to improve RFC2307bis, I think that would be >> a backwards step. The improvements needed to RFC2307bis have already >> been made, I've done the work myself and named it "DBIS" because I >> couldn't wait for everyone else to catch-up, and I needed it last year >> :-) I think if people started looking deeper into the DBIS internet >> drafts, making suggestions for improvement etc. we'd get to a much >> better end point than if you have people pore over RFC2307bis again. > It hurts me to curb enthusiasm, but I think your drafts are not a step > forward, at most a step sideways, and ignore what's out there right now. Given that they were written to fix specific deficiencies in RFC2307bis that were causing pain in a number of very large enterprises I have worked for, I don't see how they could be considered a step sideways. When you say my drafts ignore what's out there right now, what are they ignoring? I don't quite understand that point. I'm very open to make changes that would make the drafts more useful in other organisations too, but I cannot make improvements when faced with generic statements that have no detail behind them. > The software out there and now expect either RFC2307 or at most > RFC2307bis (and then really they just test against Active Directory's > schema and things happen to mostly work). Any other schema would just > fail to be useful for a generic LDAP server. > > Simo. > To what software do you refer specifically? NSS is a big subscriber, and I've addressed that one. Then there is the automounter, and sudo, and really only a handful of others all of which can be fixed to use a more modern schema. I'm not going to spend 18 months developing DBIS to be turned away because software doesn't support it. Of course software doesn't support it - yet - it's new! Best regards, Mark. From nobody Sun Feb 1 14:50:41 2015 Return-Path: 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 5EF681A1B82 for ; Sun, 1 Feb 2015 14:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] 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 IHpJk5V79CL6 for ; Sun, 1 Feb 2015 14:50:38 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEFC1A1B77 for ; Sun, 1 Feb 2015 14:50:38 -0800 (PST) Received: from host86-178-119-20.range86-178.btcentralplus.com ([86.178.119.20] helo=[192.168.1.67]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1YI3Lh-00034f-4N; Sun, 01 Feb 2015 22:50:37 +0000 Message-ID: <54CEADBC.5070902@proseconsulting.co.uk> Date: Sun, 01 Feb 2015 22:50:36 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= , ldapext@ietf.org References: <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <54C80DB9.10901@stroeder.com> <54C81EBD.3020804@proseconsulting.co.uk> <54C921AB.1090309@stroeder.com> In-Reply-To: <54C921AB.1090309@stroeder.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: Subject: Re: [ldapext] LDAP work at IETF... X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 22:50:39 -0000 On 28/01/2015 17:51, Michael Ströder wrote: > Mark R Bannister wrote: >> On 27/01/2015 22:14, Michael Ströder wrote: >>>> I think if people >>>> started looking deeper into the DBIS internet drafts, >>> I've looked into your drafts. But it differs very much from what I'm after. We >>> had this discussion before: IMO netgroups must die, die, die... >> This contradicts your earlier assertion that clients are hard-coded. In the >> same vein, clients are hard-coded to use netgroups, ergo netgroups cannot >> "die, die, die". > No contradiction, since IMO one can easily avoid using netgroups completely. And use what instead? When one needs to group together users and hosts in logical units, what other pervasive choices are there? > With my approach the ACLs on the LDAP server sort out what clients can > actually see. Therefore you get the flexible access control without the client > having to enforce e.g. login access control locally based on netgroups. Ah, I see, so you're talking specifically of access control. Yes, if all netgroups are there to do is access control, then you can offload that as ACLs on the LDAP server. But what about the netgroups that are there to define application roles? > >> Rather than attempting to kill off something that is used extensively, and has >> actually proved to be very useful in large UNIX/Linux estates (if a bit >> clunky), I've embraced them, rationalised them, defined them in a neater and >> queryable format, and complemented them with netservices. > I'd avoid them and convert access control rules based on netgroups into > another schema and let the LDAP server's ACL work through the data. Agreed, great for access control. But I don't see how that will work for the other netgroup use-cases. >> Apart from netgroups, which you are not a fan of, how else does DBIS differ >> from what you're after? > My main objective is that not the client system evaluates all the stuff. The > client system should not see data not usable on the system. The client system > acts as a dumb RFC2307(bis) and sudo-ldap client. Of course the client system > still enforces file access permissions etc. locally. > I agree with you on that point. Perhaps I could take a similar approach with DBIS. I'm interested, today the NSS library on Linux hosts does not have the identity of the requester. It is quite normal for there to be a service account used in the LDAP bind, or perhaps even an anonymous bind. The LDAP server can then only usefully filter with ACLs data that is restricted to specific hosts, but not to specific users. So you are only solving half the problem, right? Best regards, Mark. From nobody Mon Feb 2 10:21:21 2015 Return-Path: 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 915711A885F for ; Mon, 2 Feb 2015 10:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Q8-UVOSLjsZY for ; Mon, 2 Feb 2015 10:21:19 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2142F1A8859 for ; Mon, 2 Feb 2015 10:21:18 -0800 (PST) Received: from srv4.stroeder.local (srv4.stroeder.local [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id 584081D343; Mon, 2 Feb 2015 19:21:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srv4.stroeder.local (Postfix) with ESMTP id 70A6F1DFF9; Mon, 2 Feb 2015 19:21:15 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.local Received: from srv4.stroeder.local ([127.0.0.1]) by localhost (srv4.stroeder.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7ylCRg5qUQC; Mon, 2 Feb 2015 19:21:09 +0100 (CET) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 27C441CFBB; Mon, 2 Feb 2015 19:21:07 +0100 (CET) Message-ID: <54CF4F66.5000001@stroeder.com> Date: Mon, 02 Feb 2015 11:20:22 +0100 From: "michael-catchall@mail.stroeder.local (POP3)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32 MIME-Version: 1.0 To: Mark R Bannister , ldapext@ietf.org References: <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <54C80DB9.10901@stroeder.com> <54C81EBD.3020804@proseconsulting.co.uk> <54C921AB.1090309@stroeder.com> <54CEADBC.5070902@proseconsulting.co.uk> In-Reply-To: <54CEADBC.5070902@proseconsulting.co.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [ldapext] RFC2307, netgroups, DBIS (was: LDAP work at IETF...) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:21:20 -0000 (Changed the subject.) Mark R Bannister wrote: > On 28/01/2015 17:51, Michael Ströder wrote: >>> Rather than attempting to kill off something that is used extensively, and has >>> actually proved to be very useful in large UNIX/Linux estates (if a bit >>> clunky), I've embraced them, rationalised them, defined them in a neater and >>> queryable format, and complemented them with netservices. >> I'd avoid them and convert access control rules based on netgroups into >> another schema and let the LDAP server's ACL work through the data. > > Agreed, great for access control. But I don't see how that will work for the > other netgroup use-cases. Which particular netgroup use-cases do you see? One example is sufficient. >> My main objective is that not the client system evaluates all the stuff. The >> client system should not see data not usable on the system. The client system >> acts as a dumb RFC2307(bis) and sudo-ldap client. Of course the client system >> still enforces file access permissions etc. locally. > > I agree with you on that point. Perhaps I could take a similar approach > with DBIS. I'm interested, today the NSS library on Linux hosts does not > have the identity of the requester. It is quite normal for there to be a > service account used in the LDAP bind, or perhaps even an anonymous bind. IMO it's ok to use an individual machine identity to request NSS data from the LDAP server. But if the machine gets rooted the attacker should not see the rest of the NSS data for other server/service groups. So my threat model is that the machine is already out of control. > The LDAP server can then only usefully filter with ACLs data that is > restricted to specific hosts, but not to specific users. So you are only > solving half the problem, right? Filtering more based on identity of end user on a machine would IMO violate POSIX semantics. What do others think? Ciao, Michael. From nobody Mon Feb 2 10:21:23 2015 Return-Path: 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 5D9461A8866 for ; Mon, 2 Feb 2015 10:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Jqqsg18402jk for ; Mon, 2 Feb 2015 10:21:21 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657841A8859 for ; Mon, 2 Feb 2015 10:21:21 -0800 (PST) Received: from srv4.stroeder.local (srv4.stroeder.local [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id C39A31D343; Mon, 2 Feb 2015 19:21:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srv4.stroeder.local (Postfix) with ESMTP id 71BE11CFBB; Mon, 2 Feb 2015 19:21:19 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.local Received: from srv4.stroeder.local ([127.0.0.1]) by localhost (srv4.stroeder.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIwHjx16nBXD; Mon, 2 Feb 2015 19:21:16 +0100 (CET) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 0AD611DFED; Mon, 2 Feb 2015 19:21:09 +0100 (CET) Message-ID: <54CF5178.7040406@stroeder.com> Date: Mon, 02 Feb 2015 11:29:12 +0100 From: "michael-catchall@mail.stroeder.local (POP3)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32 MIME-Version: 1.0 To: Mark R Bannister References: <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <1422454472.32747.38.camel@ssimo.org> <54CEA9A4.1020709@proseconsulting.co.uk> In-Reply-To: <54CEA9A4.1020709@proseconsulting.co.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: ldapext@ietf.org Subject: [ldapext] RFC2307, netgroups, DBIS (was: LDAP work at IETF...) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:21:22 -0000 Mark R Bannister wrote: > On 28/01/2015 14:14, Simo wrote: >> It hurts me to curb enthusiasm, but I think your drafts are not a step >> forward, at most a step sideways, and ignore what's out there right now. > > Given that they were written to fix specific deficiencies in RFC2307bis > that were causing pain in a number of very large enterprises I have worked > for, I don't see how they could be considered a step sideways. Maybe I did not look closely enough. Could you please point me to some text describing the specific deficiencies you solved in more detail? > When you say my drafts ignore what's out there right now, what are they > ignoring? > [..] >> The software out there and now expect either RFC2307 or at most >> RFC2307bis (and then really they just test against Active Directory's >> schema and things happen to mostly work). Any other schema would just >> fail to be useful for a generic LDAP server. > > To what software do you refer specifically? I think like me Simo also meant the client side. > NSS is a big subscriber, and I've addressed that one. Then there is the > automounter, and sudo, and really only a handful of others all of which can > be fixed to use a more modern schema. > > I'm not going to spend 18 months developing DBIS to be turned away because > software > doesn't support it. Of course software doesn't support it - yet - it's new! But the question is whether there's a solution which is compatible to existing client-side software. I know you're working on PAM/NSS clients but the question is whether you can install that on legacy Unices or strange applicances. My approach is to lower the configuration level the client has to support by filtering what's delivered to the client at the LDAP server. Ciao, Michael. From nobody Wed Feb 4 13:41:14 2015 Return-Path: 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 ED8D01A8925 for ; Wed, 4 Feb 2015 13:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 Fmo7VevEgEHj for ; Wed, 4 Feb 2015 13:41:09 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5FABA1A891E for ; Wed, 4 Feb 2015 13:41:09 -0800 (PST) Received: from host86-178-119-74.range86-178.btcentralplus.com ([86.178.119.74] helo=[192.168.1.67]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1YJ7h5-0000gm-D4; Wed, 04 Feb 2015 21:41:07 +0000 Message-ID: <54D291ED.1080803@proseconsulting.co.uk> Date: Wed, 04 Feb 2015 21:41:01 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "michael-catchall@mail.stroeder.local (POP3)" , ldapext@ietf.org References: <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <54C80DB9.10901@stroeder.com> <54C81EBD.3020804@proseconsulting.co.uk> <54C921AB.1090309@stroeder.com> <54CEADBC.5070902@proseconsulting.co.uk> <54CF4F66.5000001@stroeder.com> In-Reply-To: <54CF4F66.5000001@stroeder.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: Subject: Re: [ldapext] RFC2307, netgroups, DBIS X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 21:41:12 -0000 On 02/02/2015 10:20, michael-catchall@mail.stroeder.local (POP3) wrote: > (Changed the subject.) > > Mark R Bannister wrote: >> On 28/01/2015 17:51, Michael Ströder wrote: >>>> Rather than attempting to kill off something that is used extensively, and has >>>> actually proved to be very useful in large UNIX/Linux estates (if a bit >>>> clunky), I've embraced them, rationalised them, defined them in a neater and >>>> queryable format, and complemented them with netservices. >>> I'd avoid them and convert access control rules based on netgroups into >>> another schema and let the LDAP server's ACL work through the data. >> Agreed, great for access control. But I don't see how that will work for the >> other netgroup use-cases. > Which particular netgroup use-cases do you see? > One example is sufficient. Generically, application roles. A specific example: sudo, where sudo rules are enabled for users based on netgroup membership. The LDAP server does not know the user requesting sudo access, only the client system knows that, so server-side ACLs are not going to help. I do need to give a second example, because the first is specific to users. Here is one specific to hosts: NFS, where an NFS server might grant read-only access to every host on the network except for those that are members of a specific netgroup, which get read-write access. The NFS server needs to know when a client request comes in whether this host is a member of the netgroup that grants read-write access or not, and this cannot be implemented by server-side ACLs, because only the NFS server knows the identity of the client requesting access to the fileshare. > >>> My main objective is that not the client system evaluates all the stuff. The >>> client system should not see data not usable on the system. The client system >>> acts as a dumb RFC2307(bis) and sudo-ldap client. Of course the client system >>> still enforces file access permissions etc. locally. >> I agree with you on that point. Perhaps I could take a similar approach >> with DBIS. I'm interested, today the NSS library on Linux hosts does not >> have the identity of the requester. It is quite normal for there to be a >> service account used in the LDAP bind, or perhaps even an anonymous bind. > IMO it's ok to use an individual machine identity to request NSS data from the > LDAP server. But if the machine gets rooted the attacker should not see the > rest of the NSS data for other server/service groups. So my threat model is > that the machine is already out of control. In the deployments I see, typically every user can login to every host, and any application could run anywhere, therefore any compromised machine will of course yield all NSS data. However, the NSS data isn't particularly sensitive anyway, and quite often the LDAP directories are open for anyone with a network device to query over port 389 anyway, so I haven't worked in an organisation yet where applying server-side ACLs to NSS maps would actually be of any practical use. What was the use-case you saw for it? > >> The LDAP server can then only usefully filter with ACLs data that is >> restricted to specific hosts, but not to specific users. So you are only >> solving half the problem, right? > Filtering more based on identity of end user on a machine would IMO violate > POSIX semantics. > What do others think? > > Ciao, Michael. > > I wasn't suggesting that different users get different filtered views of the NSS maps. They're open for all to see. They should, however, continue to be used to determine application rights and roles on a client, as they do today, which server-side ACLs cannot replace. Best regards, Mark. From nobody Wed Feb 4 13:55:54 2015 Return-Path: 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 EE3191A89AC for ; Wed, 4 Feb 2015 13:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 0ShSl7z53-Rf for ; Wed, 4 Feb 2015 13:55:50 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 398C81A8997 for ; Wed, 4 Feb 2015 13:55:47 -0800 (PST) Received: from host86-178-119-74.range86-178.btcentralplus.com ([86.178.119.74] helo=[192.168.1.67]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1YJ7vG-0006uJ-Dp; Wed, 04 Feb 2015 21:55:46 +0000 Message-ID: <54D2955E.3010608@proseconsulting.co.uk> Date: Wed, 04 Feb 2015 21:55:42 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "michael-catchall@mail.stroeder.local (POP3)" References: <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <1422454472.32747.38.camel@ssimo.org> <54CEA9A4.1020709@proseconsulting.co.uk> <54CF5178.7040406@stroeder.com> In-Reply-To: <54CF5178.7040406@stroeder.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Archived-At: Cc: ldapext@ietf.org Subject: Re: [ldapext] RFC2307, netgroups, DBIS X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 21:55:52 -0000 On 02/02/2015 10:29, michael-catchall@mail.stroeder.local (POP3) wrote: > Mark R Bannister wrote: >> On 28/01/2015 14:14, Simo wrote: >>> It hurts me to curb enthusiasm, but I think your drafts are not a step >>> forward, at most a step sideways, and ignore what's out there right now. >> Given that they were written to fix specific deficiencies in RFC2307bis >> that were causing pain in a number of very large enterprises I have worked >> for, I don't see how they could be considered a step sideways. > Maybe I did not look closely enough. Could you please point me to some text > describing the specific deficiencies you solved in more detail? Have at look at the abstract on page 2 of http://www.ietf.org/id/draft-bannister-dbis-mapping-06.txt. One of the first biggest requirements was reintroducing case sensitivity in a way that would be fully compatible with NIS, see the description of the en (4.2) and rn (4.3) attributes in particular. Also, another requirement was to fix the schema so that duplicate alias names could be easily detected and prevented (1.2). > >> When you say my drafts ignore what's out there right now, what are they >> ignoring? >> [..] >>> The software out there and now expect either RFC2307 or at most >>> RFC2307bis (and then really they just test against Active Directory's >>> schema and things happen to mostly work). Any other schema would just >>> fail to be useful for a generic LDAP server. >> To what software do you refer specifically? > I think like me Simo also meant the client side. Ok, well I'm working on fixing that already. > >> NSS is a big subscriber, and I've addressed that one. Then there is the >> automounter, and sudo, and really only a handful of others all of which can >> be fixed to use a more modern schema. >> >> I'm not going to spend 18 months developing DBIS to be turned away because >> software >> doesn't support it. Of course software doesn't support it - yet - it's new! > But the question is whether there's a solution which is compatible to existing > client-side software. I know you're working on PAM/NSS clients but the > question is whether you can install that on legacy Unices or strange applicances. Legacy unices ... depends how old we're talking. I currently have something that works on RHEL4.8 and newer, and the large organisations I have spent most of my time with over the past 5 years are at a point where RHEL4.8 is their oldest legacy now. Strange appliances - not unless I can get the vendor to add support for DBIS. However, even the appliances I've worked with support local class & attribute remapping rules, so could be tuned to fit DBIS, or vice versa with the DBIS configuration maps (http://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/). > > My approach is to lower the configuration level the client has to support by > filtering what's delivered to the client at the LDAP server. > > Ciao, Michael. > > By filtering, you mean just removing entries from maps? But you still have an old schema to support that wasn't fully NIS compatible to begin with ... Mark. From nobody Wed Feb 4 15:07:11 2015 Return-Path: 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 9193F1A0016 for ; Wed, 4 Feb 2015 15:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 k4rKF1pmTdYO for ; Wed, 4 Feb 2015 15:07:07 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E2E1A000D for ; Wed, 4 Feb 2015 15:07:06 -0800 (PST) Received: from srv4.stroeder.local (srv4.stroeder.local [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id C76901CF77; Thu, 5 Feb 2015 00:07:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srv4.stroeder.local (Postfix) with ESMTP id 74EBA1CE60; Thu, 5 Feb 2015 00:07:00 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.local Received: from srv4.stroeder.local ([127.0.0.1]) by localhost (srv4.stroeder.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42iHqsJuhA6A; Thu, 5 Feb 2015 00:06:50 +0100 (CET) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id B212B1CE5F; Thu, 5 Feb 2015 00:06:49 +0100 (CET) Message-ID: <54D2A608.6050907@stroeder.com> Date: Thu, 05 Feb 2015 00:06:48 +0100 From: =?UTF-8?Q?Michael_Str=c3=b6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32 MIME-Version: 1.0 To: Mark R Bannister , ldapext@ietf.org References: <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <54C80DB9.10901@stroeder.com> <54C81EBD.3020804@proseconsulting.co.uk> <54C921AB.1090309@stroeder.com> <54CEADBC.5070902@proseconsulting.co.uk> <54CF4F66.5000001@stroeder.com> <54D291ED.1080803@proseconsulting.co.uk> In-Reply-To: <54D291ED.1080803@proseconsulting.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090503060706030402070500" Archived-At: Subject: Re: [ldapext] RFC2307, netgroups, DBIS X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:07:09 -0000 This is a cryptographically signed message in MIME format. --------------ms090503060706030402070500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > michael@stroeder.com wrote: >> Mark R Bannister wrote: >>> Agreed, great for access control. But I don't see how that will work= for the >>> other netgroup use-cases. >> Which particular netgroup use-cases do you see? >> One example is sufficient. >=20 > Generically, application roles. A specific example: sudo, where sudo r= ules > are enabled for users based on netgroup membership. The LDAP server do= es not > know the user requesting sudo access, only the client system knows that= , so > server-side ACLs are not going to help. The server only sees 'sudoRole' entries assigned as visible for its parti= cular server/host/service group(s). Which particular command a user can execute= is indeed subject to fine-grained control by sudo on the client (based on attribute 'sudoUser' which with my approach is restricted to only referen= cing user groups). Similar file system permissions/ACLs are evaluated locally, but based on = the limited subset of visible user groups. > I do need to give a second example, because the first is specific to us= ers.=20 > Here is one specific to hosts: NFS, where an NFS server might grant rea= d-only > access to every host on the network except for those that are members o= f a > specific netgroup, which get read-write access. The NFS server needs t= o know > when a client request comes in whether this host is a member of the net= group > that grants read-write access or not, and this cannot be implemented by= > server-side ACLs, because only the NFS server knows the identity of the= client > requesting access to the fileshare. In my model such a NFS client host would be also simply an authenticated (system) user and member of user groups. The NFS server only sees user gr= oups assigned as visible for its particular server/host/service group. And furthermore it only sees the members of those user groups (NFS clients in= this example). Yes, of course: No IP-based authentication! > In the deployments I see, typically every user can login to every host,= and > any application could run anywhere, therefore any compromised machine w= ill of > course yield all NSS data. Yes. But not with my approach. > However, the NSS data isn't particularly sensitive anyway, I disagree. > and quite often the LDAP directories are open for anyone with a network= =20 > device to query over port 389 anyway, Yes in general, but not with my approach. ;-} > so I haven't worked in an organisation yet where applying server-side A= CLs > to NSS maps would actually be of any practical use. Well, this system is in production use. :-) > What was the use-case you saw for it? Role separation with separate credentials (especially passwords for sudo access), and paranoid protection of information I consider sensitive beca= use it could be used to plan next steps (e.g. social engineering). And furthermore you can keep the client configuration and map evaluation = very simple because the visibility of users and user groups is constrained by access control based on server/host/service group membership of the NSS c= lient. Ciao, Michael. --------------ms090503060706030402070500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNTAyMDQyMzA2NDhaMCMGCSqGSIb3DQEJBDEWBBRdevZi41l7 sFgiXMIx1m6lyPKYUDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAc58LMuxT 6T7VDO0Dr9jP14vs9bbHbCNlBLqyVnoMIN/ca9y5Wseys74+4DJ3VS65QJo4gCX35V7m0+hW IfJSAnhecVAxpQS46xakSZo29IjxLUNWYCUD/ksgOx6+7QluhGlvfu9YMdE1c7nCTlqe+eUv ZGGudh+tXxVZ3TeFTVjBDoCm5dJbZtEtaLrfi4A9TNRPJkPBmbuLieWrRG7WVPLZDJm/erBJ zivUP9DHSPSwXaPZgmAXQh5sc4K5JPPj1D/cq1+L1Yu59s6Zo7N+feR3bSCRL3lJ9BVcneIh /6hdsy0SHld644eQ3kEAgn+tNpeFMN+gGvC60DPgiuRO+AAAAAAAAA== --------------ms090503060706030402070500-- From nobody Wed Feb 4 15:19:19 2015 Return-Path: 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 D5B141A0016 for ; Wed, 4 Feb 2015 15:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 h-3zbDBV4-R7 for ; Wed, 4 Feb 2015 15:19:12 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5276D1A0011 for ; Wed, 4 Feb 2015 15:19:12 -0800 (PST) Received: from srv4.stroeder.local (srv4.stroeder.local [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id 29A7A1CF77; Thu, 5 Feb 2015 00:19:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srv4.stroeder.local (Postfix) with ESMTP id 55BB11CE60; Thu, 5 Feb 2015 00:19:07 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.local Received: from srv4.stroeder.local ([127.0.0.1]) by localhost (srv4.stroeder.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yni0SxilyGQF; Thu, 5 Feb 2015 00:18:56 +0100 (CET) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id B203F1CE5F; Thu, 5 Feb 2015 00:18:55 +0100 (CET) Message-ID: <54D2A8DF.8030002@stroeder.com> Date: Thu, 05 Feb 2015 00:18:55 +0100 From: =?UTF-8?Q?Michael_Str=c3=b6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32 MIME-Version: 1.0 To: Mark R Bannister References: <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <1422454472.32747.38.camel@ssimo.org> <54CEA9A4.1020709@proseconsulting.co.uk> <54CF5178.7040406@stroeder.com> <54D2955E.3010608@proseconsulting.co.uk> In-Reply-To: <54D2955E.3010608@proseconsulting.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050701060001030909070509" Archived-At: Cc: ldapext@ietf.org Subject: Re: [ldapext] RFC2307, netgroups, DBIS X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:19:15 -0000 This is a cryptographically signed message in MIME format. --------------ms050701060001030909070509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > michael@stroeder.com wrote: >> Mark R Bannister wrote: >>> On 28/01/2015 14:14, Simo wrote: >>>> It hurts me to curb enthusiasm, but I think your drafts are not a st= ep >>>> forward, at most a step sideways, and ignore what's out there right = now. >>> Given that they were written to fix specific deficiencies in RFC2307b= is >>> that were causing pain in a number of very large enterprises I have w= orked >>> for, I don't see how they could be considered a step sideways. >> Maybe I did not look closely enough. Could you please point me to some= text >> describing the specific deficiencies you solved in more detail? >=20 > Have at look at the abstract on page 2 of > http://www.ietf.org/id/draft-bannister-dbis-mapping-06.txt. One of the= first > biggest requirements was reintroducing case sensitivity in a way that w= ould be > fully compatible with NIS, see the description of the en (4.2) and rn (= 4.3) > attributes in particular. Yes, case-sensitive matching is an issue and I already saw that text in y= our drafts. I've simply added additional local constraints to the config limi= ting e.g. attribute 'uid' to lower-case values. So it was not that important t= o me. > Also, another requirement was to fix the schema so > that duplicate alias names could be easily detected and prevented (1.2)= =2E Are you talking about this text? https://tools.ietf.org/html/draft-bannister-dbis-mapping-00#section-1.2 Frankly I don't get it (besides the SHALL for LDAP client configuration).= > Legacy unices ... depends how old we're talking. I currently have some= thing > that works on RHEL4.8 and newer, and the large organisations I have spe= nt most > of my time with over the past 5 years are at a point where RHEL4.8 is t= heir > oldest legacy now. That's pretty old right now. > Strange appliances - not unless I can get the vendor to add support for= DBIS. And that is exactly the point. > However, even the appliances I've worked with support local class & att= ribute > remapping rules,=20 Unfortunately there are counter examples where you cannot configure local= class & attribute remapping rules. >> My approach is to lower the configuration level the client has to supp= ort by >> filtering what's delivered to the client at the LDAP server. >=20 > By filtering, you mean just removing entries from maps? Yes, making users, user groups and sudoers entries invisible if the clien= t is not authorized to see them. > But you still have an old schema to support What the client sees is fully compatible to RFC2307(bis) and sudo-ldap sc= hema. > that wasn't fully NIS compatible to begin with ... I don't care about full NIS feature set. I've replaced it with something different. ;-) Ciao, Michael. --------------ms050701060001030909070509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNTAyMDQyMzE4NTVaMCMGCSqGSIb3DQEJBDEWBBTVz48PWPwH SzBDnKRIVTbHhhAZDDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAx8BpAduE JyDMG29BULqhQS1W+mgk0MEdx1ZdP26EXkhHgSFkTPcFj/IprOKy6saN8foTPEj7b+S9cdHL ngYaEtDPf+bXeZfBRYn+GSeqUVT/CxvjnmxZm6FVhQcOUcfOD0fAj8bYfXwnpQsO5YfKX3PC f944YayL2D3q7YmeGb5OTgXipBOs+of7EmtwJ7lnYJZtmP4ngU3318mszEEsGSKhEpZGwV0w 1K1oZPBMwEzfCalGQwZbZ2ud1HYjG0QrtVk6a91jvm2DmmpzMlWV1zIxJSRSXHTplPgieADO SK2w3ZHwipAwHYRobGzTGdBcfZZAXcu/HNrsLy4e+SDWUAAAAAAAAA== --------------ms050701060001030909070509-- From nobody Thu Feb 5 00:51:24 2015 Return-Path: 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 8A3031A00FA for ; Thu, 5 Feb 2015 00:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 05C4936pu1KC for ; Thu, 5 Feb 2015 00:51:18 -0800 (PST) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D7E1A0145 for ; Thu, 5 Feb 2015 00:51:18 -0800 (PST) Received: by pdbft15 with SMTP id ft15so6509744pdb.5 for ; Thu, 05 Feb 2015 00:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cvldwHNtICnlNwaAd4Vnowksd6G3GHvfAv0iuVQpuqE=; b=mOch1wkJDKbx9B8EkVUNn1RVQzlSqbr9XubGxDcuQFOcWq/hw3JkO34CCooepOEA91 8Hn3aIn/PqnZRH2Dw1/8hHCzpwDVkghXQD3++WTibX4gZmrA7NgVmWd5znEetb+d5GgY gLXpAPDBdc5pN+scI07TeObj9js9i/yVQaTk9w5EWImf+M1GjOfCkXluRqhUgYjjHza8 4E0mROrUvn2KHDW5TCofEMMO8HBsVbl/Mf5AmGXkWAec/ad2GkL7mn58mXV1XfIoahZP 2lknFABjLqfEM76eDwO961ceM8ZwM295sYUX8k08OyI78RRhlGxTAqm8seTo50W3P5Pp wioQ== MIME-Version: 1.0 X-Received: by 10.68.224.6 with SMTP id qy6mr3775015pbc.155.1423126278595; Thu, 05 Feb 2015 00:51:18 -0800 (PST) Received: by 10.70.44.48 with HTTP; Thu, 5 Feb 2015 00:51:18 -0800 (PST) In-Reply-To: <54C56900.8010105@stroeder.com> References: <54C55A27.8020903@stroeder.com> <54C56900.8010105@stroeder.com> Date: Thu, 5 Feb 2015 09:51:18 +0100 Message-ID: From: =?UTF-8?Q?Cl=C3=A9ment_OUDOT?= To: =?UTF-8?Q?Michael_Str=C3=B6der?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: LDAP Extensions list Subject: Re: [ldapext] LDAP work at IETF... X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 08:51:20 -0000 2015-01-25 23:06 GMT+01:00 Michael Str=C3=B6der : > Cl=C3=A9ment OUDOT wrote: >> 2015-01-25 22:03 GMT+01:00 Michael Str=C3=B6der : >>> Gavin Henry wrote: >>>>> I would also like to hear about volunteers to work on those documents= , either contributing text or reviewing them carefully. >>>> >>>> I would like to help where I can. >>> >>> Glad to here that. Do you have any particular interest. >>> >>> Everybody can start reviewing existing stuff. Which could also mean th= at you >>> simply ask questions if something is not clear enough. >>> >>> For inetOrgPerson 2.0 it would help if we collect a wish list and then = compile >>> a realistic requirement list from that. >> >> I am also volunteer to help, especially on the password policy draft. > > Would you be willing to act as an editor? > > If yes, then simply start a new e-mail thread. > > A good start would be to agree on a goal. > > IMHO we should try to mainly document current state of implementations of > draft-behera-ldap-password-policy, but also have a closer look on Appendi= x A > of http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00 > > Digging the list archives could also help here. Hi, thanks for the inputs, I will do my best to work on this. I'll try to start on new thread on the subject. Cl=C3=A9ment OUDOT. From nobody Thu Feb 5 01:48:33 2015 Return-Path: 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 45CCA1A01A9 for ; Thu, 5 Feb 2015 01:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.815 X-Spam-Level: X-Spam-Status: No, score=0.815 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 A90KxdHG-Hiq for ; Thu, 5 Feb 2015 01:48:29 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E5B1A0166 for ; Thu, 5 Feb 2015 01:48:29 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so6499259wgh.10 for ; Thu, 05 Feb 2015 01:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=jtW0y7ZsgLK335/rL1kNXslsGqMa+seGb8Ue4LvJakk=; b=zc8jVg9PDXspl92g1F7yyZvzK2TRED0A6KSIrq95XtxzRWPOm/jZicQK2xq5dx1Nyf 3317nAOQjemVlYxEd8MjZNEbxevh5xSFfCLWrGMRBNI1fSfJFLnosFER8FMfJLM0h3nL dlKd3wXaNib+oAsJ0bjBa2GlfqSblEJgkeYhHnXHl/JzL/GRkxuc8F4sjnqdpGvc76jN gvoO/fWBcZTrdpRLiUhhC29Zdl2AnctSuZYqbVG22fiKqvHpjhVum2fiF0SIs2VMALBb 4DLUyIxFfRAXOmeOcuW3YGuGiTnDUFgJHsBGyumnr8u61NUjh4o046EeyniB4hnm5Wqq lq6w== X-Received: by 10.194.108.162 with SMTP id hl2mr5938411wjb.134.1423129708154; Thu, 05 Feb 2015 01:48:28 -0800 (PST) Received: from lpm.local ([2a01:e35:2ec9:65c0:59ae:c20e:fe6:cb69]) by mx.google.com with ESMTPSA id bv16sm16495686wib.0.2015.02.05.01.48.25 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 01:48:26 -0800 (PST) Date: Thu, 5 Feb 2015 10:48:24 +0100 From: Ludovic Poitou To: =?utf-8?Q?Michael_Str=C3=B6der?= , =?utf-8?Q?Cl=C3=A9ment_OUDOT?= Message-ID: In-Reply-To: References: <54C55A27.8020903@stroeder.com> <54C56900.8010105@stroeder.com> X-Mailer: Airmail Beta (289) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="54d33c68_66ef438d_8230" Archived-At: Cc: LDAP Extensions list Subject: Re: [ldapext] LDAP work at IETF... X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 09:48:31 -0000 --54d33c68_66ef438d_8230 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Clement, There was a general consensus that the current password policy draft need= s to be split in multiple documents to separate the configuration of it, = the internal state representation and the management side of it (controls= and possible extended operations). Ludo --=C2=A0 Ludovic Poitou http://ludopoitou.com On 5 =46eb 2015 at 09:51:26, Cl=C3=A9ment OUDOT (clem.oudot=40gmail.com) = wrote: 2015-01-25 23:06 GMT+01:00 Michael Str=C3=B6der := > Cl=C3=A9ment OUDOT wrote: >> 2015-01-25 22:03 GMT+01:00 Michael Str=C3=B6der : >>> Gavin Henry wrote: >>>>> I would also like to hear about volunteers to work on those documen= ts, either contributing text or reviewing them carefully. >>>> >>>> I would like to help where I can. >>> >>> Glad to here that. Do you have any particular interest. >>> >>> Everybody can start reviewing existing stuff. Which could also mean t= hat you >>> simply ask questions if something is not clear enough. >>> >>> =46or inetOrgPerson 2.0 it would help if we collect a wish list and t= hen compile >>> a realistic requirement list from that. >> >> I am also volunteer to help, especially on the password policy draft. > > Would you be willing to act as an editor=3F > > If yes, then simply start a new e-mail thread. > > A good start would be to agree on a goal. > > IMHO we should try to mainly document current state of implementations = of > draft-behera-ldap-password-policy, but also have a closer look on Appen= dix A > of http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00 > > Digging the list archives could also help here. Hi, thanks for the inputs, I will do my best to work on this. I'll try to start on new thread on the subject. Cl=C3=A9ment OUDOT. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ldapext mailing list Ldapext=40ietf.org https://www.ietf.org/mailman/listinfo/ldapext --54d33c68_66ef438d_8230 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline