From dbis@proseconsulting.co.uk Sun Jan 5 12:22:12 2014 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 D56B71AF7CE for ; Sun, 5 Jan 2014 12:22:12 -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, 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 TOj_3wMaygdl for ; Sun, 5 Jan 2014 12:22:09 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id C40061AF7CD for ; Sun, 5 Jan 2014 12:22:09 -0800 (PST) Received: from host31-51-252-44.range31-51.btcentralplus.com ([31.51.252.44] helo=[192.168.1.68]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1VzuCt-00068c-UQ for ldapext@ietf.org; Sun, 05 Jan 2014 20:22:00 +0000 Message-ID: <52C9BED5.2080900@proseconsulting.co.uk> Date: Sun, 05 Jan 2014 20:21:41 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ldapext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 X-Mailman-Approved-At: Sun, 05 Jan 2014 18:46:10 -0800 Subject: [ldapext] DBIS - new IETF drafts 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, 05 Jan 2014 20:23:48 -0000 In August this year, I submitted some new IETF drafts with the intent that they would replace NIS and RFC2307. It introduces Directory Based Information Services (DBIS). Michael Ströder suggested I post a link to this mailing list. The following article (and further articles on my blog) discuss some of the aspects of DBIS, and link to all of the relevant internet drafts: http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html I am currently working on a reference implementation here: http://sourceforge.net/projects/dbis/ This may be coming out of the blue for many of you, and I appreciate you may need some time to read and digest my drafts, and then ask me lots of questions. But my first question to you is, where is the best place for discussion related to these drafts? Is this the mailing list to use? Best regards, Mark Bannister. e: dbis@proseconsulting.co.uk From hyc@highlandsun.com Mon Jan 6 09:40:26 2014 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 D10721AE12E for ; Mon, 6 Jan 2014 09:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6gK8Nhy7HSsj for ; Mon, 6 Jan 2014 09:40:24 -0800 (PST) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id 547121AE136 for ; Mon, 6 Jan 2014 09:40:23 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 58EF910F3D; Mon, 6 Jan 2014 12:40:14 -0500 (EST) Message-ID: <52CAEA7D.5030002@highlandsun.com> Date: Mon, 06 Jan 2014 09:40:13 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1 MIME-Version: 1.0 To: Mark R Bannister , ldapext@ietf.org References: <52C9BED5.2080900@proseconsulting.co.uk> In-Reply-To: <52C9BED5.2080900@proseconsulting.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 17:40:27 -0000 Mark R Bannister wrote: > In August this year, I submitted some new IETF drafts with the intent > that they would replace NIS and RFC2307. It introduces Directory Based > Information Services (DBIS). > > Michael Ströder suggested I post a link to this mailing list. The > following article (and further articles on my blog) discuss some of the > aspects of DBIS, and link to all of the relevant internet drafts: > http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html > > I am currently working on a reference implementation here: > http://sourceforge.net/projects/dbis/ > > This may be coming out of the blue for many of you, and I appreciate you > may need some time to read and digest my drafts, and then ask me lots of > questions. > > But my first question to you is, where is the best place for discussion > related to these drafts? Is this the mailing list to use? Yes, this is the correct list. I must say I'm alarmed at seeing a new proposal that is primarily based on NIS-compatible attribute values. This is exactly the same fundamental problem in the original RFC2307 which made it less than useful for non-Solaris-based OSs like AIX and HPUX. This is the same flaw that I attempted to correct in my updated draft http://tools.ietf.org/html/draft-howard-rfc2307bis-02 If you're going to all the trouble of storing data into a universally accessible distributed database, you must store it in a canonical format, not a particular OS-specific format as NIS/RFC2307 did. A lot of the data elements and behaviors that the DBIS spec defines appear to be client-implementation-specific details. It seems to me their definition is inappropriate in (outside the scope of) a universally accessible distributed data context. The discussion of caching here http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such example - this is purely a client-side implementation issue. Also you give nscd as an example, and nscd has been thoroughly discredited and is well known to be unsuitable for real use. Critical deployments can use a local LDAP server with a replica of the central data, to avoid error-prone caching implementations. This is a commonly recommended approach when using OpenLDAP nssov, for example. I agree that this area of spec needs to be polished up, but not by disregarding all of the work that was done and experience that has been gained since the original RFC2307 was published. > Best regards, > Mark Bannister. > > e: dbis@proseconsulting.co.uk > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From dbis@proseconsulting.co.uk Mon Jan 6 13:00:31 2014 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 665F81AE14D for ; Mon, 6 Jan 2014 13:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 X70zuYfS676M for ; Mon, 6 Jan 2014 13:00:28 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 386D01AE146 for ; Mon, 6 Jan 2014 13:00:27 -0800 (PST) Received: from host86-182-221-59.range86-182.btcentralplus.com ([86.182.221.59] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W0HHV-00066B-Pr; Mon, 06 Jan 2014 21:00:18 +0000 Message-ID: <52CB194D.3090009@proseconsulting.co.uk> Date: Mon, 06 Jan 2014 20:59:57 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Howard Chu , ldapext@ietf.org References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> In-Reply-To: <52CAEA7D.5030002@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 21:00:31 -0000 On 06/01/2014 17:40, Howard Chu wrote: > Mark R Bannister wrote: >> In August this year, I submitted some new IETF drafts with the intent >> that they would replace NIS and RFC2307. It introduces Directory Based >> Information Services (DBIS). >> > Yes, this is the correct list. First, Howard let me apologise up-front for not approaching you about this sooner. I appreciate, as the editor of RFC2307bis-02 that it must come as quite a shock to you to see a new set of Internet Drafts released that could be seen as a direct challenge to your work, and I quite understand your defensive posture. However, I launched this initiative as a direct result of working with large corporations (mainly banks) who were using RFC2307 extensively across big Linux and Solaris installations (between 10,000 to 40,000 hosts) and facing numerous pain-points which needed to be addressed. It was purely technically motivated, and I did not mean to cause any offence. I am completely open to ideas and suggestions to further improve DBIS, and I think if you dig deep into these drafts and ask me detailed questions you'll realise that a lot of time and thought has gone into every decision I have made thus far, including preserving whatever makes sense to preserve from the RFC2307 heritage. > > I must say I'm alarmed at seeing a new proposal that is primarily > based on NIS-compatible attribute values. This is exactly the same > fundamental problem in the original RFC2307 which made it less than > useful for non-Solaris-based OSs like AIX and HPUX. This is the same > flaw that I attempted to correct in my updated draft > http://tools.ietf.org/html/draft-howard-rfc2307bis-02 Please would you give me some specific examples of what you believe is less than useful for AIX and HP-UX, and how you corrected these in RFC2307bis-02. Forgive me but I am coming from a Linux and Solaris perspective. > > If you're going to all the trouble of storing data into a universally > accessible distributed database, you must store it in a canonical > format, not a particular OS-specific format as NIS/RFC2307 did. Please give me some specific examples of attributes which I am storing in an OS-specific format. I am struggling to think of any, so some examples will help me understand your point better. > > A lot of the data elements and behaviors that the DBIS spec defines > appear to be client-implementation-specific details. It seems to me > their definition is inappropriate in (outside the scope of) a > universally accessible distributed data context. Again, examples would help you make your point, and help me to understand it. > > The discussion of caching here > http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such > example - this is purely a client-side implementation issue. Also you > give nscd as an example, and nscd has been thoroughly discredited and > is well known to be unsuitable for real use. Critical deployments can > use a local LDAP server with a replica of the central data, to avoid > error-prone caching implementations. This is a commonly recommended > approach when using OpenLDAP nssov, for example. That's why it's in a section titled "Implementation Notes", i.e. notes to help those implementing DBIS. It's not core to the draft, it's just some helpful notes to make the point that the domain-level TTL must override any local settings. I don't see that as such a big deal. Am I missing something? > > I agree that this area of spec needs to be polished up, but not by > disregarding all of the work that was done and experience that has > been gained since the original RFC2307 was published. Yes, this is why I suspect I may be causing offence, for which I apologise. If you believe I am disregarding all of the work that was done on RFC2307 and RFC2307bis, this is not true. When writing DBIS I spent much of my time reading RFC2307 and RFC2307bis, ensuring that I had thought about everything, and that I could sensibly preserve whatever I could from those documents, because I did not wish to reinvent the wheel. However, some of the fundamental incompatibilities with NIS, and some of the flexibility and modularity required in a successor, mandated (at least in my mind) splitting it out into a number of separate drafts and providing a framework to makes it easy for others in the future to define additional maps as and when required. I did actually begin by thinking, shall I just expand on RFC2307bis? But I'm sorry to say this, I found the document too unwieldy and inflexible to add much value to it. I hope you do not feel resentful and perhaps would consider offering some more constructive guidance on the development of DBIS. Best regards, Mark Bannister. e: dbis@proseconsulting.co.uk From hyc@highlandsun.com Mon Jan 6 13:19:46 2014 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 F00031AE23C for ; Mon, 6 Jan 2014 13:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a49F-uoSeuOk for ; Mon, 6 Jan 2014 13:19:44 -0800 (PST) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4001AE1F6 for ; Mon, 6 Jan 2014 13:19:44 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 201E510F3D; Mon, 6 Jan 2014 16:19:32 -0500 (EST) Message-ID: <52CB1DE3.6040000@highlandsun.com> Date: Mon, 06 Jan 2014 13:19:31 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1 MIME-Version: 1.0 To: Mark R Bannister , ldapext@ietf.org References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <52CB194D.3090009@proseconsulting.co.uk> In-Reply-To: <52CB194D.3090009@proseconsulting.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 21:19:46 -0000 Mark R Bannister wrote: > > On 06/01/2014 17:40, Howard Chu wrote: >> Mark R Bannister wrote: >>> In August this year, I submitted some new IETF drafts with the intent >>> that they would replace NIS and RFC2307. It introduces Directory Based >>> Information Services (DBIS). >>> >> Yes, this is the correct list. > > First, Howard let me apologise up-front for not approaching you about > this sooner. I appreciate, as the editor of RFC2307bis-02 that it must > come as quite a shock to you to see a new set of Internet Drafts > released that could be seen as a direct challenge to your work, and I > quite understand your defensive posture. However, I launched this > initiative as a direct result of working with large corporations (mainly > banks) who were using RFC2307 extensively across big Linux and Solaris > installations (between 10,000 to 40,000 hosts) and facing numerous > pain-points which needed to be addressed. It was purely technically > motivated, and I did not mean to cause any offence. I am completely > open to ideas and suggestions to further improve DBIS, and I think if > you dig deep into these drafts and ask me detailed questions you'll > realise that a lot of time and thought has gone into every decision I > have made thus far, including preserving whatever makes sense to > preserve from the RFC2307 heritage. Nothing defensive here at all. I have nothing personally invested in one spec or another. As I stated before, it's a mistake to embed Solaris-specific semantics into a supposedly universal spec. My response is purely technical, since technical details are my only concern. >> I must say I'm alarmed at seeing a new proposal that is primarily >> based on NIS-compatible attribute values. This is exactly the same >> fundamental problem in the original RFC2307 which made it less than >> useful for non-Solaris-based OSs like AIX and HPUX. This is the same >> flaw that I attempted to correct in my updated draft >> http://tools.ietf.org/html/draft-howard-rfc2307bis-02 > > Please would you give me some specific examples of what you believe is > less than useful for AIX and HP-UX, and how you corrected these in > RFC2307bis-02. Forgive me but I am coming from a Linux and Solaris > perspective. This is all pretty old ground. http://www.openldap.org/lists/openldap-software/200310/msg00138.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From dbis@proseconsulting.co.uk Mon Jan 6 13:29:53 2014 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 A6BD71AE25B for ; Mon, 6 Jan 2014 13:29:53 -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 uE7e2ic_ta2X for ; Mon, 6 Jan 2014 13:29:51 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 856AE1AE251 for ; Mon, 6 Jan 2014 13:29:50 -0800 (PST) Received: from host86-182-221-59.range86-182.btcentralplus.com ([86.182.221.59] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W0Hjx-0001xT-1v; Mon, 06 Jan 2014 21:29:41 +0000 Message-ID: <52CB2030.3010403@proseconsulting.co.uk> Date: Mon, 06 Jan 2014 21:29:20 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Simo , Howard Chu References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> In-Reply-To: <1389033674.27654.32.camel@pico.ipa.ssimo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 21:29:54 -0000 On 06/01/2014 18:41, Simo wrote: > I have to say I have to agree with Howard here, although I wouldn't > consider rfc2307bis *the* solution, at least it tried to fix some of > the most glaring issues ion rfc2307, there is lots that can be > improved of course, but the direction is good. As I wrote in my response to Howard just now, I considered both RFC2307 and the improvements made in RFC2307bis when I wrote the DBIS drafts. I have not disregarded lessons learned from the past, I am simply attempting to move it onto the next logical step. Look harder, I think you'll see a lot of technical content you recognise (although admittedly I couldn't keep much of the descriptive text because it didn't fit the new model). >> If you're going to all the trouble of storing data into a universally >> accessible distributed database, you must store it in a canonical format, not >> a particular OS-specific format as NIS/RFC2307 did. > If there is a flawed model that should *not* be followed going forward that is NIS. > And especially netgroups, please spare us from the disease of NIS > netgroups, they should be buried, there are much better ways to group > diverse objects. Please provide a technical description of "disease" please, because it's hard to do anything constructive with a statement like that. Like it or not, there are very big installations out there using NIS or RFC2307 and netgroups. If netgroups have been built into the way a corporation works, they'll possibly never be extracted. Embrace and extend (without the extinguish) if you'd like to bring those corporations with you and make improvements for everyone. Ignore them, and you get IPv6 all over again. I have taken netgroups and tried to take the "disease" out of them, while providing a clear migration path, but was it the same disease you were suffering? I don't know. Perhaps. More detail please. > >> A lot of the data elements and behaviors that the DBIS spec defines appear to >> be client-implementation-specific details. It seems to me their definition is >> inappropriate in (outside the scope of) a universally accessible distributed >> data context. > Same concerns here. As before, I'm not sure I understand what you mean. Please provide specific examples. >> The discussion of caching here >> http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such example >> - this is purely a client-side implementation issue. Also you give nscd as an >> example, and nscd has been thoroughly discredited and is well known to be >> unsuitable for real use. Critical deployments can use a local LDAP server with >> a replica of the central data, to avoid error-prone caching implementations. >> This is a commonly recommended approach when using OpenLDAP nssov, for example. > I do not think this section is particularly bad though. > It just mentions nscd (bad as it is) as an example but all it really > does is to prescribe the use of a domain level ttl for all entries. That > may be useful, but I am not sure it sufficient, at the very least you > would have to define also how the client handles negative caching and > have a different timeout there. In the SSSD project we also have > additional knobs, it is a more complex than you think at first area, and > using nscd as a blue print is a bad idea. Yes I have also had similar thoughts about negative caching. On the one hand, not mentioning it at all implies there is one TTL for everything (positive and negative) but leaves room for a local implementation to vary that. On the other hand, if there is no standard place to store a negative TTL then we get fragmentation and I'd like to avoid that. This was the whole point about putting a framework out there, because at the moment too many of these configuration attributes today are implementation specific and scattered around the place. DBIS aims to provide a single place that describes how the whole domain is configured, right down to the nuts and bolts. About all a local configuration file would need to know is how to contact the LDAP server and a base DN for the domain. Everything else it needs to know is in a standard place in the DIT. >> I agree that this area of spec needs to be polished up, but not by >> disregarding all of the work that was done and experience that has been gained >> since the original RFC2307 was published. > Ack. > > For the security point of view I find it extremely amusing that the > drafts assumes distribution of the hashes to clients (and mandates the > use of CRYPT to top it all!). I think that is a very wrongheaded > approach and should not be pursued at all. CRYPT is a throwback to RFC2307bis and provides a place to start. That's why these are drafts, because they are a work in progress. I need to support old clients as well as new clients, possibly old clients that cannot be upgraded. Backwards compatibility is important. If DBIS doesn't support CRYPT, how do I support the old clients? Suggestions welcomed. Now I was considering implementing pseudo NIS servers that act as a gateway for NIS clients that can't be upgraded, but the PAM modules on the old clients are going to expect passwords in CRYPT format I assume? I had yet to prove this in a lab environment, but until now I assumed that CRYPT would have to be the lowest common denominator, I'd have to support it. Better authentication schemes can be added as and when I found the time to further explore the options. > > Mark, > you are obviously building new clients as nothing existing supports your > schema so you have to implement new stuff. With this premise keeping > distributing hashes to any machines on a network instead of relying on a > LDAP bind operation and keeping hashes private is simply not acceptable > in 2014 IMO and should not be ratified in IETF as a standard. > > Simo. > > I agree the authentication piece always made me uncomfortable, but then I'm no expert on the subject. Find me an expert, lock us in a room with a whiteboard, and I'm sure we'll come out with something that ticks all the right boxes, my previous paragraph notwithstanding. Best regards, Mark Bannister. e: dbis@proseconsulting.co.uk From dbis@proseconsulting.co.uk Mon Jan 6 13:35:47 2014 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 364E81AE251 for ; Mon, 6 Jan 2014 13:35:47 -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 p9OiOoJyoksv for ; Mon, 6 Jan 2014 13:35:45 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id AB8FD1AE242 for ; Mon, 6 Jan 2014 13:35:45 -0800 (PST) Received: from host86-182-221-59.range86-182.btcentralplus.com ([86.182.221.59] helo=[192.168.1.68]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W0Hpg-0000aU-Ny; Mon, 06 Jan 2014 21:35:37 +0000 Message-ID: <52CB2194.30907@proseconsulting.co.uk> Date: Mon, 06 Jan 2014 21:35:16 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Howard Chu , ldapext@ietf.org References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <52CB194D.3090009@proseconsulting.co.uk> <52CB1DE3.6040000@highlandsun.com> In-Reply-To: <52CB1DE3.6040000@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 21:35:47 -0000 On 06/01/2014 21:19, Howard Chu wrote: > >>> I must say I'm alarmed at seeing a new proposal that is primarily >>> based on NIS-compatible attribute values. This is exactly the same >>> fundamental problem in the original RFC2307 which made it less than >>> useful for non-Solaris-based OSs like AIX and HPUX. This is the same >>> flaw that I attempted to correct in my updated draft >>> http://tools.ietf.org/html/draft-howard-rfc2307bis-02 >> >> Please would you give me some specific examples of what you believe is >> less than useful for AIX and HP-UX, and how you corrected these in >> RFC2307bis-02. Forgive me but I am coming from a Linux and Solaris >> perspective. > > This is all pretty old ground. > http://www.openldap.org/lists/openldap-software/200310/msg00138.html > Ok, so rather than being "alarmed" you could have just said, "please would you consider seconds instead of days for some of the shadow attributes". This is a small request, and very easy to put into DBIS, and by no means a "fundamental problem". Let's put comments into their right perspective. Do you have any more alarming problems that can be turned into simple requests? Thanks :-) p.s. I'm being playful, no rudeness intended. From hyc@highlandsun.com Mon Jan 6 13:49:52 2014 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 E1D8C1AE270 for ; Mon, 6 Jan 2014 13:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hS1H6sO-cs-s for ; Mon, 6 Jan 2014 13:49:51 -0800 (PST) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id 77BDA1AE26F for ; Mon, 6 Jan 2014 13:49:51 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 1CF5710F3D; Mon, 6 Jan 2014 16:49:40 -0500 (EST) Message-ID: <52CB24F4.1030503@highlandsun.com> Date: Mon, 06 Jan 2014 13:49:40 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1 MIME-Version: 1.0 To: Mark R Bannister , 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> In-Reply-To: <52CB2194.30907@proseconsulting.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 21:49:53 -0000 Mark R Bannister wrote: > On 06/01/2014 21:19, Howard Chu wrote: >> >>>> I must say I'm alarmed at seeing a new proposal that is primarily >>>> based on NIS-compatible attribute values. This is exactly the same >>>> fundamental problem in the original RFC2307 which made it less than >>>> useful for non-Solaris-based OSs like AIX and HPUX. This is the same >>>> flaw that I attempted to correct in my updated draft >>>> http://tools.ietf.org/html/draft-howard-rfc2307bis-02 >>> >>> Please would you give me some specific examples of what you believe is >>> less than useful for AIX and HP-UX, and how you corrected these in >>> RFC2307bis-02. Forgive me but I am coming from a Linux and Solaris >>> perspective. >> >> This is all pretty old ground. >> http://www.openldap.org/lists/openldap-software/200310/msg00138.html >> > > Ok, so rather than being "alarmed" you could have just said, "please > would you consider seconds instead of days for some of the shadow > attributes". This is a small request, and very easy to put into DBIS, > and by no means a "fundamental problem". Let's put comments into their > right perspective. > > Do you have any more alarming problems that can be turned into simple > requests? The alarming part is that such obvious flaws in data modeling are still occurring today, over a decade after they were first addressed. I raised these issues back in 2001 as I recall. Some references in 2002 http://www.openldap.org/lists/openldap-software/200201/msg00628.html > > Thanks :-) > > p.s. I'm being playful, no rudeness intended. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Mon Jan 6 13:57:38 2014 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 E18F91AE27F for ; Mon, 6 Jan 2014 13:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hQF39nWFe_tu for ; Mon, 6 Jan 2014 13:57:36 -0800 (PST) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id BCC351AE27E for ; Mon, 6 Jan 2014 13:57:36 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id AE55A10F3D; Mon, 6 Jan 2014 16:57:27 -0500 (EST) Message-ID: <52CB26C6.1070406@highlandsun.com> Date: Mon, 06 Jan 2014 13:57:26 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1 MIME-Version: 1.0 To: Mark R Bannister , 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> In-Reply-To: <52CB2194.30907@proseconsulting.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 21:57:39 -0000 Mark R Bannister wrote: > Do you have any more alarming problems that can be turned into simple > requests? Just read thru http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and again there's a lot of redundant work here, this time in regards to http://tools.ietf.org/html/draft-behera-ldap-password-policy-10 The obvious issue is collisions in some attribute descriptors with the ppolicy spec, which is already widely deployed. More problematic is the data model itself, again. Storing the actual policy settings in the user entries will be unmanageable for any moderately large sized user population. This is one reason why draft-behera uses dedicated policy objects. It is the client side DUA's job to adapt the universal data store to the local host's security implementation. And we already have pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so I don't see much value in defining yet another new broken data model that has no existing client support. As much as you claim to have read and absorbed the prior work in this area, it really appears that you have ignored most of it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From arthur@arthurdejong.org Tue Jan 7 14:25:35 2014 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 DEC1C1AE212 for ; 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 ; 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 ; 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 To: Mark R Bannister , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 22:27:05 -0000 --=-hyrQtB4Ql9acFPKQOEho Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. --=20 -- arthur - arthur@arthurdejong.org - http://arthurdejong.org/ -- --=-hyrQtB4Ql9acFPKQOEho Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAABCAAGBQJSzH7SAAoJECqLdGgQ4K/BVywQAJIwmjKYCe9kap4b/BN2x5SK NepmmEKKWx6faPqBJSBD9cFs02Zlk3S8cvDrBlF3j9tNFz3whWcinzs3xetGbLiK T3OUrDMILTgiH4BqQZwsmpOXzU5YK2Brwknnsn2HkHEv/TOpFgI4e2Hw2k8dqRq3 5tf0HDQj9ZxpAjCNbf20RUeyZuZ3I81jFK59yqhwB1PphOf2ciEToYAHPESVr7fo ou0aY00VyoSfAubAS4FNI2Ua+hKebaDWkFuolQgMdE0YEoRo5btIPhDRB5ZUJdFW Wh1jbv9zH1NKm2mGc8RyHAyZXVjWV3dF8Bmhg7SbjKicCXkFjZ6PghQ5Mbk5/tWA o1yHJbWg7NBAd5eJtChIBy+1rvX7n9lOzfCA+PBGm4pHxh/96yreNQnZ65YXKB4D oe6AXt+CZGCrRnR+8CPHQ0a3TfUCrLPHaMM+CCetLAJWt10llCD2CZFM1G2xY5b3 CYbeUGbj3eKfBCfooNkJErcXkW6sEFSKlHUtEnrWGul/oTvkUkfq1fASRvZsc5K/ 7IOtQTHCxKngHg1r7WEU3eHzLJKrh3P6UsnDtAnEwPhN4obu0jSIAQbxlPNlXgGd WlbKoOB0tXnAQQqiKA1TJBMCzEVVYb14VcySkpiiROHwFWUHnWVf5fKo+h3GIVWD wYlfAFL0aSaevXPSNhT6 =UlxK -----END PGP SIGNATURE----- --=-hyrQtB4Ql9acFPKQOEho-- From michael@stroeder.com Wed Jan 8 12:08:07 2014 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 DD1E41AE575 for ; Wed, 8 Jan 2014 12:08:07 -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 C2VP9CwgMKl5 for ; Wed, 8 Jan 2014 12:08:05 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC4F1ADFA6 for ; Wed, 8 Jan 2014 12:08:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 8C6F160719 for ; Wed, 8 Jan 2014 21:07:54 +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 geqpGaTfk_8p for ; Wed, 8 Jan 2014 21:07:46 +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 AD19A60714 for ; Wed, 8 Jan 2014 20:07:45 +0000 (UTC) Message-ID: <52CD9F94.2090707@stroeder.com> Date: Wed, 08 Jan 2014 19:57:24 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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: ldapext@ietf.org References: <1389133522.4574.30.camel@sorbet.thuis.net> In-Reply-To: <1389133522.4574.30.camel@sorbet.thuis.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000806010207010903080700" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:08:08 -0000 This is a cryptographically signed message in MIME format. --------------ms000806010207010903080700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Arthur de Jong wrote: > I personally like the use of flat names to describe group membership. I= t > makes the semantics much simpler than dealing with things like the > member or uniqueMember attribute (at least from a client implementation= > perspective). >=20 > 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. Using DNs allows to implement server-side access control. I'm not a frien= d of letting client-side demons enforce the access control because if a machin= e got hacked the attacker can find out more about the infrastructure. Ciao, Michael. --------------ms000806010207010903080700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA4MTg1NzI0WjAj BgkqhkiG9w0BCQQxFgQUFvyYWhTC9tkWjsbcpNVJkeTg+1wwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAE6WncjC+jrcwCjRt1Ly7zpzClHMDWhxF /Egka/QyfgoTqc3ulCKHyhMjMLURmPdTv8EONz9KzVrhj42AgwHNjjkeakklwsJO8Yz55klZ 3hysJntccg94gqTbtRvC3ebivgKJnBrfyPpQOdNq7wnG/RB+U15AW7m3QByzEs9vKd6YNZbq QQgC44cvAzQsYB1iUlP0HAWBHVOpSitkrpvfHJ0i0qpTngflyXCbjYWSb2i5nMetaCY3yLF1 z+O2anHraQiBKUGWz3DwkGRgS1WjYp5lcO1dYkZfNbxMoeoX4gv+Fz0Z+oNipH+BofCMfHWG +HvyhZw5cnSuqjDw/bHRjgAAAAAAAA== --------------ms000806010207010903080700-- From michael@stroeder.com Wed Jan 8 12:08:10 2014 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 291031AE597 for ; Wed, 8 Jan 2014 12:08:10 -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 VFVDRv_BpIwO for ; Wed, 8 Jan 2014 12:08:08 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 135141ADFA6 for ; Wed, 8 Jan 2014 12:08:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 576BA606A0; Wed, 8 Jan 2014 21:07:58 +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 zNFvd8Kw9piF; Wed, 8 Jan 2014 21:07:51 +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 9419660715; Wed, 8 Jan 2014 20:07:47 +0000 (UTC) Message-ID: <52CDA099.9070300@stroeder.com> Date: Wed, 08 Jan 2014 20:01:45 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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 , Simo , Howard Chu References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> In-Reply-To: <52CB2030.3010403@proseconsulting.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090706090308050401000908" Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:08:10 -0000 This is a cryptographically signed message in MIME format. --------------ms090706090308050401000908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > On 06/01/2014 18:41, Simo wrote: >> I have to say I have to agree with Howard here, although I wouldn't co= nsider >> rfc2307bis *the* solution, at least it tried to fix some of the most g= laring >> issues ion rfc2307, there is lots that can be improved of course, but = the >> direction is good.=20 Was Simo's message personal or did I miss a posting by him to the ietf-ld= apext list? >> And especially netgroups, please spare us from the disease of NIS >> netgroups, they should be buried, there are much better ways to group >> diverse objects. >=20 > Please provide a technical description of "disease" please, because it'= s hard > to do anything constructive with a statement like that. @Simo: I know that FreeIPA/sssd has a custom schema. Is there a formal description of the schema so we can look at what cure you're implementing= for the netgroups "disease"? Personally I also avoid netgroups (or I don't have a real use-case for th= em for now). Ciao, Michael. --------------ms090706090308050401000908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA4MTkwMTQ1WjAj BgkqhkiG9w0BCQQxFgQUFv3SQWgm5ZKLiT8N59h4YKrSJiQwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEA2B/GynTKUk2b2tBy4l95qIUbASCZAhfy eRJzz2+RdBxnQxeLk0AVGiNDIqv2EFeHPKqYYEwHr/y5EKN2NwSobdpmqIStq8BHZnWsw7W7 f6RmjhOyl6ubEMbjgOyfQD/j+jlAJNgp8p3MjJhL4SsvM1E+IGzt6sv56HkTqkMa8TYgH2ZU x/FHAYP3apiIH1PmP007vvfEFcVGzJ3wKdBReXTAzcxNf6MSrbl9wRb6y6jCo3yhFz09MGtg ZtIkTNWbhEIYZWf28cc5vC2gQ0A51nBjqkPG14AfGzfwW9iAuGmVsKkBbVQyjxovJR136eQl 1H0J0mOdGIvXC4aZZ+0uoQAAAAAAAA== --------------ms090706090308050401000908-- From dbis@proseconsulting.co.uk Wed Jan 8 12:24:50 2014 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 62E781AE0AF for ; Wed, 8 Jan 2014 12:24:50 -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 HLsJ1rsxvz2V for ; Wed, 8 Jan 2014 12:24:48 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id C2DCB1AE0A6 for ; Wed, 8 Jan 2014 12:24:47 -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 ) id 1W0zg5-0004eK-DH; Wed, 08 Jan 2014 20:24:37 +0000 Message-ID: <52CDB3EE.6080203@proseconsulting.co.uk> Date: Wed, 08 Jan 2014 20:24:14 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Howard Chu , 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> <52CB24F4.1030503@highlandsun.com> In-Reply-To: <52CB24F4.1030503@highlandsun.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:24:50 -0000 On 06/01/2014 21:49, Howard Chu wrote: > Mark R Bannister wrote: >> On 06/01/2014 21:19, Howard Chu wrote: >>> >>>>> I must say I'm alarmed at seeing a new proposal that is primarily >>>>> based on NIS-compatible attribute values. This is exactly the same >>>>> fundamental problem in the original RFC2307 which made it less than >>>>> useful for non-Solaris-based OSs like AIX and HPUX. This is the same >>>>> flaw that I attempted to correct in my updated draft >>>>> http://tools.ietf.org/html/draft-howard-rfc2307bis-02 >>>> >>>> Please would you give me some specific examples of what you believe is >>>> less than useful for AIX and HP-UX, and how you corrected these in >>>> RFC2307bis-02. Forgive me but I am coming from a Linux and Solaris >>>> perspective. >>> >>> This is all pretty old ground. >>> http://www.openldap.org/lists/openldap-software/200310/msg00138.html >>> >> >> Ok, so rather than being "alarmed" you could have just said, "please >> would you consider seconds instead of days for some of the shadow >> attributes". This is a small request, and very easy to put into DBIS, >> and by no means a "fundamental problem". Let's put comments into their >> right perspective. >> >> Do you have any more alarming problems that can be turned into simple >> requests? > > The alarming part is that such obvious flaws in data modeling are > still occurring today, over a decade after they were first addressed. > I raised these issues back in 2001 as I recall. Some references in > 2002 http://www.openldap.org/lists/openldap-software/200201/msg00628.html Well, I still wouldn't call that "alarming" unless you are of the singular belief that every message you have personally written has been read by everyone in the world. So, getting down to the exact detail here, and ignoring the fluff, am I right that the only complaint you are making in this particular message is that whereas on Solaris some of the shadow attributes are represented in days, in HP-UX and AIX they are represented in seconds? As already stated, this is easy to fix. So if that is all, I'll log the request, and make the appropriate change in the draft in due course. If you spot any other details you think can be done better, I would really like to know. Best regards, Mark. From dbis@proseconsulting.co.uk Wed Jan 8 12:25:06 2014 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 056811AE179 for ; Wed, 8 Jan 2014 12:25:06 -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 Ev4Hz3Ox0U47 for ; Wed, 8 Jan 2014 12:25:04 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5354E1AE186 for ; Wed, 8 Jan 2014 12:25:00 -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 ) id 1W0zgI-0004iB-GM; Wed, 08 Jan 2014 20:24:50 +0000 Message-ID: <52CDB3FC.2000205@proseconsulting.co.uk> Date: Wed, 08 Jan 2014 20:24:28 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Howard Chu , 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> In-Reply-To: <52CB26C6.1070406@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:25:06 -0000 On 06/01/2014 21:57, Howard Chu wrote: > Mark R Bannister wrote: >> Do you have any more alarming problems that can be turned into simple >> requests? > > Just read thru > http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and again > there's a lot of redundant work here, this time in regards to > http://tools.ietf.org/html/draft-behera-ldap-password-policy-10 Originally I had shadow attributes mingled in with the user and group document, as it is in RFC2307, however I decided quite late on in fact that it would be better as a separate bolt-on option. So it went into its own draft. I thought I'd already made it clear in the drafts that password policies are best handled a separate way, however, DBIS would be incomplete if it did not support the old NIS way of doing it as well. 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. So, what's the harm in supporting it? As long as I make it clear that it is not recommended, which is the intention of the following paragraph in section 1.1.1: It is RECOMMENDED that password policies are managed using native features in the LDAP Directory Server if available, or using Pluggable Authentication Modules [PAM] to provide consistency of security and centralised administration. Whether or not the shadow attributes are used by the policy will vary between implementations. Perhaps we can work this paragraph better. I must admit I haven't seen draft-behera-ldap-password-policy-10 so I shall add that to my reading list. > > The obvious issue is collisions in some attribute descriptors with the > ppolicy spec, which is already widely deployed. draft-behera-ldap-password-policy-10 is already widely deployed, you say? Then it must go higher up in my reading list. > > More problematic is the data model itself, again. Storing the actual > policy settings in the user entries will be unmanageable for any > moderately large sized user population. This is one reason why > draft-behera uses dedicated policy objects. It is the client side > DUA's job to adapt the universal data store to the local host's > security implementation. And we already have > pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so > I don't see much value in defining yet another new broken data model > that has no existing client support. 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. > > As much as you claim to have read and absorbed the prior work in this > area, it really appears that you have ignored most of it. Appearances can be deceptive. If you ask me for a reason why I did something in a particular way, you'll realise I have actually put a lot of thought into the entire design. I haven't ignored RFC2307 nor RFC2307bis, nor indeed any of the RFCs I make reference to in my drafts. I was unaware of draft-behera-ldap-password-policy-10 so thank you for pointing this out. I suspect it will not make a big difference short of perhaps becoming the recommended approach. I'll review it and let you know what I think afterwards. Best regards, Mark. From dbis@proseconsulting.co.uk Wed Jan 8 12:36:39 2014 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 D206C1AE20F for ; Wed, 8 Jan 2014 12:36:39 -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 oFiDCSOIZakh for ; Wed, 8 Jan 2014 12:36:36 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id AAD431AE156 for ; Wed, 8 Jan 2014 12:36:35 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W0zrU-0000dt-Pv; Wed, 08 Jan 2014 20:36:26 +0000 Message-ID: <52CDB6B2.2080406@proseconsulting.co.uk> Date: Wed, 08 Jan 2014 20:36:02 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Simo References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> In-Reply-To: <1389050240.27654.67.camel@pico.ipa.ssimo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:36:40 -0000 On 06/01/2014 23:17, Simo wrote: > On Mon, 2014-01-06 at 21:29 +0000, Mark R Bannister wrote: >> On 06/01/2014 18:41, Simo wrote: >>> I have to say I have to agree with Howard here, although I wouldn't >>> consider rfc2307bis *the* solution, at least it tried to fix some of >>> the most glaring issues ion rfc2307, there is lots that can be >>> improved of course, but the direction is good. >> As I wrote in my response to Howard just now, I considered both RFC2307 >> and the improvements made in RFC2307bis when I wrote the DBIS drafts. I >> have not disregarded lessons learned from the past, I am simply >> attempting to move it onto the next logical step. Look harder, I think >> you'll see a lot of technical content you recognise (although admittedly >> I couldn't keep much of the descriptive text because it didn't fit the >> new model). > One thing I forgot to say is that I haven't seen a good rationale > document to be honest, what did you identify as problems, what did you > see in the field, what solutions did you discard (you mentioned > something about RFC2307bis not being good enough in reply to Howard) and > why. What is the guiding principle behind the choices you made ? > Apologies if you have mentioned all this, my quick read of the initial > pages and introductory paragraphs didn't seem to give this information. You're right I've not written a good rationale document yet and it's something I've been meaning to do. The abstract in draft-bannister-dbis-mapping-02 goes some of the way, it doesn't go all of the way. Thinking about this chronologically: * At one of my clients, NIS was being migrated into Active Directory using the RFC2307bis schema. This client had circa 6,000 Linux hosts and 1,500 Solaris. They had to use a commercial product to achieve this, even though their Linux and Solaris estate had full Open Source support for putting all of their NIS maps, including the automounter, into LDAP and even though they could have used Open Source tools to get the Kerberos authentication working. I even assessed how it could be done with Open Source tooling and wrote about it in my blog which you are welcome to read at your leisure: http://technicalprose.blogspot.co.uk/2011/10/linux-integration-with-active-directory.html. However, they chose a commercial product because the job was so difficult, the Linux tooling so fragmented, and RFC2307bis alone was not going to help them with a big merger of two NIS domains with clashing UIDs and GIDs. It was at this time that I first decided that RFC2307bis did not go far enough to help with the complexities of large corporations, even given the similarities in architecture the way in which NSS is configured on Solaris and Linux is considerably (and unnecessarily) different due to lack of standardisation at the client layer. Unless Open Source tools were to be patched, it would not be possible to manage the merger of two NIS domains with clashing UIDs/GIDs without renumbering large numbers of user and group accounts. I realised at this time the importance of having a standardised abstraction/rewriting layer above the data that would essentially allow the data to be fragmented across the DIT, using a different mix of attributes to define the fields required by NSS databases, and removing the need to perform complex and error-prone data merge and cleansing operations in favour of simply linking and transforming. * Another of my clients, with approx. 35,000 Linux hosts and 1,000 Solaris, struggled in particular with case sensitivity. In fact they had to come up with their own schema on top of RFC2307bis in order to make things case sensitive again (like they were in NIS). It seemed ludicrous to me that RFC2307bis had made stuff case insensitive, and there didn't appear to be a good reason for doing so. So to fix this problem, I couldn't just redefine the same attributes again, because that would make migration from RFC2307bis to DBIS really rather tricky and probably impossible for large deployments. So wherever an attribute in RFC2307bis is defined as case insensitive, but needed to be case sensitive, a new attribute would be required. * Looking first at RFC2307bis and deciding how best to tackle these problems, I also realised that defining all of the NSS databases in a single document was not a good approach. If I were to support an abstraction layer above the data itself, allowing the flexibility I wanted to glue maps together from different parts of the DIT, first I would need a standard framework. This would also solve another thing I didn't like about current implementations, that NSS client configurations can get long, especially when you want to start remapping attribute names, are not always defined in a single configuration file, and differ from one OS to another. If I started with a standard framework, where all of the information pertaining to the location and transformation of the data were in the DIT, it would also make it easier for administrators to make structural changes to this data over time without ever having to touch the client. Where would I define this framework? In configuration map objects, defined in draft-bannister-dbis-mapping-02. It seemed to make natural sense to define the framework in its own document, and for it to be extensible so that even after the standard NSS databases had been described in this framework, vendors could come along in the future and plug-in their own databases (for example, Solaris has extra databases such as user_attr, auth_attr, prof_attr and exec_attr that I wouldn't want to define within DBIS at this time but nothing stops Oracle adding them). It was taking shape itself: one document to describe the framework, then one document for each of the standard NSS databases. * Netgroups, urgh. A third field that always seems redundant, and I've worked at clients where they have thousands of nested netgroups and it's a horrible mess. So I had to do something about those. Cleaning up their definition so there is no redundant data was step one, introducing netservices to help reduce the sheer number of them was step two. I hope the net result will be to make them a lot more appealing and a lot easier to use. > This said, > > What is the point of a new schema if you feel bound to serve unchanged > legacy clients for example, aren't you pretty much shackled to RFC2307 > that way ? So a new schema is required anyway, if problems such as case insensitivity and to be avoided. There are other things I've fixed throughout the schema as well which I won't list here, but should be clear in my drafts. Legacy NIS clients can't use RFC2307, only if they have already been configured with nss_ldap. So, legacy NIS clients can either be migrated to use nss_dbis, or alternatively we can point them at a pseudo NIS server that back-ends to DBIS. Clients already migrated to nss_ldap need to move over to nss_dbis first. This can be done quickly and in stages, because DBIS configuration maps can be defined that point to the existing data in LDAP. It should be as painless as setting up a few configuration maps, then deploying nss_dbis to the clients. New NSS data, such as new user accounts and group accounts, can start to be populated in a different area in the DIT using the new schema, and referenced by a different set of configuration maps, which are received by clients filtered by netgroup. Don't forget that a single client can use data from multiple places in the DIT using a mix of different schemas in order to piece together a single map. Then, optional if you want the benefits of the new schema, we may choose to do a mass migration of data from RFC2307 schema to DBIS schema and get rid of RFC2307 completely. Except switching from nss_ldap to nss_dbis, all this done off-client and seamlessly. The clients are none the wiser that the data is being moved around and transformed beneath them. So, no, not shackled in any way to RFC2307. > OTOH, if you think you can change stuff then why stick to the NIS > paradigm, which doesn't really map well at all to modern directories ? If by this you are referring solely to shadow entries (password policies), then I think I've answered this question in my response to Howard. Do you have examples of anything besides shadow entries that don't map well to modern directories? I could do with some specifics to give you a meaningful response. >>>> If you're going to all the trouble of storing data into a universally >>>> accessible distributed database, you must store it in a canonical format, not >>>> a particular OS-specific format as NIS/RFC2307 did. >>> If there is a flawed model that should *not* be followed going forward that is NIS. >>> And especially netgroups, please spare us from the disease of NIS >>> netgroups, they should be buried, there are much better ways to group >>> diverse objects. >> Please provide a technical description of "disease" please, because it's >> hard to do anything constructive with a statement like that. Like it or >> not, there are very big installations out there using NIS or RFC2307 and >> netgroups. If netgroups have been built into the way a corporation >> works, they'll possibly never be extracted. Embrace and extend (without >> the extinguish) if you'd like to bring those corporations with you and >> make improvements for everyone. Ignore them, and you get IPv6 all over >> again. I have taken netgroups and tried to take the "disease" out of >> them, while providing a clear migration path, but was it the same >> disease you were suffering? I don't know. Perhaps. More detail please. > Well the definition of netgroups simply makes little sense as it is in > NIS and RFC2307. The fact you have triplets but then only 2 parameters > at a time can be effectively used at once makes little sense and keeping > that representation simply maintains a bad data representation model and > keeps legitimizing it instead of fading it off. So this is why I've changed that. I've slightly redefined the meaning of the "domain" component in the triplet, and I'm defining netgroup members using two multi-valued attributes: netgroupHost and netgroupUser, rather than by a triplet. The domain component can optionally be used with either of those two attributes, and has a more useful meaning when applied. Take a closer look at draft-bannister-dbis-netgroup-01 again. >>>> A lot of the data elements and behaviors that the DBIS spec defines appear to >>>> be client-implementation-specific details. It seems to me their definition is >>>> inappropriate in (outside the scope of) a universally accessible distributed >>>> data context. >>> Same concerns here. >> As before, I'm not sure I understand what you mean. Please provide >> specific examples. > It looks like you are trying to build a glorified NIS, trying to follow > closely the way information is stored in files, but why ? > I do understand quite well the need for compatibility on the client, esp > with nsswitch interfaces, but that doesn't mean the best representation > in the directory is a straight copy, which is unfortunately what the > NIS/RFC2307 schema extenders did. > > What I mean, and suspect Howard may mean too, is that what should be > done is to provide the objects and attributes that matter to identity > management today, and only as a second layer explain how a client can > map those attributes to the legacy NIS concepts for clients that need to > serve that representation internally through its legacy interfaces. > > This is what I ave tried to do in the FreeIPA project for example, > although within the limits of what we could do many years ago when we > started, and only later we provided a compatibility tree that provides a > view of the data to make legacy clients happy, performing whatever > transformations are necessary to make them work, but not binding the > directory model to the legacy objects and attributes. So the problem here is that I wanted a solution we can use right now, today, and with minimal pain. You'll see from some of my description above that it's actually very easy to swap a client from nss_ldap to nss_dbis to gain lots of benefits. Changing the data model considerably makes it a lot more difficult to migrate from one solution to another, and large corporations obviously want to minimise the amount of big change going on, as large changes are prone to error. Migrating to DBIS involves a small number of steps which are all easily reversed. Up-take depends on ease of migration, if you want a solution to be used you have to consider backwards compatibility, otherwise like I said before, you end up with IPv6 (which despite being invented in the 1990s I have personally yet to see any of my clients making any use of it). I'm not someone who likes to design something "academically perfect" if no one besides academics are going to use it. >> CRYPT is a throwback to RFC2307bis and provides a place to start. That's >> why these are drafts, because they are a work in progress. I need to >> support old clients as well as new clients, possibly old clients that >> cannot be upgraded. > Old clients that can't be updated can't make any use of new schema nor > follow it anyway, so I fail to see the point to cater for those clients > in this schema. I am not saying you shouldn't make allowances to > *optionally* support exposing those hashes for compatibility purposes, > but it should be clear it is an option and there should be language in > the security considerations about how to properly limit exposure of such > hashes through ACI or other configuration etc... I agree. I really dislike having to support CRYPT. If I could get rid of it completely I would. But I would only get rid of it completely if I could still guarantee a smooth migration from one system to another. I don't see how that is possible. You're going to force 10,000+ users to change their passwords? Ok, users might not be such an issue because they are probably being forced to change their passwords every 90 days anyway. But service accounts, that's very difficult. I have to support CRYPT because I don't want a migration to DBIS forcing passwords to be changed. However, I entirely agree that we should give people as much help as possible to migrate to a more secure password scheme, and should strongly recommend it. If it's really easy to do, then it'll be a no-brainer. > >> Backwards compatibility is important. > The only way to be backward compatible at the LDAP level is to maintain > all the problems of RFC2307, which I would rather see left behind. Indeed. But as you'll see from my earlier points, you can use the RFC2307 schema with a DBIS client, and that can be a very useful stepping stone in moving on to a better schema. > >> If DBIS doesn't support CRYPT, how do I support the old clients? > Through a new PAM module ? After all if you can't even put a new pam > module on those client syou most probably can't put a new nsswitch > client either so the new schema will not be used at all. I think I've covered CRYPT already. >> Suggestions welcomed. > The way I solved it in most cases is by using pam_krb5 (or equivalents), > ie move auth completely way from LDAP for those clients. Service accounts. Don't want to force password changes. Discussed this already above. >> Now I was considering implementing pseudo NIS servers that >> act as a gateway for NIS clients that can't be upgraded, > We've done this too in FreeIPA (see slapi-nis directory module), because > you have no choice after all, if you need to serve legacy clients you > are better off providing a gateway, so you do not have to touch those > clients at all, except when it is finally time to decommission them and > then you can flip a single switch and throw away all the compatibility > garbage you were forced to provide. Meanwhile the main DIT is free(er) > to evolve. Fine if migration occurs once and once only. Large corporations buy companies. Mergers & acquisitions mean that your data will be polluted again. Rather than making each and every merger painful, with DBIS you have the flexibility to plug-in new data, even though it doesn't comply with the standards you prefer, and get using it straight away. Then you can perform migrations under the covers in your own time without senior management breathing down your neck asking you when they can finally kill the legacy network links or legacy infrastructure because it's costing them lots of money to maintain it. > >> but the PAM >> modules on the old clients are going to expect passwords in CRYPT format >> I assume? > Well, the point of the "Pluggable Authentication Module" system, > usually, is that you can plug new modules. I do understand there may be > resistance doing that on some old systems, but you need to draw a line > at some point. Why draw a line? We don't need to draw a line. Old NIS clients can use DBIS if you point them at a NIS gateway server. No changes required at all on the NIS client. Old infrastructure can continue to rot for a few more years. Sometimes we have no choice. Senior management says "jump" and we have to jump. "These 100 hosts are critical to the running of this bank and must NOT be touched under any circumstances". Oh and also "decommission those old NIS servers". DBIS with a NIS gateway allows us to do both. Prior to DBIS, we could not meet both of these requirements. > >> I had yet to prove this in a lab environment, but until now I >> assumed that CRYPT would have to be the lowest common denominator, I'd >> have to support it. Better authentication schemes can be added as and >> when I found the time to further explore the options. > Exposing hashes should be a last resort for compatibility reasons only > and should be disabled by default with appropriate ACIs. I don't suggest DBIS makes any mention of ACIs. That's up to local rules & procedures, not something that could possibly be standardised. > My point of view is that using LDAP binds SHOULD be mandated for > authentication for any new client following any new schema, and exposing > hashes MUST be disabled by default, and explicitly enabled by admins > that needs backwards compatibility. We need to move up the security bar, > and you do that only with appropriate defaults, and new IETF work should > reflect that IMHO. > > Simo. > > > I don't think LDAP binds can be mandated, we can only strongly recommend it. Given the migration path I have already described, I find it highly unlikely that people will be able to move to LDAP binds and move off CRYPT immediately, I would rather encourage them to get onto DBIS first and then gently steer them down a more secure route afterwards. To be honest, people can make up their own minds about security, we don't have to make their minds up for them. We offer them the tools and the options, the interoperability, and they decide how secure they want to be. Both of the clients I mentioned earlier, with 7,000 hosts and 36,000 hosts respectively, used Kerberos authentication with RFC2307bis anyway. So they had already elected a stronger password scheme. Best regards, Mark. From dbis@proseconsulting.co.uk Wed Jan 8 13:15:34 2014 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 1BC7F1A1DFA for ; 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 ; 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 ; 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 ) 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 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. From dbis@proseconsulting.co.uk Wed Jan 8 13:26:03 2014 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 271051A1F7A for ; Wed, 8 Jan 2014 13:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 P7UnpZULSZvc for ; Wed, 8 Jan 2014 13:26:02 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 424171A1F1A for ; Wed, 8 Jan 2014 13:26:02 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W10dM-0005ip-KO; Wed, 08 Jan 2014 21:25:52 +0000 Message-ID: <52CDC249.8050407@proseconsulting.co.uk> Date: Wed, 08 Jan 2014 21:25:29 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= , ldapext@ietf.org References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> In-Reply-To: <52CD9F94.2090707@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 21:26:03 -0000 On 08/01/2014 18:57, Michael Ströder wrote: > Arthur de Jong wrote: >> 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. > Using DNs allows to implement server-side access control. I'm not a friend of > letting client-side demons enforce the access control because if a machine got > hacked the attacker can find out more about the infrastructure. > > Ciao, Michael. > Hi Michael, Please will you give me a more solid example of what you are referring to re access control? What is it exactly you think you'd like to do with regards to group membership and server-side access control? Thanks, Mark. From michael@stroeder.com Thu Jan 9 07:56:00 2014 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 0706C1AD8D5 for ; Thu, 9 Jan 2014 07:56:00 -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 ObpuFXdY71L3 for ; Thu, 9 Jan 2014 07:55:58 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id BE6061ACCE2 for ; Thu, 9 Jan 2014 07:55:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id ADB5160777; Thu, 9 Jan 2014 16:55:45 +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 vSvUGA84xCTy; Thu, 9 Jan 2014 16:55:37 +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 7EACF60702; Thu, 9 Jan 2014 15:55:36 +0000 (UTC) Message-ID: <52CEB72F.9050000@stroeder.com> Date: Thu, 09 Jan 2014 15:50:23 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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 , 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> In-Reply-To: <52CDB3FC.2000205@proseconsulting.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020301070902040308090700" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:56:00 -0000 This is a cryptographically signed message in MIME format. --------------ms020301070902040308090700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > I don't personally like the idea > of having per-user shadow attributes, however some might see it as a fe= ature > and there may be some edge cases where this is exactly what is required= =2E AFAICS today nobody is seriously using LDAP with shadow attributes anymor= e. > draft-behera-ldap-password-policy-10 is already widely deployed, you sa= y?=20 > Then it must go higher up in my reading list. Yes, it's the only standard considered widely deployed. You have to know = it. > Indeed, I agree, as stated earlier on I would whole-heartedly recommend= > against having user-specific policy settings. However, providing the f= acility > 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 decid= e whether DBIS is just an improvement for 1. or a real innvotation for 2. Ciao, Michael. --------------ms020301070902040308090700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MTQ1MDIzWjAj BgkqhkiG9w0BCQQxFgQUTcPvhqc1b2uG+hn+tw95o4XyONgwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAIFQtX/vlO92aPAznBMNozCcbMQ2v7sdm d/6Uz2bKU1Ixyh7TKyiNqZ4O6ziU9c+/63T3XnVRD6BQsW1n5naNhxNOTRXqQF/h/9NOZrF2 1Y3FhzTieu2Y7EwZU4Fk0FWQYuPkLyvhGaDjrKb2hSpVSZ1woCUBjHHP26hmrQJ+vTEb7f42 wpdFYM4nDWDI+zNiFeNAXrXc2JmGGPQ/w8d6Mz9iv5FlagSwgQZMrUMMo/QMeA4SzpSkjgWc SVY8mNPwTec1X+qnUeSuGntXdyFF5Loq2/VRKC0qFd+SGpE0juB4CWz9C+16oCrDUVx+ohsJ 6gDA98+h3nNFsXlLLpiCawAAAAAAAA== --------------ms020301070902040308090700-- From michael@stroeder.com Thu Jan 9 07:56:01 2014 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 4D4DD1ACCE2 for ; Thu, 9 Jan 2014 07:56:01 -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 0DshUVyrdlVH for ; Thu, 9 Jan 2014 07:55:59 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5578D1AD627 for ; Thu, 9 Jan 2014 07:55:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 39D4760775; Thu, 9 Jan 2014 16:55:49 +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 YU6vf5DUeo2J; Thu, 9 Jan 2014 16:55:39 +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 8154A60771; Thu, 9 Jan 2014 15:55:38 +0000 (UTC) Message-ID: <52CEBEAE.5090701@stroeder.com> Date: Thu, 09 Jan 2014 16:22:22 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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 References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> In-Reply-To: <52CDB6B2.2080406@proseconsulting.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040606010106030702000706" Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:56:01 -0000 This is a cryptographically signed message in MIME format. --------------ms040606010106030702000706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: >> Exposing hashes should be a last resort for compatibility reasons only= >> and should be disabled by default with appropriate ACIs. The problem with exposing a central {CRYPT} hash is that a central and si= ngle password will be compromised even though newer systems might be capable o= f using stronger authc mechs. Especially if you want to support old systems= you likely won't be able to use a stronger {CRYPT} hashing scheme. =3D> I'd avoid that mess completely and I won't support any schema encour= aging this. At least your drafts should contain big ALARM notes in the security= considerations section. > I don't suggest DBIS makes any mention of ACIs. That's up to local rul= es & > procedures, not something that could possibly be standardised. >> My point of view is that using LDAP binds SHOULD be mandated for >> authentication for any new client following any new schema, and exposi= ng >> hashes MUST be disabled by default, and explicitly enabled by admins >> that needs backwards compatibility. We need to move up the security ba= r, >> and you do that only with appropriate defaults, and new IETF work shou= ld >> reflect that IMHO. >> >> Simo. +1 to Simo's comment. > I don't think LDAP binds can be mandated, we can only strongly recommen= d it.=20 > Given the migration path I have already described, I find it highly unl= ikely > that people will be able to move to LDAP binds and move off CRYPT immed= iately, If your customers have old legacy systems which they won't change at all = then simply let them run them in a isolated environment with all the old cruft= around they need for those systems. Sooner or later they have to migrate anyway because systems are running out-of-service (e.g. will not receive security updates anymore). IMO any new standard should focus on getting the near future right. Ciao, Michael. --------------ms040606010106030702000706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MTUyMjIyWjAj BgkqhkiG9w0BCQQxFgQUbT4bibo8zWvQOgGd7guSdlgcOaAwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAkkrtJVDjwGFnx0Hq5zRdcOaynl13I30p 19Pwbuah2uiH7mC2TRvBoXyv3tOAsd5MUkOLY0SPhIbia6TzPSOVwqBu70v4UO5yZ0f21vBY wTXYcZauMSpABtibTAIIR1Y+gLC/074llzq9OTVVXPPIWmwn2KEzI4cmuKUJMFgy2EvjKUEr TAW4Y/k1MkG9OTeSREJqATzS/zwP34qOpj67cofX+BY31kGuX5Q+x2shSjc5SzgpqsS18ooV wjTLvYOoOEh+0kFA/hn3f04DOzlG2d4suB0milPjvCWeb4J0r2VbLgCUnvDpRORLcsd1tHGQ ZMwpTXJdR9JiWPz1sJvEBQAAAAAAAA== --------------ms040606010106030702000706-- From michael@stroeder.com Thu Jan 9 07:56:11 2014 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 24F8F1AE413 for ; Thu, 9 Jan 2014 07:56:11 -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 BIwLhPrCYBt8 for ; Thu, 9 Jan 2014 07:56:09 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAB21AE412 for ; Thu, 9 Jan 2014 07:56:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id DAAF360771; Thu, 9 Jan 2014 16:55:58 +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 60Z-ycNNeuxu; Thu, 9 Jan 2014 16:55:49 +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 9808B60776; Thu, 9 Jan 2014 15:55:42 +0000 (UTC) Message-ID: <52CEC1DC.6030907@stroeder.com> Date: Thu, 09 Jan 2014 16:35:56 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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 , ldapext@ietf.org References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> In-Reply-To: <52CDC249.8050407@proseconsulting.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020909030708050209030601" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:56:11 -0000 This is a cryptographically signed message in MIME format. --------------ms020909030708050209030601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > On 08/01/2014 18:57, Michael Str=F6der wrote: >> Arthur de Jong wrote: >>> 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 implementati= on >>> 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 lo= t >>> of search operations to get complete data. >> Using DNs allows to implement server-side access control. I'm not a fr= iend of >> letting client-side demons enforce the access control because if a mac= hine got >> hacked the attacker can find out more about the infrastructure. >=20 > Please will you give me a more solid example of what you are referring = to re > access control? What is it exactly you think you'd like to do with reg= ards to > group membership and server-side access control? If the client system *individually* binds to the LDAP server you can impl= ement server-side access control in the LDAP server. During the last weeks I de= fined a schema and OpenLDAP ACLs for such a deployment. Nothing to publish yet = since this is done for a customer. Similar to what Simo described for IPA I use server groups (IPA host grou= ps) with rights assigned to user groups. In opposite to all other implementations all clients MUST individually bi= nd to the LDAP server and server-side ACLs limit access to posixAccount, posixG= roup, server group and sudoRole entries. I have to clarify if I'm allowed to disclose further details about this w= hich will take a while. Ciao, Michael. --------------ms020909030708050209030601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MTUzNTU2WjAj BgkqhkiG9w0BCQQxFgQU/f8zdDf5Z8Nur1rJX2RGOr167QkwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAdCTIrO2fWDBWnP+oqA+6VsfvaTxjKL4G IuRj2lknYDWBwzfY/Hq46PoZQgWMQ6LyNA69rxc/JXtNV2TWLXZvv18Etf/QNPUm7JrnyMt/ XLKgnclBzn+tqxFWL2pUHc1vvmJPWZ19p4FssfWF2l6EDcG+UDOlOaC89zvQmtNfgNieArOB rGipmcej6pWhjVY9kcD2YT/9GlgfT+Ap5VrwA1vjAGHhzZD12rZGz6Loj5K2wpu32PCV0fkG wKEPYFPLBEWWBiNmqIKAzTzshOztdVRDm5XKfM3YnRnS0/40yA4wHgoCeH8yKfLibpVHnJqq UzfMLFCXekBR6oPa9zWLBgAAAAAAAA== --------------ms020909030708050209030601-- From michael@stroeder.com Thu Jan 9 07:56:17 2014 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 8D9CD1AE42A for ; Thu, 9 Jan 2014 07:56:17 -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 3Y-AF2JMviUS for ; Thu, 9 Jan 2014 07:56:11 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id A666F1AE417 for ; Thu, 9 Jan 2014 07:56:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id AEEC16076E; Thu, 9 Jan 2014 16:56:00 +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 iyHrN2CXsWv1; Thu, 9 Jan 2014 16:55:52 +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 A58726076D; Thu, 9 Jan 2014 15:55:44 +0000 (UTC) Message-ID: <52CEC4D5.1070703@stroeder.com> Date: Thu, 09 Jan 2014 16:48:37 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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 , ldapext@ietf.org References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> In-Reply-To: <52CDBFD2.10905@proseconsulting.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040401000806020808020206" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:56:17 -0000 This is a cryptographically signed message in MIME format. --------------ms040401000806020808020206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > Yes as you'll see from my recent reply to Simo, the case sensitivity is= sue was > one of the problems I faced at a large installation, This could be easily solved with RFC2307bis. Or not? In my deployments I simply define additional (OpenLDAP) constraints for t= hose attributes (e.g. to enforce lower-case 'uid' values). IMHO only re-defining the matching rules does not fully solve the case pr= oblem anyway. Restricting to lower-case attribute values helps better. > It seemed quite strange to me that > RFC2307 should have differed like this from NIS in the first place. We all agree that RFC 2307 - even though widely deployed - has serious is= sues. > Yes this was another aspect I wanted to simplify. RFC2307bis does not = make it > easy to express group membership. What does "express group membership" mean exactly? > Nested groups are very important especially in large enterprises, and r= eally > do assist with data management. I am always getting told this but I have strong doubts about nested group= s. > Yes we'll get more search operations, but I > don't think this will be a problem. I should be able to prove this wil= l work > in my reference implementation. Resolving nested group membership is a big performance cost. I can see th= is with a MS Sharepoint installation working with a OpenLDAP server. Sharepo= int sends many search requests even though nested groups are not used in this= deployment. Also nested groups are a pain if you want to report all effective user ri= ghts to auditors (which is something banks have to do at least once per year).= In this context even maintaining the group membership does not look that sim= ple anymore. Ciao, Michael. --------------ms040401000806020808020206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MTU0ODM3WjAj BgkqhkiG9w0BCQQxFgQUaMX+yshy5c29iwFUf4awoI76zTwwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAejxUu/RSLuSNj/1nAWAhktR1sOQxzf6x ZPOJp1uaJDvJl6NpVadA3eC12Dj9D0CIPxUTneVNThHVFNZ88W4xXUEgF2POGLGOeuuSQawd KIlIen/Hvh428dkqpLq5ipKfiLnEtZjYLONdFxUfRMtW3YZr/+E7lOpreefaPLjHFvPmRli6 gCUTgLFdi7c93VxljxVbyPiSvglysCXhkktPkwSh7itwBV+xQBOBTooUedZ2x+hmzsEKc9oW A+Qlz7YfE/rOQR9LXGLbCaVIIkreW9R001xeIrzOZBXDFlKqP09bcz29qDqswX+8BkJ5KlTQ 2Gw2x4IntDesf3cVTZf6xwAAAAAAAA== --------------ms040401000806020808020206-- From ludovic.poitou@gmail.com Thu Jan 9 08:02:50 2014 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 823CC1AE3FD for ; Thu, 9 Jan 2014 08:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 OFW6J2CSwXSV for ; Thu, 9 Jan 2014 08:02:48 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2F71AE3B1 for ; Thu, 9 Jan 2014 08:02:47 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq4so6849186wib.5 for ; Thu, 09 Jan 2014 08:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=6mLko67sEHJuWQryyz+j9rdNbz9JXluD4e3S9b/qgiA=; b=lZ4ekYmhZkhdV1WaOYNuXWpNgdSCl8ZbiCP/HFSYbGw92BOweHOI2Pb8EBdavxPJN/ bL+AZlQgZ8TlgM9BGkNQgvl5qmNDxCL3560yz3lRWiEiwEw/Wm+6a7d5z+yT1awHTbko nfLx6hE8krNeEKLcg2w5O9HnnEGmW4Bi7MilU7gUlMr4t7cNm+XawdkrgLMV/2jk7X83 EgeR9C3YrvD46gGSM12rAKdfJ4fsl11WUbK7ANOCr0isFsqWS1SJD3lL6nrbJriZZJvA rypoazIa5RLQUPkiE/xQjGeJqqp4o5q6QfYWUp0r5LvMNPIXTycZu/Sm9MdaiBtEthGY 3p9A== X-Received: by 10.194.161.136 with SMTP id xs8mr3730035wjb.56.1389283357445; Thu, 09 Jan 2014 08:02:37 -0800 (PST) Received: from lpmac.local ([46.218.40.139]) by mx.google.com with ESMTPSA id md9sm14680125wic.1.2014.01.09.08.02.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jan 2014 08:02:36 -0800 (PST) Message-ID: <52CEC81A.9080207@gmail.com> Date: Thu, 09 Jan 2014 17:02:34 +0100 From: Ludovic Poitou User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= 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> In-Reply-To: <52CEB72F.9050000@stroeder.com> Content-Type: multipart/alternative; boundary="------------020506090202080309020708" Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 16:02:50 -0000 This is a multi-part message in MIME format. --------------020506090202080309020708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit > Michael Ströder > January 9, 2014 at 15:50 > 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. > >> 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. Actually, I'm not sure version 10 is the version that is widely implemented. Version 9 is the one that was implemented in Sun DS, OpenDS, OpenDJ, Oracle servers... Ludo > >> 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. > > Ciao, Michael. > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > Mark R Bannister > January 8, 2014 at 21:24 > On 06/01/2014 21:57, Howard Chu wrote: >> Mark R Bannister wrote: >>> Do you have any more alarming problems that can be turned into simple >>> requests? >> >> Just read thru >> http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and again >> there's a lot of redundant work here, this time in regards to >> http://tools.ietf.org/html/draft-behera-ldap-password-policy-10 > > Originally I had shadow attributes mingled in with the user and group > document, as it is in RFC2307, however I decided quite late on in fact > that it would be better as a separate bolt-on option. So it went into > its own draft. I thought I'd already made it clear in the drafts that > password policies are best handled a separate way, however, DBIS would > be incomplete if it did not support the old NIS way of doing it as > well. 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. So, what's > the harm in supporting it? As long as I make it clear that it is not > recommended, which is the intention of the following paragraph in > section 1.1.1: > > It is RECOMMENDED that password policies are managed using native > features in the LDAP Directory Server if available, or using > Pluggable Authentication Modules [PAM] to provide consistency of > security and centralised administration. Whether or not the shadow > attributes are used by the policy will vary between implementations. > > Perhaps we can work this paragraph better. I must admit I haven't > seen draft-behera-ldap-password-policy-10 so I shall add that to my > reading list. > >> >> The obvious issue is collisions in some attribute descriptors with >> the ppolicy spec, which is already widely deployed. > > draft-behera-ldap-password-policy-10 is already widely deployed, you > say? Then it must go higher up in my reading list. > >> >> More problematic is the data model itself, again. Storing the actual >> policy settings in the user entries will be unmanageable for any >> moderately large sized user population. This is one reason why >> draft-behera uses dedicated policy objects. It is the client side >> DUA's job to adapt the universal data store to the local host's >> security implementation. And we already have >> pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, >> so I don't see much value in defining yet another new broken data >> model that has no existing client support. > > 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. > >> >> As much as you claim to have read and absorbed the prior work in this >> area, it really appears that you have ignored most of it. > > Appearances can be deceptive. If you ask me for a reason why I did > something in a particular way, you'll realise I have actually put a > lot of thought into the entire design. I haven't ignored RFC2307 nor > RFC2307bis, nor indeed any of the RFCs I make reference to in my > drafts. I was unaware of draft-behera-ldap-password-policy-10 so > thank you for pointing this out. I suspect it will not make a big > difference short of perhaps becoming the recommended approach. I'll > review it and let you know what I think afterwards. > > Best regards, > Mark. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > Howard Chu > January 6, 2014 at 22:57 > > > Just read thru > http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and again > there's a lot of redundant work here, this time in regards to > http://tools.ietf.org/html/draft-behera-ldap-password-policy-10 > > The obvious issue is collisions in some attribute descriptors with the > ppolicy spec, which is already widely deployed. > > More problematic is the data model itself, again. Storing the actual > policy settings in the user entries will be unmanageable for any > moderately large sized user population. This is one reason why > draft-behera uses dedicated policy objects. It is the client side > DUA's job to adapt the universal data store to the local host's > security implementation. And we already have > pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so > I don't see much value in defining yet another new broken data model > that has no existing client support. > > As much as you claim to have read and absorbed the prior work in this > area, it really appears that you have ignored most of it. > > Mark R Bannister > January 6, 2014 at 22:35 > > > Ok, so rather than being "alarmed" you could have just said, "please > would you consider seconds instead of days for some of the shadow > attributes". This is a small request, and very easy to put into DBIS, > and by no means a "fundamental problem". Let's put comments into > their right perspective. > > Do you have any more alarming problems that can be turned into simple > requests? > > Thanks :-) > > p.s. I'm being playful, no rudeness intended. > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > Howard Chu > January 6, 2014 at 22:19 > Mark R Bannister wrote: >> >> On 06/01/2014 17:40, Howard Chu wrote: >>> Mark R Bannister wrote: >>>> In August this year, I submitted some new IETF drafts with the intent >>>> that they would replace NIS and RFC2307. It introduces Directory >>>> Based >>>> Information Services (DBIS). >>>> >>> Yes, this is the correct list. >> >> First, Howard let me apologise up-front for not approaching you about >> this sooner. I appreciate, as the editor of RFC2307bis-02 that it must >> come as quite a shock to you to see a new set of Internet Drafts >> released that could be seen as a direct challenge to your work, and I >> quite understand your defensive posture. However, I launched this >> initiative as a direct result of working with large corporations (mainly >> banks) who were using RFC2307 extensively across big Linux and Solaris >> installations (between 10,000 to 40,000 hosts) and facing numerous >> pain-points which needed to be addressed. It was purely technically >> motivated, and I did not mean to cause any offence. I am completely >> open to ideas and suggestions to further improve DBIS, and I think if >> you dig deep into these drafts and ask me detailed questions you'll >> realise that a lot of time and thought has gone into every decision I >> have made thus far, including preserving whatever makes sense to >> preserve from the RFC2307 heritage. > > Nothing defensive here at all. I have nothing personally invested in > one spec or another. As I stated before, it's a mistake to embed > Solaris-specific semantics into a supposedly universal spec. My > response is purely technical, since technical details are my only > concern. > >>> I must say I'm alarmed at seeing a new proposal that is primarily >>> based on NIS-compatible attribute values. This is exactly the same >>> fundamental problem in the original RFC2307 which made it less than >>> useful for non-Solaris-based OSs like AIX and HPUX. This is the same >>> flaw that I attempted to correct in my updated draft >>> http://tools.ietf.org/html/draft-howard-rfc2307bis-02 >> >> Please would you give me some specific examples of what you believe is >> less than useful for AIX and HP-UX, and how you corrected these in >> RFC2307bis-02. Forgive me but I am coming from a Linux and Solaris >> perspective. > > This is all pretty old ground. > http://www.openldap.org/lists/openldap-software/200310/msg00138.html > --------------020506090202080309020708 Content-Type: multipart/related; boundary="------------080801040408070502040103" --------------080801040408070502040103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

January 9, 2014 at 15:50 
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.


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.

Actually, I'm not sure version 10 is the version that is widely implemented. Version 9 is the one that was implemented in Sun DS, OpenDS, OpenDJ, Oracle servers...

Ludo


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.

Ciao, Michael.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
January 8, 2014 at 21:24
On 06/01/2014 21:57, Howard Chu wrote:
Mark R Bannister wrote:
Do you have any more alarming problems that can be turned into simple
requests?

Just read thru http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and again there's a lot of redundant work here, this time in regards to http://tools.ietf.org/html/draft-behera-ldap-password-policy-10

Originally I had shadow attributes mingled in with the user and group document, as it is in RFC2307, however I decided quite late on in fact that it would be better as a separate bolt-on option.  So it went into its own draft.  I thought I'd already made it clear in the drafts that password policies are best handled a separate way, however, DBIS would be incomplete if it did not support the old NIS way of doing it as well.  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.  So, what's the harm in supporting it?  As long as I make it clear that it is not recommended, which is the intention of the following paragraph in section 1.1.1:

   It is RECOMMENDED that password policies are managed using native
   features in the LDAP Directory Server if available, or using
   Pluggable Authentication Modules [PAM] to provide consistency of
   security and centralised administration.  Whether or not the shadow
   attributes are used by the policy will vary between implementations.

Perhaps we can work this paragraph better.  I must admit I haven't seen draft-behera-ldap-password-policy-10 so I shall add that to my reading list.


The obvious issue is collisions in some attribute descriptors with the ppolicy spec, which is already widely deployed.

draft-behera-ldap-password-policy-10 is already widely deployed, you say?  Then it must go higher up in my reading list.


More problematic is the data model itself, again. Storing the actual policy settings in the user entries will be unmanageable for any moderately large sized user population. This is one reason why draft-behera uses dedicated policy objects. It is the client side DUA's job to adapt the universal data store to the local host's security implementation. And we already have pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so I don't see much value in defining yet another new broken data model that has no existing client support.

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.


As much as you claim to have read and absorbed the prior work in this area, it really appears that you have ignored most of it.

Appearances can be deceptive.  If you ask me for a reason why I did something in a particular way, you'll realise I have actually put a lot of thought into the entire design.  I haven't ignored RFC2307 nor RFC2307bis, nor indeed any of the RFCs I make reference to in my drafts.  I was unaware of draft-behera-ldap-password-policy-10 so thank you for pointing this out.  I suspect it will not make a big difference short of perhaps becoming the recommended approach.  I'll review it and let you know what I think afterwards.

Best regards,
Mark.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
January 6, 2014 at 22:57


Just read thru http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and again there's a lot of redundant work here, this time in regards to http://tools.ietf.org/html/draft-behera-ldap-password-policy-10

The obvious issue is collisions in some attribute descriptors with the ppolicy spec, which is already widely deployed.

More problematic is the data model itself, again. Storing the actual policy settings in the user entries will be unmanageable for any moderately large sized user population. This is one reason why draft-behera uses dedicated policy objects. It is the client side DUA's job to adapt the universal data store to the local host's security implementation. And we already have pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so I don't see much value in defining yet another new broken data model that has no existing client support.

As much as you claim to have read and absorbed the prior work in this area, it really appears that you have ignored most of it.

January 6, 2014 at 22:35


Ok, so rather than being "alarmed" you could have just said, "please would you consider seconds instead of days for some of the shadow attributes".  This is a small request, and very easy to put into DBIS, and by no means a "fundamental problem".  Let's put comments into their right perspective.

Do you have any more alarming problems that can be turned into simple requests?

Thanks :-)

p.s. I'm being playful, no rudeness intended.
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
January 6, 2014 at 22:19
Mark R Bannister wrote:

On 06/01/2014 17:40, Howard Chu wrote:
Mark R Bannister wrote:
In August this year, I submitted some new IETF drafts with the intent
that they would replace NIS and RFC2307.  It introduces Directory Based
Information Services (DBIS).
<snip>
Yes, this is the correct list.

First, Howard let me apologise up-front for not approaching you about
this sooner.  I appreciate, as the editor of RFC2307bis-02 that it must
come as quite a shock to you to see a new set of Internet Drafts
released that could be seen as a direct challenge to your work, and I
quite understand your defensive posture.  However, I launched this
initiative as a direct result of working with large corporations (mainly
banks) who were using RFC2307 extensively across big Linux and Solaris
installations (between 10,000 to 40,000 hosts) and facing numerous
pain-points which needed to be addressed.  It was purely technically
motivated, and I did not mean to cause any offence.  I am completely
open to ideas and suggestions to further improve DBIS, and I think if
you dig deep into these drafts and ask me detailed questions you'll
realise that a lot of time and thought has gone into every decision I
have made thus far, including preserving whatever makes sense to
preserve from the RFC2307 heritage.

Nothing defensive here at all. I have nothing personally invested in one spec or another. As I stated before, it's a mistake to embed Solaris-specific semantics into a supposedly universal spec. My response is purely technical, since technical details are my only concern.

I must say I'm alarmed at seeing a new proposal that is primarily
based on NIS-compatible attribute values. This is exactly the same
fundamental problem in the original RFC2307 which made it less than
useful for non-Solaris-based OSs like AIX and HPUX. This is the same
flaw that I attempted to correct in my updated draft
http://tools.ietf.org/html/draft-howard-rfc2307bis-02

Please would you give me some specific examples of what you believe is
less than useful for AIX and HP-UX, and how you corrected these in
RFC2307bis-02.  Forgive me but I am coming from a Linux and Solaris
perspective.

This is all pretty old ground. http://www.openldap.org/lists/openldap-software/200310/msg00138.html

--------------080801040408070502040103 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------080801040408070502040103 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD6Y+I3jC28EfBzWfilfaVY6lqVpoyXyG5t kka4u5I12BiQScyMOPTgY4r5mDdWvyt6Hqtckbo8x8A/EHSbTwpo2sw6NNq1/qccN7d3Nxao /wBrZwu9dpwiYLHCoo2++K+frZhioYq0muVNpryPqIZXhquE54p3aTT89z2/XNE0WeTT57XS 7BVeVXSSO1jRwCAQysBlT3BBBFes6suaJ824KzPH/wDhdXxN/wChyvPyT/4mu729Xuc/s4dj n/2vvH+i6J+zBBoLywTajqljYeSq3YR4HVEZX2rliQQCBwPejCU/aYhhVrRhCyep88eCvi/F YfDFdc165026fRrUZjdHZ5LrcuyF0XAjWTBKyL3yCPvY5pZMpYmejs/T77+XY9n+25rCQhFq /wA/y21PtD4SfGXwr8XPDMUmiCe2v9DFvDqVpPEU8lmT5WRujRsFO09cDkCliMO6Mo3PNpVV UTPn3/hIrL/n+t/+/o/xrr9mzDmXc+dT4tvr2GPT9ftLi3tIfLtZ4biMqIXiQJyrDIZWVgc9 yRxXpxpRi3y7ngTpyjr1OS1yKKHTpVby/st5exzyoknz+XHE23Cjnq5xnjjrxXXF6HTSfu6n oPw9+OGm+C7/AEjxJo1naxW1sscOo2k22N5dhIxcBAdyFcEPgkNgkHAriq4Lmum3d6/8N2Ov 2l3GS6f1qbn/AAsnxp/0RXxN/wB+n/8AjVT9Ufc09uXP+ChX/JVNY/7CL/8AoqKlhv8AeJl4 z+BS+Z8rap/x6z/7sX8jXoLdHmdiP4af8lZ8H/8AYd07/wBKEqzVH7p0DP/Z --------------080801040408070502040103-- --------------020506090202080309020708-- From clem.oudot@gmail.com Thu Jan 9 08:26:43 2014 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 73A571AE454 for ; Thu, 9 Jan 2014 08:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.081 X-Spam-Level: X-Spam-Status: No, score=-0.081 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, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 WrIicvEKJ-Ld for ; Thu, 9 Jan 2014 08:26:42 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F15A11AE456 for ; Thu, 9 Jan 2014 08:26:41 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id b8so617151lan.32 for ; Thu, 09 Jan 2014 08:26:31 -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; bh=yo1nJHW7a0YUTgNlg2UGetFrQAkrN7w4btRPC3BkBV4=; b=b8VpZUuANmpNXbsOHXacC+73jnU2sw1utPB1zy1KImyuhc6aZUMZqsN3oJwmGJY0rw zGJQKDmef7o6uh+JZkTnm7PjX2+oruKbNK88QA5dKGbthZ/Lffb+y8U61DvLhMn2EjiZ QAYiLzkEWEIQGTJ08y4vl6UyhKQZvBuNziyymd4en6pFh0o11Fhkz4ahA3+VN/OvCi7W 63hGyhLNbFQUIM7t5yoaHyL+JC8kdeHGDU01yYxty0HevBCPrMmlHmzDmFn9qDD9cUUE JC5mz7iwKw7H1krrah9LmvVJjuGC53IwUnnL++sHQL3cbzhAYK6+2SKFvjF6Pyx3ZpvY pOSA== MIME-Version: 1.0 X-Received: by 10.152.28.230 with SMTP id e6mr1654908lah.3.1389284791711; Thu, 09 Jan 2014 08:26:31 -0800 (PST) Received: by 10.114.0.176 with HTTP; Thu, 9 Jan 2014 08:26:31 -0800 (PST) In-Reply-To: <52CEC81A.9080207@gmail.com> 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> <52CEC81A.9080207@gmail.com> Date: Thu, 9 Jan 2014 17:26:31 +0100 Message-ID: From: =?ISO-8859-1?Q?Cl=E9ment_OUDOT?= To: Ludovic Poitou Content-Type: multipart/related; boundary=089e0160b79a8093be04ef8c1258 Cc: ldapext@ietf.org, =?ISO-8859-1?Q?Michael_Str=F6der?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 16:26:43 -0000 --089e0160b79a8093be04ef8c1258 Content-Type: multipart/alternative; boundary=089e0160b79a8093bb04ef8c1257 --089e0160b79a8093bb04ef8c1257 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2014/1/9 Ludovic Poitou > > > Michael Str=F6der > January 9, 2014 at 15:50 > > Mark R Bannister wrote: > > I don't personally like the idea > of having per-user shadow attributes, however some might see it as a feat= ure > and there may be some edge cases where this is exactly what is required. > > AFAICS today nobody is seriously using LDAP with shadow attributes anymor= e. > > > 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. > > > Actually, I'm not sure version 10 is the version that is widely > implemented. Version 9 is the one that was implemented in Sun DS, OpenDS, > OpenDJ, Oracle servers... > And OpenLDAP. Seems RedHat (389) use it too, as it was implemented in the SUN DS code base used for this server. I think nobody implements version 10 yet. Cl=E9ment. --089e0160b79a8093bb04ef8c1257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2014/1/9 Ludovic Poitou <ludovic.poitou@gmail.com>


=20 January 9, 2014= =20 at 15:50
= 
Mark R Bannister wrote:

I don't personally like the idea
of having per-user shadow attributes, however some might see it as a featur=
e
and there may be some edge cases where this is exactly what is required.

AFAICS today nobody is seriously using LDAP with sh=
adow attributes anymore.


draft-behera-ldap-password-policy-10 i=
s already widely deployed, you say?=20
Then it must go higher up in my reading list.

Yes, it's the only standard considered widely d=
eployed. You have to know it.

Actually, I'm not sure version 10 is the version that is widely=20 implemented. Version 9 is the one that was implemented in Sun DS,=20 OpenDS, OpenDJ, Oracle servers...


And OpenLDAP. Seems RedHat (389) use it too, as it was implemented in = the SUN DS code base used for this server.

I think nobody implements= version 10 yet.

Cl=E9ment.
--089e0160b79a8093bb04ef8c1257-- --089e0160b79a8093be04ef8c1258 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f814b0e88a4c154d_0.0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --089e0160b79a8093be04ef8c1258-- From andrew.findlay@skills-1st.co.uk Thu Jan 9 09:43:35 2014 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 86C971AE521 for ; Thu, 9 Jan 2014 09:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 7-odjnDJRLNY for ; Thu, 9 Jan 2014 09:43:33 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFA21AE51F for ; Thu, 9 Jan 2014 09:43:33 -0800 (PST) Received: from 9.1.5.2.b.3.c.7.4.f.9.1.a.6.4.b.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:b46a:19f4:7c3b:2519] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W1Jda-0005s1-98; Thu, 09 Jan 2014 17:43:22 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1W1JdZ-0006Bm-RB; Thu, 09 Jan 2014 17:43:21 +0000 Date: Thu, 9 Jan 2014 17:43:21 +0000 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20140109174321.GV3938@slab.skills-1st.co.uk> References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52CEBEAE.5090701@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:43:35 -0000 On Thu, Jan 09, 2014 at 04:22:22PM +0100, Michael Ströder wrote: > Mark R Bannister wrote: > >> Exposing hashes should be a last resort for compatibility reasons only > >> and should be disabled by default with appropriate ACIs. Absolutely. You need the LDAP server to support the old-style hashes to allow for migrating data in, but exposing *any* form of hash outside your trusted LDAP servers is asking for trouble. Every LDAP-aware client system that I have worked with can use the bind operation as a means to validate passwords, so the only possible excuse for exporting hashes is temporary support of migrating systems. If you only allow the export of hashes that are actually needed by the old non-LDAP systems then at least you are not making matters worse than they were before the migration. > >> My point of view is that using LDAP binds SHOULD be mandated for > >> authentication for any new client following any new schema, and exposing > >> hashes MUST be disabled by default, and explicitly enabled by admins > >> that needs backwards compatibility. We need to move up the security bar, > >> and you do that only with appropriate defaults, and new IETF work should > >> reflect that IMHO. > >> > >> Simo. > > +1 to Simo's comment. Another +1. I find that showing people the crack-attempt rate tables on Hashcat's front page usually ups the priority for getting rid of old hashes... To see the data for Crypt-style hashes you need to go back in the archive a bit: http://web.archive.org/web/20130703144216/http://hashcat.net/oclhashcat-plus/ Comparing those figures (July 2013, based on software from January 2013) with todays is interesting too. The latest hardware they have tested boosts the crack-rate by another order of magnitude so traditional Unix-style crypt(3) hashes are probably testable at 600M attempts/sec, with plain MD5 now at 81000M and NTLM at 140000M... That means that *every possible* 8-character ASCII password can be tested against a file of NTLM hashes in 12 hours, or against Unix crypt in 117 days on a single PC. Real passwords are at least 1000 times weaker in practice. In terms of LDAP best practice what this means is: Store password data using a modern salted hash that was designed specifically for this purpose. Preferably choose one that allows the number of iterations to be increased in the future. [ I currently favour bcrypt ($2a$), falling back to sha512crypt ($6$) or md5crypt ($1$) if that is not available ] Use ACIs to prevent access to password storage fields. Use all good system-management practices to protect the LDAP database, the filesystem, the physical disks, and the backup tapes from being copied or stolen. Advise users to set much longer passwords than before. e.g. a 5-word Diceware password is about 1000 times better than the best possible 8-character ASCII password - and a lot easier to remember and to type! Passwords hashed with weak schemes may be imported as part of a migration process provided they are changed within some short period of time to be set by a sensible risk analysis. > > I don't think LDAP binds can be mandated, we can only strongly recommend it. > > Given the migration path I have already described, I find it highly unlikely > > that people will be able to move to LDAP binds and move off CRYPT immediately, > > If your customers have old legacy systems which they won't change at all then > simply let them run them in a isolated environment with all the old cruft > around they need for those systems. Sooner or later they have to migrate > anyway because systems are running out-of-service (e.g. will not receive > security updates anymore). I would be a bit more flexible than that. There are often advantages to loose coupling of the old system to the new one: reduced support effort, maybe even increased security as passwords actually do get changed, etc. There are risks though, and these need to be considered on a case-by-case basis. An obvious example here would be a system that stores an old Unix-crypt hash alongside a bcrypt one with both derived from the same data. The old hash is easily attacked and will expose the first 8 chars of the full password with very little effort, making it much easier to attack the full password in the bcrypt hash. > IMO any new standard should focus on getting the near future right. Yes, but that does have to include migrating stuff that is currently stuck in the technological past! Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From andrew.findlay@skills-1st.co.uk Thu Jan 9 10:09:04 2014 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 DE6671ADFF3 for ; Thu, 9 Jan 2014 10:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 IzanDi5ruZq2 for ; Thu, 9 Jan 2014 10:09:03 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id AB12D1AE078 for ; Thu, 9 Jan 2014 10:09:02 -0800 (PST) Received: from 9.1.5.2.b.3.c.7.4.f.9.1.a.6.4.b.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:b46a:19f4:7c3b:2519] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W1K2G-00063h-N5; Thu, 09 Jan 2014 18:08:52 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1W1K2F-0006Ca-Ub; Thu, 09 Jan 2014 18:08:51 +0000 Date: Thu, 9 Jan 2014 18:08:51 +0000 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20140109180851.GW3938@slab.skills-1st.co.uk> References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52CEC4D5.1070703@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:09:05 -0000 On Thu, Jan 09, 2014 at 04:48:37PM +0100, Michael Ströder wrote: > > Nested groups are very important especially in large enterprises, and really > > do assist with data management. > > I am always getting told this but I have strong doubts about nested groups. Groups are usually there to define permissions - the Authorisation part of the AAA triple. Allowing nested groups helps to decouple individual users from individual permissions. For example: The Helpdesk group contains a, b, c, d The SysManagers group contains e, f The PasswordRestKiosk group contains j, k, l, m The AccountProvisioning group contains p I can now write permission rules like: Members of Helpdesk, PasswordRestKiosk, AccountProvisioning may set user passwords Members of SysManagers may set system-account passwords Members of Helpdesk, AccountProvisioning may change user contact data where each of the rules is expressed as a group whose members are other groups. It is easy to explain such rules, and easy to maintain them as they are visibale as data in the LDAP tree. I think this is a lot better than maintaining flat groups like: UserPasswordSetGroup contains a, b, c, d, j, k, l, m, p SysPasswordResetGroup contains e, f UserContactModifyGroup contains a, b, c, d, p > > 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. > > Resolving nested group membership is a big performance cost. I can see this > with a MS Sharepoint installation working with a OpenLDAP server. Sharepoint > sends many search requests even though nested groups are not used in this > deployment. That is because there is no standard schema for nested groups, so there is no server-side support to make them efficient. [In fact many LDAP server implementations do define their own nesting schemes, but I don't think any of them are shared with other unrelated implementations.] You and I started trying to sort this out after the first LDAP conference, but the effort got bogged down. Maybe we should dust off the drafts and see if anything can be salvaged. > Also nested groups are a pain if you want to report all effective user rights > to auditors (which is something banks have to do at least once per year). In > this context even maintaining the group membership does not look that simple > anymore. I don't see that it adds much to the work. If the server supports nested groups then it is a single query; otherwise it is a series of derefs. (I am assuming a simple two-level nesting here as I can see many uses for that without making the rules too complex.) Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From michael@stroeder.com Thu Jan 9 12:13:30 2014 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 692F51AE19D for ; Thu, 9 Jan 2014 12:13:30 -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 cIgAWQ801Yle for ; Thu, 9 Jan 2014 12:13:25 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3671AE02E for ; Thu, 9 Jan 2014 12:13:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 7BF2D6078A; Thu, 9 Jan 2014 21:13:12 +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 FZysZiC628Zu; Thu, 9 Jan 2014 21:13:06 +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 BB17960702; Thu, 9 Jan 2014 20:13:05 +0000 (UTC) Message-ID: <52CEE58C.7060304@stroeder.com> Date: Thu, 09 Jan 2014 19:08:12 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 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: Simo References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <52CDA099.9070300@stroeder.com> <1389219912.27654.113.camel@pico.ipa.ssimo.org> In-Reply-To: <1389219912.27654.113.camel@pico.ipa.ssimo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000700000802000605070205" Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:13:30 -0000 This is a cryptographically signed message in MIME format. --------------ms000700000802000605070205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simo wrote: > The full schema definitions can be found here: > https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60base= v2.ldif Looked at the schema: I'm a bit confused by some object classes directly referencing MAY member= Of. 'memberOf' is normally an operational attribute also in 389 DS isn't it? Also I don't understand the rationale for object class nestedGroup SUP groupOfNames with memberOf. Regarding host groups: Can hosts be member in more than host group and if= yes, why? I've also considered that in my own schema but did not find a good r= eason to do so. Ciao, Michael. --------------ms000700000802000605070205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MTgwODEyWjAj BgkqhkiG9w0BCQQxFgQUhZs3DnXhZDgeQuNWRd5zg4HOTukwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAYXLUnfzL+IXghA0bVjbN9ReY14P/gl9i 6/82F2vWQMsSfhFv1l82ENHF4+j+dPeCAakelQZpplIllzuL7QYkcH1duIcpCWsRwXrECu1p MN1a3BAqhkwYcfieCtZYKZKXcPWdmKK84kyux81w8t7pI05ds+A5HQP6wpDBBfOQTnklqfSo Ucqpy46Hwd+kTCC0zpZHND/9L87Y2F3uyLO4jsy8cNHwNkIGvofJm+SIZnFiQGp6lOyTFQ8A Qr+GUJEV1ZR+KnwQY8If34g4HGY2l63HQMTpX+PuxTPZSF58bvSNhacCf/mdUTvJjVHCMBbv Vw5vcufeoigLKdrnho9OkQAAAAAAAA== --------------ms000700000802000605070205-- From michael@stroeder.com Thu Jan 9 12:36:31 2014 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 6CDEA1AE542 for ; Thu, 9 Jan 2014 12:36:31 -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 1-EDwf5SeZbx for ; Thu, 9 Jan 2014 12:36:29 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 09B7D1AE53A for ; Thu, 9 Jan 2014 12:36:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 9C06E6078D; Thu, 9 Jan 2014 21:36:18 +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 FdbbqafA8mmy; Thu, 9 Jan 2014 21:36:12 +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 1208060702; Thu, 9 Jan 2014 20:36:10 +0000 (UTC) Message-ID: <52CF0838.3060102@stroeder.com> Date: Thu, 09 Jan 2014 21:36:08 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 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: Simo References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <1389290636.27654.125.camel@pico.ipa.ssimo.org> In-Reply-To: <1389290636.27654.125.camel@pico.ipa.ssimo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050103080802040602040409" Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:36:31 -0000 This is a cryptographically signed message in MIME format. --------------ms050103080802040602040409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simo wrote: > On Thu, 2014-01-09 at 16:48 +0100, Michael Str=C3=B6der wrote: >> Mark R Bannister wrote: >>> 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, >> >> This could be easily solved with RFC2307bis. Or not? >> >> In my deployments I simply define additional (OpenLDAP) constraints fo= r those >> attributes (e.g. to enforce lower-case 'uid' values). >> >> IMHO only re-defining the matching rules does not fully solve the case= problem >> anyway. Restricting to lower-case attribute values helps better. >=20 >=20 > I'd go beyond this, supporting case-sensitive user names is actively > harmful for various reasons. >=20 > - Assuming users (and admins) should be able to distinguish based on > case is wrong, we naturally consider the strings 'Admin' and 'admin' to= > be the same thing. >=20 > - Some systems are case-preserving (meaning they'll show you back the > same case you entered, but are really case-insensitive and if you have > to interoperate with them you cannot assume Admin and amdin to be > different users, it could lead to serious security issues. >=20 > - If we are in the legacy game, there are still systems that will simpl= y > accept only all caps names, like ADMIN. In these cases what do you map > that to ? Admin ? admin? a third user called ADMIN ? >=20 > And there are many other examples where really being case sensitive > causes a lot more problem than it resolves. > Due to these problems what we did in FreeIPA is to always create users > in lower case and explicitly state we are case-preserving and > insensitive. It is the only reasonable compromise IMHO. So basically you're doing the same thing like I described above. >>> Nested groups are very important especially in large enterprises, and= really >>> do assist with data management. >> >> I am always getting told this but I have strong doubts about nested gr= oups. >=20 > Great value at least in IPA, we use them a lot to associate things like= > permissions to roles to groups and ultimately to users (All through > nesting each of these as groupsofnames). It does really make some > problems much easier to handle at the end of the process. Which problems are easier? Personally I'd definitely consider abusing groupOfNames for permissions bad schema design. >>> Yes we'll get more search operations, but I >>> don't think this will be a problem. I should be able to prove this w= ill work >>> in my reference implementation. >> >> Resolving nested group membership is a big performance cost. I can see= this >> with a MS Sharepoint installation working with a OpenLDAP server. Shar= epoint >> sends many search requests even though nested groups are not used in t= his >> deployment. >=20 > Performance issues with nested groups can easily be solved via caching > and the deref control though. But the deref control gives you only one level. Speaking of nested groups= in general people mean more than just two-level group memberships. Ciao, Michael. --------------ms050103080802040602040409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MjAzNjA4WjAj BgkqhkiG9w0BCQQxFgQUyZ3DxEb677T/DyX3qRtCffJLiPswbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAhMCCDL3lTKN4Xo+11Bfu/tNQD7mikLdl tTYt5J1/aRLRI/mepQsqlaHkSy/pu0SHVWlTGZAF7myr99ObV4so3ZKGo0arwCXk6xyq7BSt y3Tv7ClLgY9LnLuwrD8GcKS7L1SmPoT142OYgUG5qClTo1hXxOrlyEbSSNt0KySfJO+z+l9F Agw67xQ/0Y3peg9AqUQDe7CokoJrjoIuCrOqYoZT+iZkEW98umngcJCOsIdBslYiutGbmCLZ ymSJwdzEn387N85zIyDSbi641kJr5hG3D7zbm+8nkDjq8F+AeGa6B4OvmWyxohMcTtYrfD/i 0RI7kBsu0dSmtxbQRD9XHAAAAAAAAA== --------------ms050103080802040602040409-- From michael@stroeder.com Thu Jan 9 12:40:30 2014 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 414B61AE550 for ; Thu, 9 Jan 2014 12:40:30 -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 dOkPI7N4U7lF for ; Thu, 9 Jan 2014 12:40:28 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 52EED1AE16F for ; Thu, 9 Jan 2014 12:40:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 1B4E56078D; Thu, 9 Jan 2014 21:40:18 +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 xzbewO3S6lvO; Thu, 9 Jan 2014 21:40:12 +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 7BBA160702; Thu, 9 Jan 2014 20:40:11 +0000 (UTC) Message-ID: <52CF0929.2020904@stroeder.com> Date: Thu, 09 Jan 2014 21:40:09 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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: Andrew Findlay , ldapext References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <20140109180851.GW3938@slab.skills-1st.co.uk> In-Reply-To: <20140109180851.GW3938@slab.skills-1st.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060003000505070901040709" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:40:30 -0000 This is a cryptographically signed message in MIME format. --------------ms060003000505070901040709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > On Thu, Jan 09, 2014 at 04:48:37PM +0100, Michael Str=F6der wrote: >=20 >>> Nested groups are very important especially in large enterprises, and= really >>> do assist with data management. >> >> I am always getting told this but I have strong doubts about nested gr= oups. >=20 > Groups are usually there to define permissions - the Authorisation > part of the AAA triple. Allowing nested groups helps to decouple > individual users from individual permissions. For example: >=20 > The Helpdesk group contains a, b, c, d > The SysManagers group contains e, f > The PasswordRestKiosk group contains j, k, l, m > The AccountProvisioning group contains p >=20 > I can now write permission rules like: >=20 > Members of Helpdesk, PasswordRestKiosk, AccountProvisioning may set us= er passwords > Members of SysManagers may set system-account passwords > Members of Helpdesk, AccountProvisioning may change user contact data What you describe is rather assigning permissions to user groups. IMHO th= at's not what people mean when they are talking about nested groups in general= =2E >> Resolving nested group membership is a big performance cost. I can see= this >> with a MS Sharepoint installation working with a OpenLDAP server. Shar= epoint >> sends many search requests even though nested groups are not used in t= his >> deployment. >=20 > That is because there is no standard schema for nested groups, so > there is no server-side support to make them efficient. [In fact > many LDAP server implementations do define their own nesting > schemes, but I don't think any of them are shared with other > unrelated implementations.] Ok, let the server internally search all the group membership (like AD do= es e.g. with tokenGroups attribute) would make things more effecient. > You and I started trying to sort this out after the first LDAP > conference, but the effort got bogged down. Maybe we should dust off > the drafts and see if anything can be salvaged. Server-side resolving of nested groups were far beyond our former scope. = But we could try. > I don't see that it adds much to the work. If the server supports > nested groups then it is a single query; otherwise it is a series of > derefs. (I am assuming a simple two-level nesting here as I can see > many uses for that without making the rules too complex.) Aha, you're limiting to two levels... ;-) Ciao, Michael. --------------ms060003000505070901040709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MjA0MDA5WjAj BgkqhkiG9w0BCQQxFgQUmPBQM8CFvmvwjYE3zUxNxnfjSU0wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAq8sMDfeFZBmqO6hv1gN8GCInG1R5ekkR HlZv57BFhiZawX4R58hzyrXOLMN6G+9MGHF76eV2YgG1sX8BB+Pbb0vjgTVndtRT5uKo3dMZ Rog5uJi5AskOaJLlnv31yaFUdqVepQYE2lliznEvVPZbklUeQE/FZ0gZ6EfEZtDdCLAuQ7LX fgr6okvcdPawuotHk/jITqzU55eL6mGQOpbyOHj73zyIc3Ljuzt7yW/9ta6zYEPQWOkz7Gph Qy2a81vZ5LAB+hQCi64hkAsYuEZOuY/ov0FJE6QY5NA/5UDSeRclMfaDvg6/j2oZw2UZAcnI wVnrIcU3psQLvSDDO1Z71gAAAAAAAA== --------------ms060003000505070901040709-- From michael@stroeder.com Thu Jan 9 12:45:37 2014 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 28C1A1AE4D9 for ; Thu, 9 Jan 2014 12:45:37 -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 ZHKOApRaMJ7u for ; Thu, 9 Jan 2014 12:45:35 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 75DFB1AE1F2 for ; Thu, 9 Jan 2014 12:45:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id B82636078D; Thu, 9 Jan 2014 21:45:24 +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 R9APVVVwLn4t; Thu, 9 Jan 2014 21:45:19 +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 6B4CE60702; Thu, 9 Jan 2014 20:45:18 +0000 (UTC) Message-ID: <52CF0A5C.5090002@stroeder.com> Date: Thu, 09 Jan 2014 21:45:16 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 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: Simo References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <52CDA099.9070300@stroeder.com> <1389219912.27654.113.camel@pico.ipa.ssimo.org> <52CEE58C.7060304@stroeder.com> <1389299653.27654.130.camel@pico.ipa.ssimo.org> In-Reply-To: <1389299653.27654.130.camel@pico.ipa.ssimo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040107050709090502020803" Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:45:37 -0000 This is a cryptographically signed message in MIME format. --------------ms040107050709090502020803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simo wrote: > On Thu, 2014-01-09 at 19:08 +0100, Michael Str=C3=B6der wrote: >> Simo wrote: >>> The full schema definitions can be found here: >>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60ba= sev2.ldif >> >> Looked at the schema: >> >> I'm a bit confused by some object classes directly referencing MAY mem= berOf. >> 'memberOf' is normally an operational attribute also in 389 DS isn't i= t? >=20 > It is a generated by the memberof plugin, it's semantics are different > from other solutions (like AD), all descendants are resolved at modify > time. Really different semantics? AFAIK memberOf should be a simple back-link from the member's entry to th= e group entry. When the attribute value is actually created (on modify or o= n read) is not relevant for memberOf semantics. Or did I get you wrong? >> Also I don't understand the rationale for object class nestedGroup SUP= >> groupOfNames with memberOf. >=20 > Not sure where's the confusion. I'm confused by seeing an operational attribute like 'memberOf' being def= ined in user schema. Ciao, Michael. --------------ms040107050709090502020803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MjA0NTE2WjAj BgkqhkiG9w0BCQQxFgQUQZCDOHM8/ruocqXRVyNpRKxJcRAwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEASGlS1RWw6cSwG8BWJsOAtbTbXuoDLChj N4XSmgjQD+ybNinraQ5t9zDqv5xb9eNMYbN02XcmcZh2V6vKQMJTEVIONyB8PbgILXfcjGrF CaJRePX9ZpisUg2ul+qGaLgKDYjmVjadphLQsgjor3Xp/eafstil7r54Ac6CKukNj1c2JrQU tPpCTGJVtLJ7XflV20eOrYOiGDfFFRROG4yhBZciP5gIz6TX09pP0UNEpzxGLcxW3vMoiy/Q dz9C9bcJRel/8rzW4zBf3j+vvX2Q3MSxu6W8GUxyEtiXro8DmSa5Y/68WXBg2F4e+vSeSsgK 24FMqsaZNGqsO8aF2AjG3QAAAAAAAA== --------------ms040107050709090502020803-- From medievalist@gmail.com Thu Jan 9 16:32:40 2014 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 32A441ACC7E for ; Thu, 9 Jan 2014 16:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 viZq4W6Yo2xf for ; Thu, 9 Jan 2014 16:32:38 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7DA1AC829 for ; Thu, 9 Jan 2014 16:32:38 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id y6so993204lbh.18 for ; Thu, 09 Jan 2014 16:32:28 -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 :content-type; bh=1RC/7HKbbW3WtzbbU9o0agu06WYoLNtNJx0LhY1ivvE=; b=oEo8qaXDVDdDb3Gn1dGSO610GSKH3TcjIhtSHHA5G4/WZuhhJ6c7taBO6Kx7+lWKo7 imARoTX6dRI28AfMWBR8oKg/rRITYJLNQcS7D418To19EI/xHUBY+jmpAQH+VUnpdeVO 8KADRzfTV9l3CQrKS94yWOOYsn35E1RWT4ev/5KZDAERCjbya1wFCzU4vWK3+R7eLoQD ToUHrKGVSdKiZhUmgFFt6ktuu90vLKqWjVbLuIpzC1oTD8dW2D9BuaiVLCPf5ni7cvOx JC/uy7RYGpYiesQHm+3znrWIRrKTW8vcDMASW5SqZsPRR9GMGXAnWexhGmccWvP+p0nV FTHA== MIME-Version: 1.0 X-Received: by 10.112.151.42 with SMTP id un10mr2415646lbb.7.1389313948088; Thu, 09 Jan 2014 16:32:28 -0800 (PST) Received: by 10.112.141.65 with HTTP; Thu, 9 Jan 2014 16:32:28 -0800 (PST) In-Reply-To: <52CDC249.8050407@proseconsulting.co.uk> References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> Date: Thu, 9 Jan 2014 19:32:28 -0500 Message-ID: From: Charlie To: Mark R Bannister , ldapext Content-Type: text/plain; charset=ISO-8859-1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 00:32:40 -0000 What I have learned from about a decade of quietly following LDAP across multiple forums and lists is the following: 1) Whenever people say "nobody is using this/that" they are invariably wrong. 2) POSIX group semantics are the bane of open-source LDAP. The functional paradigm that a member is an attribute of a group is fundamentally broken; group membership is an attribute of the member. The security concerns frequently raised concerning this are all either trivially solvable or pragmatically completely bogus. 3) Howard knows what he's talking about. But Kurt also knows what he's talking about, and Kurt wrote "multi-master considered harmful" (draft-zeilenga-ldup-harmful-00). Sometimes real world pragmatism obviates perfectly valid academic arguments. --Charlie From lukeh@padl.com Thu Jan 9 16:42:48 2014 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 C60AD1ADA74 for ; Thu, 9 Jan 2014 16:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 Vg5aJq41yp6u for ; Thu, 9 Jan 2014 16:42:47 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 50C451AC828 for ; Thu, 9 Jan 2014 16:42:47 -0800 (PST) Received: by us.padl.com with ESMTP id s0A0gPaP003200; Thu, 9 Jan 2014 19:42:29 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luke Howard In-Reply-To: Date: Fri, 10 Jan 2014 11:42:25 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> To: Ldapext X-Mailer: Apple Mail (2.1822) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 00:42:49 -0000 I was reluctant to join this conversation as I haven't had a chance to = look at the drafts, but: to anyone wanting to improve on RFC2307 (or = indeed, anything), I would say go for it. To get traction IMO, it needs to (a) be published in a finished state = (unlike 2307bis), and (b) have a reference implementation that supports = every platform. Enterprises that are still welded to NIS and need all = the corner cases (netgroups, case sensitivity, etc) are also likely to = still be using AIX, HP-UX, Solaris 8, etc. (Of course there is always = inertia owing to the installed base, but were one to have that attitude = about everything, there would be no progress. In the end the market will = decide.) -- Luke= From bob.joslin@hp.com Thu Jan 9 17:31:16 2014 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 DE7451ACCFA for ; Thu, 9 Jan 2014 17:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.438 X-Spam-Level: X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538] 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 56I9Ur6iw1-r for ; Thu, 9 Jan 2014 17:31:15 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2C1ACC87 for ; Thu, 9 Jan 2014 17:31:14 -0800 (PST) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id A5FD5800D; Fri, 10 Jan 2014 01:31:04 +0000 (UTC) Received: from G4W6305.americas.hpqcorp.net (16.210.26.230) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 10 Jan 2014 01:29:24 +0000 Received: from G4W3226.americas.hpqcorp.net ([169.254.5.124]) by G4W6305.americas.hpqcorp.net ([16.210.26.230]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 01:29:24 +0000 From: "Neal-Joslin, Robert (3PAR Engineering)" To: Mark R Bannister , ldapext Thread-Topic: [ldapext] DBIS - new IETF drafts Thread-Index: AQHPDKN3qmJ8NeTnkEOj9cqs5xDRkJp7VweAgAHGkwCAAA5qUA== Date: Fri, 10 Jan 2014 01:29:24 +0000 Message-ID: References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 01:31:17 -0000 My apologies for commenting on this without having read the draft, and also= being out of this technology for several years. It seems the root of the complaint is that the RFC2307 schema isn't good en= ough. But what I've learned is that there is no schema that is good enough= . Which is why we wrote RFC4876, which allows the DUA to convert the RFC23= 07 schema (or any schema) to the locally deployed schema. For example, pos= ixGroup can be mapped to a dynamic group. Regards, Bob Neal-Joslin > -----Original Message----- > From: Ldapext [mailto:ldapext-bounces@ietf.org] On Behalf Of Charlie > Sent: Thursday, January 09, 2014 4:32 PM > To: Mark R Bannister; ldapext > Subject: Re: [ldapext] DBIS - new IETF drafts >=20 From hyc@highlandsun.com Thu Jan 9 18:34:10 2014 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 3713B1ADFA5 for ; Thu, 9 Jan 2014 18:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ObMsU2lvbu6q for ; Thu, 9 Jan 2014 18:34:08 -0800 (PST) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id F18331ADF88 for ; Thu, 9 Jan 2014 18:34:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 4AB2510F3D; Thu, 9 Jan 2014 21:33:57 -0500 (EST) Message-ID: <52CF5C14.3020600@highlandsun.com> Date: Thu, 09 Jan 2014 18:33:56 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1 MIME-Version: 1.0 To: Mark R Bannister , 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> <52CB24F4.1030503@highlandsun.com> <52CDB3EE.6080203@proseconsulting.co.uk> In-Reply-To: <52CDB3EE.6080203@proseconsulting.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 02:34:10 -0000 Mark R Bannister wrote: > On 06/01/2014 21:49, Howard Chu wrote: >> The alarming part is that such obvious flaws in data modeling are >> still occurring today, over a decade after they were first addressed. >> I raised these issues back in 2001 as I recall. Some references in >> 2002 http://www.openldap.org/lists/openldap-software/200201/msg00628.html > > Well, I still wouldn't call that "alarming" unless you are of the > singular belief that every message you have personally written has been > read by everyone in the world. Don't be stupid. My expectation is that anyone who intends to write new LDAP specifications for the IETF has already read all of the existing LDAP specifications and any discussions surrounding relevant works-in-progress, along with the already published defects in such unfinished items. Clearly you have not done your due diligence. It takes very little time to troll the ldapext mailing list archive and find previous attempts to fix RFC2307. E.g. http://www.ietf.org/mail-archive/web/ldapext/current/msg01808.html It takes not much time at all to google "rfc2307 nis ldap" and find commentary from the original author(s) noting the spec's problems and better alternatives. http://www.openldap.org/lists/openldap-software/200201/msg00628.html http://www.openldap.org/lists/openldap-software/200109/msg00278.html It takes not much time at all to see that most of the problems you're trying to address have already been attacked, e.g. the schema mapping in your spec overlaps RFC4687. If you haven't fully absorbed the existing specs and standardization efforts then there's no way to take anything you've done as anything other than reinventing the wheel. That's not how progress gets made, that's how time gets wasted. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From michael@stroeder.com Fri Jan 10 02:40:34 2014 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 F19F81ADF5F for ; Fri, 10 Jan 2014 02:40:33 -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 ht7TlNhzazBc for ; Fri, 10 Jan 2014 02:40:32 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0D1ADE84 for ; Fri, 10 Jan 2014 02:40:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 289C6607E1; Fri, 10 Jan 2014 11:40:20 +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 OYNtA0C4UUud; Fri, 10 Jan 2014 11:40:16 +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 6043D6075E; Fri, 10 Jan 2014 10:40:15 +0000 (UTC) Message-ID: <52CFCE0B.4040802@stroeder.com> Date: Fri, 10 Jan 2014 11:40:11 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 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: Simo References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <1389290636.27654.125.camel@pico.ipa.ssimo.org> <52CF0838.3060102@stroeder.com> <1389300747.27654.133.camel@pico.ipa.ssimo.org> In-Reply-To: <1389300747.27654.133.camel@pico.ipa.ssimo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000302000202060307000109" Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:40:34 -0000 This is a cryptographically signed message in MIME format. --------------ms000302000202060307000109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simo wrote: > On Thu, 2014-01-09 at 21:36 +0100, Michael Str=C3=B6der wrote: >> Simo wrote: >>> On Thu, 2014-01-09 at 16:48 +0100, Michael Str=C3=B6der wrote: >>>> Resolving nested group membership is a big performance cost. I can s= ee this >>>> with a MS Sharepoint installation working with a OpenLDAP server. Sh= arepoint >>>> sends many search requests even though nested groups are not used in= this >>>> deployment. >>> >>> Performance issues with nested groups can easily be solved via cachin= g >>> and the deref control though. >> >> But the deref control gives you only one level. Speaking of nested gro= ups in >> general people mean more than just two-level group memberships. >=20 > It's an 80/20 thing, the most common case is 2 levels deep, so the wors= t > case is not usually a big issue. But if you don't enforce the 2-level-nested-groups limit the client has t= o search for nested groups and deref control does not help. Ciao, Michael. --------------ms000302000202060307000109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTEwMTA0MDExWjAj BgkqhkiG9w0BCQQxFgQUc6wRgF6KSwLWhrkGbvO3+2B3TLgwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAW4NM7/bsmSoh6w5OltmeoMNNZutq6iaA SEXKt6Zhi1VCPKUx/ZqZ43dwzD6D6loO3BkNWE8xdh3gIq+m4aOWQ6KFHvFN0dDChmQminAL SELetppEGHhGoPtWWPtLMDkSUpK/kzbHPWmGVGOs+uU3xs8dv68WO/QOqHTx2S6shCouAioS 1a404oYWJ/mbOiTGTeGGXVsl1kly+D2fvEkdPZMO9n/LG2v/zXwDtcinLBDKwIwWLB5Qx7Bf Y2/hhI8ATViIeTIK/42Lmclb43LW9SgjHy9RI/bWyogENxtJuzDpnCpNaYkIzw3mqPUnCF4F ozH3dCdlUH+zemju/fW2LQAAAAAAAA== --------------ms000302000202060307000109-- From dbis@proseconsulting.co.uk Fri Jan 10 05:47:01 2014 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 A1EA71AE020 for ; Fri, 10 Jan 2014 05:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 G6sU5GnzFjEB for ; Fri, 10 Jan 2014 05:47:00 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A21ADEBE for ; Fri, 10 Jan 2014 05:46:59 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W1cQC-00033V-Ld; Fri, 10 Jan 2014 13:46:48 +0000 Message-ID: <52CFF9B0.6020408@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 13:46:24 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= , 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> In-Reply-To: <52CEB72F.9050000@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:47:01 -0000 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. > >> 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? > >> 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. Best regards, Mark. From dbis@proseconsulting.co.uk Fri Jan 10 05:54:53 2014 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 1A4581AE008 for ; Fri, 10 Jan 2014 05:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 xMPa7d0GU1Cl for ; Fri, 10 Jan 2014 05:54:52 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id D7DBB1ADF4D for ; Fri, 10 Jan 2014 05:54:51 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W1cXp-0007r3-95; Fri, 10 Jan 2014 13:54:41 +0000 Message-ID: <52CFFB89.1040900@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 13:54:17 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> In-Reply-To: <52CEBEAE.5090701@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:54:53 -0000 On 09/01/2014 15:22, Michael Ströder wrote: > Mark R Bannister wrote: >>> Exposing hashes should be a last resort for compatibility reasons only >>> and should be disabled by default with appropriate ACIs. > The problem with exposing a central {CRYPT} hash is that a central and single > password will be compromised even though newer systems might be capable of > using stronger authc mechs. Especially if you want to support old systems you > likely won't be able to use a stronger {CRYPT} hashing scheme. > > => I'd avoid that mess completely and I won't support any schema encouraging > this. At least your drafts should contain big ALARM notes in the security > considerations section. As long as we have a solution to make migration to DBIS straightforward and without forcing everybody to change their passwords and without forcing legacy NIS clients to require upgrading, then I'm with you. > >> I don't suggest DBIS makes any mention of ACIs. That's up to local rules & >> procedures, not something that could possibly be standardised. >>> My point of view is that using LDAP binds SHOULD be mandated for >>> authentication for any new client following any new schema, and exposing >>> hashes MUST be disabled by default, and explicitly enabled by admins >>> that needs backwards compatibility. We need to move up the security bar, >>> and you do that only with appropriate defaults, and new IETF work should >>> reflect that IMHO. >>> >>> Simo. > +1 to Simo's comment. Can all LDAP servers on the market today use a CRYPT-style password to serve a bind request? If so, it's easy to mandate this. If not, it won't be mandatory. > >> I don't think LDAP binds can be mandated, we can only strongly recommend it. >> Given the migration path I have already described, I find it highly unlikely >> that people will be able to move to LDAP binds and move off CRYPT immediately, > If your customers have old legacy systems which they won't change at all then > simply let them run them in a isolated environment with all the old cruft > around they need for those systems. Sooner or later they have to migrate > anyway because systems are running out-of-service (e.g. will not receive > security updates anymore). > > IMO any new standard should focus on getting the near future right. This is where we differ a lot. You would throw away the past to build the future (ironically something that Howard seems to be accusing me of). I, on the other hand, am all about building bridges between the past and the future so that we don't cut anybody out. Everyone should be able to make use of DBIS, right now, without pain. Flick a switch, you're on DBIS, then slowly make improvements once you're on a better framework. That's the philosophy, and I'll happily battle hard and feel lots of pain now convincing everybody that you can't ignore the past, if it means users of DBIS in the future don't have to feel any pain. Best regards, Mark. From dbis@proseconsulting.co.uk Fri Jan 10 06:03:15 2014 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 0530D1ADF73 for ; Fri, 10 Jan 2014 06:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 a8B0G85Dg5ub for ; Fri, 10 Jan 2014 06:03:14 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 052CC1ADE72 for ; Fri, 10 Jan 2014 06:03:14 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W1cfv-0006yd-I6; Fri, 10 Jan 2014 14:03:03 +0000 Message-ID: <52CFFD80.6030600@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 14:02:40 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= , ldapext@ietf.org References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> In-Reply-To: <52CEC4D5.1070703@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:03:15 -0000 On 09/01/2014 15:48, Michael Ströder wrote: > Mark R Bannister wrote: >> 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, > This could be easily solved with RFC2307bis. Or not? Not. It uses the 'cn' attribute for a start, which is case insensitive. > In my deployments I simply define additional (OpenLDAP) constraints for those > attributes (e.g. to enforce lower-case 'uid' values). Hard to do with 'cn'. We had to invent a new custom attribute to replace 'cn' with. > IMHO only re-defining the matching rules does not fully solve the case problem > anyway. Restricting to lower-case attribute values helps better. > >> It seemed quite strange to me that >> RFC2307 should have differed like this from NIS in the first place. > We all agree that RFC 2307 - even though widely deployed - has serious issues. > >> Yes this was another aspect I wanted to simplify. RFC2307bis does not make it >> easy to express group membership. > What does "express group membership" mean exactly? "Express", meaning, to put into words. > >> Nested groups are very important especially in large enterprises, and really >> do assist with data management. > I am always getting told this but I have strong doubts about nested groups. If you're always getting told this, then there must be lots of people who like nested groups. If people like it, then it's in demand. > >> 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. > Resolving nested group membership is a big performance cost. I can see this > with a MS Sharepoint installation working with a OpenLDAP server. Sharepoint > sends many search requests even though nested groups are not used in this > deployment. Caching will improve the situation. Yes there is a performance cost. So what? Don't innovate if it takes CPU cycles? > Also nested groups are a pain if you want to report all effective user rights > to auditors (which is something banks have to do at least once per year). In > this context even maintaining the group membership does not look that simple > anymore. > Not if you come up with the good tools to help you search and visualise the nested structures. Best regards, Mark. From dbis@proseconsulting.co.uk Fri Jan 10 06:08:15 2014 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 B26861AE078 for ; Fri, 10 Jan 2014 06:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 4YL3Q7_rHmNV for ; Fri, 10 Jan 2014 06:08:14 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD221AE068 for ; Fri, 10 Jan 2014 06:08:14 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W1ckm-00051O-8o; Fri, 10 Jan 2014 14:08:04 +0000 Message-ID: <52CFFEAC.7070208@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 14:07:40 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andrew Findlay , =?ISO-8859-1?Q?Mich?= =?ISO-8859-1?Q?ael_Str=F6der?= References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk> In-Reply-To: <20140109174321.GV3938@slab.skills-1st.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:08:15 -0000 On 09/01/2014 17:43, Andrew Findlay wrote: > On Thu, Jan 09, 2014 at 04:22:22PM +0100, Michael Ströder wrote: > >> Mark R Bannister wrote: >>>> Exposing hashes should be a last resort for compatibility reasons only >>>> and should be disabled by default with appropriate ACIs. > Absolutely. You need the LDAP server to support the old-style hashes > to allow for migrating data in, but exposing *any* form of hash > outside your trusted LDAP servers is asking for trouble. > > Every LDAP-aware client system that I have worked with can use the > bind operation as a means to validate passwords, so the only > possible excuse for exporting hashes is temporary support of > migrating systems. If you only allow the export of hashes that are > actually needed by the old non-LDAP systems then at least you are > not making matters worse than they were before the migration. Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords? If it can be done server-side there'll be no problem here and we need never expose the hashes to clients. > >> IMO any new standard should focus on getting the near future right. > Yes, but that does have to include migrating stuff that is currently > stuck in the technological past! > > Thanks Andrew, I think this point can't be emphasised enough. We must always be aware of how customers are going to be expected to get from A to B. That journey needs to be as simple as possible. If that means supporting extra legacy stuff to smooth the transition, than so be it. Best regards, Mark. From dbis@proseconsulting.co.uk Fri Jan 10 06:13:50 2014 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 882551AE086 for ; Fri, 10 Jan 2014 06:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 QegeNiV5zCgQ for ; Fri, 10 Jan 2014 06:13:49 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8AD1AE057 for ; Fri, 10 Jan 2014 06:13:49 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W1cqA-0003zV-Qm; Fri, 10 Jan 2014 14:13:39 +0000 Message-ID: <52CFFFFB.8060105@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 14:13:15 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Simo , =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <1389290636.27654.125.camel@pico.ipa.ssimo.org> In-Reply-To: <1389290636.27654.125.camel@pico.ipa.ssimo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:13:50 -0000 On 09/01/2014 18:03, Simo wrote: > On Thu, 2014-01-09 at 16:48 +0100, Michael StrĂśder wrote: >> Mark R Bannister wrote: >>> 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, >> This could be easily solved with RFC2307bis. Or not? >> >> In my deployments I simply define additional (OpenLDAP) constraints for those >> attributes (e.g. to enforce lower-case 'uid' values). >> >> IMHO only re-defining the matching rules does not fully solve the case problem >> anyway. Restricting to lower-case attribute values helps better. > > I'd go beyond this, supporting case-sensitive user names is actively > harmful for various reasons. UNIX is traditionally case sensitive. I am currently working at a large installation where there is an important distinction between lower-case and upper-case user names. This debate isn't just about user names anyway. There are loads of NIS fields that were case sensitive, and UNIX isn't going to change. They will always be case sensitive. So trying to represent them in case insensitive fields is just, well, wrong. > - Assuming users (and admins) should be able to distinguish based on > case is wrong, we naturally consider the strings 'Admin' and 'admin' to > be the same thing. If you're used to Microsoft Windows, yes. DBIS is not aimed at Microsoft. > - Some systems are case-preserving (meaning they'll show you back the > same case you entered, but are really case-insensitive and if you have > to interoperate with them you cannot assume Admin and amdin to be > different users, it could lead to serious security issues. > > - If we are in the legacy game, there are still systems that will simply > accept only all caps names, like ADMIN. In these cases what do you map > that to ? Admin ? admin? a third user called ADMIN ? > > And there are many other examples where really being case sensitive > causes a lot more problem than it resolves. > Due to these problems what we did in FreeIPA is to always create users > in lower case and explicitly state we are case-preserving and > insensitive. It is the only reasonable compromise IMHO. NIS, RFC2307, RFC2307bis and DBIS are for UNIX. UNIX is case sensitive. It makes no sense to store data in a case insensitive fashion if the client expects it to be case sensitive. Data loss or corruption will occur this way. Best regards, Mark. From lukeh@padl.com Fri Jan 10 06:15:30 2014 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 27A5A1AE087 for ; Fri, 10 Jan 2014 06:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 ly3yrMWKtFNM for ; Fri, 10 Jan 2014 06:15:28 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0241AE086 for ; Fri, 10 Jan 2014 06:15:28 -0800 (PST) Received: by us.padl.com with ESMTP id s0AEF4mo001067; Fri, 10 Jan 2014 09:15:09 -0500 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luke Howard In-Reply-To: <52CFFEAC.7070208@proseconsulting.co.uk> Date: Sat, 11 Jan 2014 01:15:03 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk> <52CFFEAC.7070208@proseconsulting.co.uk> To: Mark R Bannister X-Mailer: Apple Mail (2.1822) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.4 Cc: Ldapext , Andrew Findlay , =?iso-8859-1?Q?Michael_Str=F6der?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:15:30 -0000 >> Every LDAP-aware client system that I have worked with can use the >> bind operation as a means to validate passwords, so the only >> possible excuse for exporting hashes is temporary support of >> migrating systems. If you only allow the export of hashes that are >> actually needed by the old non-LDAP systems then at least you are >> not making matters worse than they were before the migration. >=20 > Ok, so I posed this question just now, but can all LDAP servers you = can think of authentication bind operations using CRYPT-style passwords? = If it can be done server-side there'll be no problem here and we need = never expose the hashes to clients. Active Directory cannot. -- Luke= From lukeh@padl.com Fri Jan 10 06:17:12 2014 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 3CB0A1ADF8A for ; Fri, 10 Jan 2014 06:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 VmkW-LjYtkNu for ; Fri, 10 Jan 2014 06:17:11 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF271ADF73 for ; Fri, 10 Jan 2014 06:17:11 -0800 (PST) Received: by us.padl.com with ESMTP id s0AEGq2Z001129; Fri, 10 Jan 2014 09:16:55 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luke Howard In-Reply-To: <52CFFFFB.8060105@proseconsulting.co.uk> Date: Sat, 11 Jan 2014 01:16:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D1C420E-A625-4391-B929-6400C3EAF70D@padl.com> References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <1389290636.27654.125.camel@pico.ipa.ssimo.org> <52CFFFFB.8060105@proseconsulting.co.uk> To: Mark R Bannister X-Mailer: Apple Mail (2.1822) X-SMTP-Vilter-Version: 1.3.6 Cc: Simo , Ldapext , =?iso-8859-1?Q?Michael_Str=F6der?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:17:12 -0000 > UNIX is traditionally case sensitive. I am currently working at a = large installation where there is an important distinction between = lower-case and upper-case user names. This debate isn't just about user = names anyway. There are loads of NIS fields that were case sensitive, = and UNIX isn't going to change. They will always be case sensitive. So = trying to represent them in case insensitive fields is just, well, = wrong. Unfortunately once again this exists for historical reasons (mostly to = do with Netscape's original internal deployment, if my memory serves me = correctly). Obviously you can fix it with client-side schema mapping, = but it's also good to have a schema to map to, agreed. -- Luke= From dbis@proseconsulting.co.uk Fri Jan 10 06:18:10 2014 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 2AD021AE064 for ; Fri, 10 Jan 2014 06:18:10 -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 s-naE4ufWY2A for ; Fri, 10 Jan 2014 06:18:08 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id B745E1ADF8A for ; Fri, 10 Jan 2014 06:18:08 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W1cuM-00009f-F7; Fri, 10 Jan 2014 14:17:58 +0000 Message-ID: <52D000FE.6050909@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 14:17:34 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Charlie , ldapext References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:18:10 -0000 On 10/01/2014 00:32, Charlie wrote: > What I have learned from about a decade of quietly following LDAP > across multiple forums and lists is the following: > > 1) Whenever people say "nobody is using this/that" they are invariably wrong. Thanks Charlie, good point. It's like when you watch the TV news and a journalist says "the public think this" or "the public think that". Once something is in the public domain, I don't think anyone can claim to know who is using what, how everyone is using it, nor on what antiquated features anyone may or may not rely, except perhaps the NSA, but let's not go there ;-) > 2) POSIX group semantics are the bane of open-source LDAP. The > functional paradigm that a member is an attribute of a group is > fundamentally broken; group membership is an attribute of the member. > The security concerns frequently raised concerning this are all either > trivially solvable or pragmatically completely bogus. DBIS allows you to represent it from both angles. Best regards, Mark. From dbis@proseconsulting.co.uk Fri Jan 10 06:22:16 2014 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 4B7621AE046 for ; Fri, 10 Jan 2014 06:22:16 -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 7w8L1sdLcXcf for ; Fri, 10 Jan 2014 06:22:15 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id B5FF21ADF90 for ; Fri, 10 Jan 2014 06:22:14 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W1cyK-0001ij-Dv for ldapext@ietf.org; Fri, 10 Jan 2014 14:22:04 +0000 Message-ID: <52D001F4.4020504@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 14:21:40 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ldapext@ietf.org References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:22:16 -0000 On 10/01/2014 00:42, Luke Howard wrote: > I was reluctant to join this conversation as I haven't had a chance to look at the drafts, but: to anyone wanting to improve on RFC2307 (or indeed, anything), I would say go for it. Thanks Luke, I went for it already. > To get traction IMO, it needs to (a) be published in a finished state (unlike 2307bis) That bit might be hard, even once the reference implementation is complete and it's proven how does one get something out of draft into a published state? > , and (b) have a reference implementation that supports every platform. Working on it. As much as possible with be Python, so apart from NSS/PAM semantics, it will be quite portable. > Enterprises that are still welded to NIS and need all the corner cases (netgroups, case sensitivity, etc) are also likely to still be using AIX, HP-UX, Solaris 8, etc. (Of course there is always inertia owing to the installed base, but were one to have that attitude about everything, there would be no progress. In the end the market will decide.) Indeed, and all of the big clients I've worked for still have a sizeable Solaris 8 footprint, and those clients are very reluctant if not refusing to upgrade that estate. I haven't seen as much AIX or HP-UX. I would rather DBIS supports all of the legacy platforms as well, so that everyone can make a clean break from NIS and RFC2307 rather than having to support both environments. This is why I have focused very hard on compatibility between the models. Best regards, Mark. From dbis@proseconsulting.co.uk Fri Jan 10 06:26:07 2014 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 3FD841AE064 for ; Fri, 10 Jan 2014 06:26:07 -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 KIkAXEsqO6jI for ; Fri, 10 Jan 2014 06:26:05 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF361AE061 for ; Fri, 10 Jan 2014 06:26:05 -0800 (PST) Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1W1d23-0003R5-3A; Fri, 10 Jan 2014 14:25:55 +0000 Message-ID: <52D002DB.6050708@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 14:25:31 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Neal-Joslin, Robert (3PAR Engineering)" , ldapext References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:26:07 -0000 On 10/01/2014 01:29, Neal-Joslin, Robert (3PAR Engineering) wrote: > My apologies for commenting on this without having read the draft, and also being out of this technology for several years. > > It seems the root of the complaint is that the RFC2307 schema isn't good enough. But what I've learned is that there is no schema that is good enough. Which is why we wrote RFC4876, which allows the DUA to convert the RFC2307 schema (or any schema) to the locally deployed schema. For example, posixGroup can be mapped to a dynamic group. > Hi Bob, Thanks, but one of the most powerful features of DBIS gives us the ability to pull together the entries for any given map from multiple locations in the DIT, using a mix of different schemas. This makes it so much easier to merge NIS domains together without having to manually export/transform/import anything. Best regards, Mark. From dbis@proseconsulting.co.uk Fri Jan 10 06:30:59 2014 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 E16AC1AE01E for ; Fri, 10 Jan 2014 06:30:59 -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 QSa3PU7XRL5j for ; Fri, 10 Jan 2014 06:30:57 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id BB21A1ADFC7 for ; Fri, 10 Jan 2014 06:30:57 -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 ) id 1W1d6l-0007dD-4E; Fri, 10 Jan 2014 14:30:47 +0000 Message-ID: <52D003FF.9010600@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 14:30:23 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Howard Chu , 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> <52CB24F4.1030503@highlandsun.com> <52CDB3EE.6080203@proseconsulting.co.uk> <52CF5C14.3020600@highlandsun.com> In-Reply-To: <52CF5C14.3020600@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:31:00 -0000 On 10/01/2014 02:33, Howard Chu wrote: > > Don't be stupid. Howard, If you have some more technical input I'd really like to hear it. Otherwise you have already made your point, which regards only 5 attribute definitions in 1 of my 8 submitted drafts, and which I have already committed to fixing. Best regards, Mark. From michael@stroeder.com Fri Jan 10 06:34:14 2014 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 D167E1AE064 for ; Fri, 10 Jan 2014 06:34:14 -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 1Us4ce7dcbUK for ; Fri, 10 Jan 2014 06:34:13 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE901AE059 for ; Fri, 10 Jan 2014 06:34:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 5A7E1607FB for ; Fri, 10 Jan 2014 15:34:01 +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 uhD93B935McD for ; Fri, 10 Jan 2014 15:33:57 +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 D37116075E for ; Fri, 10 Jan 2014 14:33:55 +0000 (UTC) Message-ID: <52D004CF.4070301@stroeder.com> Date: Fri, 10 Jan 2014 15:33:51 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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: Ldapext References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk> <52CFFEAC.7070208@proseconsulting.co.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010506050805000006000601" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:34:15 -0000 This is a cryptographically signed message in MIME format. --------------ms010506050805000006000601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Luke Howard wrote: >>> Every LDAP-aware client system that I have worked with can use the >>> bind operation as a means to validate passwords, so the only >>> possible excuse for exporting hashes is temporary support of >>> migrating systems. If you only allow the export of hashes that are >>> actually needed by the old non-LDAP systems then at least you are >>> not making matters worse than they were before the migration. >> >> Ok, so I posed this question just now, but can all LDAP servers you ca= n think of authentication bind operations using CRYPT-style passwords? I= f it can be done server-side there'll be no problem here and we need neve= r expose the hashes to clients. >=20 > Active Directory cannot. Right. But it's not a real operational issue because if you already have an AD d= omain with a big user base they already have passwords set for Windows anyway. Ciao, Michael. --------------ms010506050805000006000601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTEwMTQzMzUxWjAj BgkqhkiG9w0BCQQxFgQUveBvHwFlebQDwY2/6+n134RA+xUwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAFc0Ms0af+5MeeIItW0xaObiczsGov/9T YwhIqoDv4odGQEyR8L/5B3AT3UZSSCWg+1BIT8uk7mzPMzk3MI4W4tS4MY7N1EUajNbP8tcK xyU3N5oxXzaSlq2EBEUU/FQ8PMYgwPEPlUq7ilp+Ou4w1UOSDiVo+l7wJBzizkQ/t+9mGPul cPfT2hSFOapxpHc6rfld2Op2JGWsg1dOQAINGrzWtDGTtSD77ZDbxZ9ow9PMTQX6Cx5Lwnbd L/c9Mb4TYAuBo2LK9XSuf1bzHATUfYqY96YRofSiJx2Gqr+2WS+mYrXvFyrDp4LEP/fyrTkZ rz+A9ZsE8+SOQXkbTlBI9gAAAAAAAA== --------------ms010506050805000006000601-- From dbis@proseconsulting.co.uk Fri Jan 10 06:37:22 2014 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 8AC5C1AE01E for ; Fri, 10 Jan 2014 06:37:22 -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 W7HMn6Fs-1k7 for ; Fri, 10 Jan 2014 06:37:21 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1A71AD68A for ; Fri, 10 Jan 2014 06:37:21 -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 ) id 1W1dCw-0001Z2-LF; Fri, 10 Jan 2014 14:37:10 +0000 Message-ID: <52D0057D.2030501@proseconsulting.co.uk> Date: Fri, 10 Jan 2014 14:36:45 +0000 From: Mark R Bannister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Luke Howard References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk> <52CFFEAC.7070208@proseconsulting.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailcore-Auth: 12040446 X-Mailcore-Domain: 1286164 Cc: Ldapext , Andrew Findlay , =?ISO-8859-1?Q?Mich?= =?ISO-8859-1?Q?ael_Str=F6der?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:37:22 -0000 On 10/01/2014 14:15, Luke Howard wrote: >>> Every LDAP-aware client system that I have worked with can use the >>> bind operation as a means to validate passwords, so the only >>> possible excuse for exporting hashes is temporary support of >>> migrating systems. If you only allow the export of hashes that are >>> actually needed by the old non-LDAP systems then at least you are >>> not making matters worse than they were before the migration. >> Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords? If it can be done server-side there'll be no problem here and we need never expose the hashes to clients. > Active Directory cannot. > > -- Luke Thanks Luke. Everywhere I have seen UNIX accounts deployed on AD, Kerberos password authentication has been used, so in those places it would not be an issue. However, I cannot possibly know how many people out there rely on CRYPT hashes in AD attributes, and I'm not about to cut off the possibly of them migrating to DBIS. CRYPT will therefore have to remain as an option, although I'm perfectly happy to put stronger wording around it. So far I have written: While a DUA MAY implement any authentication password scheme supported by the DSA, it MUST support the CRYPT scheme for backwards compatibility, which is an implementation of the traditional UNIX crypt algorithm. However, it is RECOMMENDED that a more secure scheme is used. and ... Passwd and group database entries contain encrypted passwords and SHOULD be transmitted securely when transferred between DSA and DUA to prevent eavesdropping. A DUA SHOULD NOT allow a user to see any encrypted passwords except they MAY see the password on their own posixUserAccount entry in encrypted form. Open to suggestions on how to reword this. Best regards, Mark. From michael@stroeder.com Fri Jan 10 07:19:23 2014 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 DC97C1AE087 for ; Fri, 10 Jan 2014 07:19:23 -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 KwptPZMmZmhK for ; Fri, 10 Jan 2014 07:19:22 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id C100D1AE06F for ; Fri, 10 Jan 2014 07:19:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 39F0360790; Fri, 10 Jan 2014 16:19:10 +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 GtZxnIXGhRQz; Fri, 10 Jan 2014 16:19:04 +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 DC0806075E; Fri, 10 Jan 2014 15:19:03 +0000 (UTC) Message-ID: <52D00C43.1030108@stroeder.com> Date: Fri, 10 Jan 2014 16:05:39 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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 , ldapext@ietf.org References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <52CFFD80.6030600@proseconsulting.co.uk> In-Reply-To: <52CFFD80.6030600@proseconsulting.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090808030204010105090000" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:19:24 -0000 This is a cryptographically signed message in MIME format. --------------ms090808030204010105090000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > On 09/01/2014 15:48, Michael Str=F6der wrote: >> In my deployments I simply define additional (OpenLDAP) constraints fo= r those >> attributes (e.g. to enforce lower-case 'uid' values). >=20 > Hard to do with 'cn'. We had to invent a new custom attribute to repla= ce 'cn' > with. Not hard with OpenLDAP to restrict a 'cn' constraint to entries of a cert= ain object class. Other directory servers have similar constraint capabilitie= s too. Ciao, Michael. --------------ms090808030204010105090000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTEwMTUwNTM5WjAj BgkqhkiG9w0BCQQxFgQUFHa/vlBQg5zlNzwOU2VHaTDELF0wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAaLQSQZMhmtMgvPyVO+S0CDO0QzSpnkzF ktR+AYots5HT/j2BoAAT+um7D+KoLF2kv8tdH3e+kkqdNQJ9616wQq5DVNQlb5qVsHD63kUT LFHqrlU/4qqC+MyfBe5QOU8ed6/R64dDjuuYO8UWU5Try/2gvtxE2MMaD47n7ga/aHortvIy dalJ9jL5OJH06s0PtcKuLb6WcqJuy68Y1dVbaN+WkBPBUL6uMbZlY6Yj8rme4JJ3croI8Kt4 JIQFpqONa9EnE0Q71GtjeEDgSPr//eW28lWtAnCsaHegQeXSwC3iC5wUQEnkjrASrO1GcnxJ qbEeLTEU/EswrvwncpTpSgAAAAAAAA== --------------ms090808030204010105090000-- From michael@stroeder.com Fri Jan 10 07:19:28 2014 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 960851AE0AA for ; 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 ; 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 ; 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: =?ISO-8859-1?Q?Michael_Str=F6der?= 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:19:28 -0000 This is a cryptographically signed message in MIME format. --------------ms020109040206000906070903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark R Bannister wrote: > On 09/01/2014 14:50, Michael Str=F6der 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 requir= ed. >> AFAICS today nobody is seriously using LDAP with shadow attributes any= more. >=20 > 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 kn= ow it. >=20 > 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 imp= lemented. >>> Indeed, I agree, as stated earlier on I would whole-heartedly recomme= nd >>> 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 de= cide >> whether DBIS is just an improvement for 1. or a real innvotation for 2= =2E >=20 > 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 h= ave 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 en= try. I'd go for a DN reference so you can make use of deref control. Ciao, Michael. --------------ms020109040206000906070903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTEwMTUxMDE0WjAj BgkqhkiG9w0BCQQxFgQU6M0u8Uyu0jJCTkwTN+S3IcA759IwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAlJR+54ZdAiaGl7+uBV3Fs1W6OgiQFZqs 3hzS7rL8ygbHnNdfQa8+xMcTOxISLrUpqTp+b/7N0LQLSkK/C7NfGCp5dYAhovCaI/q884QC XE9fY//vmcJiPx2IMO4h/ZU6AfT0iIad9lgJdnalYQ+gRRFrEbRaRJ+YnIOb6nVLLzD+2ppo lSD7Yptg/gzobK1zxLkJfhS9L3+fUQy9YVTsKtpUoyaieEDEMwS6f86WCjoRGjBcUI1phHSe O3VdQGXVu9F7q4QQsJOkVHqVUHqMENpg6SNdcvbub8Tm6fjxVcz+P8Em/zDFkeASoKUFwtrs 5TyKY48DmPta3fjcOOW5cgAAAAAAAA== --------------ms020109040206000906070903-- From andrew.findlay@skills-1st.co.uk Fri Jan 10 09:37:45 2014 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 32D391ADFA4 for ; Fri, 10 Jan 2014 09:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 rR1w36_JbX6n for ; Fri, 10 Jan 2014 09:37:43 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id 2044B1ADF30 for ; Fri, 10 Jan 2014 09:37:43 -0800 (PST) Received: from 9.d.e.2.e.6.a.d.5.9.e.0.f.9.4.9.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:949f:e95:da6e:2ed9] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W1g1T-0008Cp-PL; Fri, 10 Jan 2014 17:37:31 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1W1g1T-0007Ea-9u; Fri, 10 Jan 2014 17:37:31 +0000 Date: Fri, 10 Jan 2014 17:37:31 +0000 From: Andrew Findlay To: Luke Howard Message-ID: <20140110173731.GA3938@slab.skills-1st.co.uk> References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk> <52CFFEAC.7070208@proseconsulting.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: Ldapext , Michael =?iso-8859-1?Q?Str=F6der?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:37:45 -0000 On Sat, Jan 11, 2014 at 01:15:03AM +1100, Luke Howard wrote: > > Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords? If it can be done server-side there'll be no problem here and we need never expose the hashes to clients. > > Active Directory cannot. True, but there are many things that Active Directory cannot do. It is not a general-purpose LDAP server: it is a proprietary database that happens to support an LDAP access method. As for CRYPT (at least the traditional 13-character DES version) in other servers: OpenLDAP yes IBM Tivoli Directory Server yes 389 yes OpenDJ yes Sun/Oracle DSEE yes Oracle OID yes Isode M-Vault yes ApacheDS yes Lotus Domino very unlikely The only server that I have not been able to find a clear statement of CRYPT support for is Lotus Domino - and like AD, that is really not intended as a general-purpose LDAP server. Of course these days we are not just talking about 13-character CRYPT in migration jobs. Any decent Unix-like system released in the past decade or two is likely to use a stronger hash algorithm in /etc/shadow. Support for those is much more restricted, and normally depends on the underlying OS to supply the hashing code. Some of the enterprise distros have only gained support for my preferred hash algorithms in the past couple of years, so running LDAP servers on older enterprise OSs can be rather limiting. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From andrew.findlay@skills-1st.co.uk Fri Jan 10 09:44:24 2014 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 6C3E61AE108 for ; Fri, 10 Jan 2014 09:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 n13iRhscV7Hs for ; Fri, 10 Jan 2014 09:44:22 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id BCD6B1AE074 for ; Fri, 10 Jan 2014 09:44:22 -0800 (PST) Received: from 9.d.e.2.e.6.a.d.5.9.e.0.f.9.4.9.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:949f:e95:da6e:2ed9] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W1g7w-0008GP-44; Fri, 10 Jan 2014 17:44:12 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from ) id 1W1g7v-0007Ew-Lm; Fri, 10 Jan 2014 17:44:11 +0000 Date: Fri, 10 Jan 2014 17:44:11 +0000 From: Andrew Findlay To: Mark R Bannister Message-ID: <20140110174411.GB3938@slab.skills-1st.co.uk> References: <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk> <52CFFEAC.7070208@proseconsulting.co.uk> <52D0057D.2030501@proseconsulting.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D0057D.2030501@proseconsulting.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Cc: Luke Howard , Ldapext , Michael =?iso-8859-1?Q?Str=F6der?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:44:24 -0000 On Fri, Jan 10, 2014 at 02:36:45PM +0000, Mark R Bannister wrote: > While a DUA MAY implement any authentication password scheme > supported by the DSA, it MUST support the CRYPT scheme for backwards > compatibility, which is an implementation of the traditional UNIX > crypt algorithm. However, it is RECOMMENDED that a more secure > scheme is used. Is it really necessary for client code to get involved with this at all? > Passwd and group database entries contain encrypted passwords and > SHOULD be transmitted securely when transferred between DSA and DUA > to prevent eavesdropping. A DUA SHOULD NOT allow a user to see any > encrypted passwords except they MAY see the password on their own > posixUserAccount entry in encrypted form. Don't rely on the DUA (client code) to protect data from the user. That's just saying "here is a bit of paper with a secret on the other side; please don't turn it over". The person currently looking at the screen may not be the person who logged in... Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From michael@stroeder.com Fri Jan 10 11:24:49 2014 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 3A2201AE073 for ; Fri, 10 Jan 2014 11:24:49 -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 Nmd2x7wyWzP0 for ; Fri, 10 Jan 2014 11:24:47 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 942E31ADFF3 for ; Fri, 10 Jan 2014 11:24:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 695D860818; Fri, 10 Jan 2014 20:24:35 +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 OIl2CZ3THU9f; Fri, 10 Jan 2014 20:24:31 +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 7412E6075E; Fri, 10 Jan 2014 19:24:30 +0000 (UTC) Message-ID: <52D048E9.1060503@stroeder.com> Date: Fri, 10 Jan 2014 20:24:25 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= 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: Andrew Findlay References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk> <52CFFEAC.7070208@proseconsulting.co.uk> <20140110173731.GA3938@slab.skills-1st.co.uk> In-Reply-To: <20140110173731.GA3938@slab.skills-1st.co.uk> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000006010700060604020605" Cc: Ldapext 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:24:49 -0000 This is a cryptographically signed message in MIME format. --------------ms000006010700060604020605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > Lotus Domino very unlikely >=20 > The only server that I have not been able to find a clear > statement of CRYPT support for is Lotus Domino - and like AD, that > is really not intended as a general-purpose LDAP server. Domino/LDAP uses its own password attribute for LDAP simple bind with the= so-called "Domino HTTP password". Ciao, Michael. --------------ms000006010700060604020605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTEwMTkyNDI1WjAj BgkqhkiG9w0BCQQxFgQUXPy1ynr5XCyCbQ06L9M7YeA3vJUwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAndE2r3yo91y4ss5mZCWMxauihrX8z8K7 aTOPDg0i7zH7AYQOrMrGh1VKrzwqWMvKXEUdnsSwWJsrGbfGhWi/1Tn4z1+i/fwL9MW2QiHn T55uWGhow6NN+JD2mO9NPgv3OWbqpOYCQkPyfTAI+DK0HmznrSzpN9f79nJDej3lFcopPsUi EGlobcmrL4CXGFygdilDOBEG5HDPmCJF+EIfjAOBBOqTJqz+QWxD6FdcDv8l5stAsrcTemva V6CQ14mF3GjArSsYzQWwiGa3zYnNwSrrVXrUDdowsPiINoHPf5O0S/GgkMNj2T6dmlm1NX3b 4SFxjQrNWNNu/239ibE2RAAAAAAAAA== --------------ms000006010700060604020605-- From michael@stroeder.com Fri Jan 10 11:32:52 2014 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 B326C1AE0F3 for ; Fri, 10 Jan 2014 11:32:51 -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 qCfhacRn15tt for ; Fri, 10 Jan 2014 11:32:49 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3191AE058 for ; Fri, 10 Jan 2014 11:32:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 61A3760818; Fri, 10 Jan 2014 20:32:38 +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 XSjlTDUlyvmH; Fri, 10 Jan 2014 20:32:32 +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 681D86075E; Fri, 10 Jan 2014 19:32:28 +0000 (UTC) Message-ID: <52D04AC6.4030507@stroeder.com> Date: Fri, 10 Jan 2014 20:32:22 +0100 From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 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: Simo References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <52CDA099.9070300@stroeder.com> <1389219912.27654.113.camel@pico.ipa.ssimo.org> <52CEE58C.7060304@stroeder.com> <1389299653.27654.130.camel@pico.ipa.ssimo.org> <52CF0A5C.5090002@stroeder.com> <1389302200.27654.136.camel@pico.ipa.ssimo.org> In-Reply-To: <1389302200.27654.136.camel@pico.ipa.ssimo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080608080404050907050101" Cc: ldapext@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 19:32:52 -0000 This is a cryptographically signed message in MIME format. --------------ms080608080404050907050101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simo wrote: > On Thu, 2014-01-09 at 21:45 +0100, Michael Str=C3=B6der wrote: >> Simo wrote: >>> On Thu, 2014-01-09 at 19:08 +0100, Michael Str=C3=B6der wrote: >>>> Simo wrote: >>>>> The full schema definitions can be found here: >>>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60= basev2.ldif >>>> >>>> Looked at the schema: >>>> >>>> I'm a bit confused by some object classes directly referencing MAY m= emberOf. >>>> 'memberOf' is normally an operational attribute also in 389 DS isn't= it? >>> >>> It is a generated by the memberof plugin, it's semantics are differen= t >>> from other solutions (like AD), all descendants are resolved at modif= y >>> time. >> >> Really different semantics? >> >> AFAIK memberOf should be a simple back-link from the member's entry to= the >> group entry. When the attribute value is actually created (on modify o= r on >> read) is not relevant for memberOf semantics. Or did I get you wrong? >=20 > It is not a backlink in FreeIPA. >=20 > If you have: > groupA: > member: GroupB >=20 > groupB: > member: userC >=20 > then userC's memberof is: >=20 > userC: > memberOf: groupA > memberOf: groupB >=20 > This makes initgroups a lot more efficient as it is a single dereferenc= e > search to get all groups a user directly or indirectly belongs to. (Sigh!) You took the attribute type NAME and OID from MS AD: ( 1.2.840.113556.1.2.102 NAME 'memberOf' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION ) But you've changed the semantics. In AD 'memberOf' does not(!) include ne= sted group membership. That's really bad practice and makes client developers live really misera= ble! Ciao, Michael. --------------ms080608080404050907050101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTEwMTkzMjIyWjAj BgkqhkiG9w0BCQQxFgQUCkIXo5Ns2+72kU4ayL0fZ4IwABUwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAROnPqhWp+jcjElDcuiIuKN4Yu8S98Dza Y4t2Y6dKQ6hLKdsY80U5YMb5QAZ6nOAhAEXPJbh9cgF1ZlgSp06sim0WY1LfefirRVxrnDsC sCphiDTCr058tc24jP4fVmKhKevVIw02uPKhsvbbE7uQrVC3D+fjERKkAOJ8Zl5gPoRO59Ur VCEHQ3ikp5h2zmU0iJIBIvUg2NgIL5cn9kF2dR2mHpDPSqRIc6aavoeM57iN1M0jjaJdN0O0 rThITr9YkmcXpU55Waal3ZlpM69OgeO7gBbknvqTW5Qc1DBDvBwkl4hIHk1Ywfa2oVCiGKXR t0/f0ImFDp8FzA27cBb7ngAAAAAAAA== --------------ms080608080404050907050101-- From hyc@highlandsun.com Sun Jan 12 19:00:04 2014 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 0E2561AD8DC for ; Sun, 12 Jan 2014 19:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 4VT7_4JUaxE0 for ; Sun, 12 Jan 2014 19:00:02 -0800 (PST) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id 500C71AD8C4 for ; Sun, 12 Jan 2014 19:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 43A8584ECD; Sun, 12 Jan 2014 21:59:49 -0500 (EST) Message-ID: <52D356A4.3010508@highlandsun.com> Date: Sun, 12 Jan 2014 18:59:48 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1 MIME-Version: 1.0 To: Charlie , Mark R Bannister , ldapext References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 03:00:04 -0000 Charlie wrote: > What I have learned from about a decade of quietly following LDAP > across multiple forums and lists is the following: > 2) POSIX group semantics are the bane of open-source LDAP. The > functional paradigm that a member is an attribute of a group is > fundamentally broken; group membership is an attribute of the member. > The security concerns frequently raised concerning this are all either > trivially solvable or pragmatically completely bogus. Sorry but that makes no sense. It's the same as saying 'element e is a member of set S' is true but 'set S contains element e' is false. If one is true then both must be true. Of course there are two different ways to view it. From a sysadmin's point of view, what is important is knowing which users are the member of a group. From an individual user's point of view, knowing which groups they belong to is more important. In real life, users will login many times more frequently than sysadmins will manipulate group memberships, so you may decide that optimizing for the user check is more important. But while sysadmin manipulation may be infrequent, the consequences of making a mistake are high, so data models up till now have been designed to make the sysadmin view more straightforward. Complexity for the user's perspective is simple to automate and never have to worry about ever again. I think it would be a mistake to lose sight of this distinction. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From medievalist@gmail.com Mon Jan 13 09:21:23 2014 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 B62DC1AE19C for ; Mon, 13 Jan 2014 09:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, SPF_PASS=-0.001] 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 WW0KVMNQw06C for ; Mon, 13 Jan 2014 09:21:21 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CC7BB1ADFD4 for ; Mon, 13 Jan 2014 09:21:20 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id p9so3647624lbv.5 for ; Mon, 13 Jan 2014 09:21:09 -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:cc :content-type; bh=BDmhmgeynVvu1NN6HFbcTKQUEWDE8cSD3fxY8i4qOho=; b=OULhnjaLw2kQby4HdbWn44XQZ4lRqQ4Oma9C6VudPJoBMrwKkU1WnGVzOBDCNKn0d9 drDPOhmRQU+o3PTvg1uCYq4AVoJoUWJp65bGHBiVIuzwpCAeWjPIn+duixo1A4ey0ZHl tJD4NYUMn0oK28utiMcu+I7a1Xms0fyLel9cpmWXwqIKR1BWtMqttaMzzTFLRbvWm4bc Mj8haWGW0sFsaylZcNNd9gq4LDT3/r3981Wt4S01it1EFQkrt8edh0f6bdzN6lB2Ka/d cNAxBbu5UZmcA/mAyIyK0YlH0KCySvLIBPGhykyrq9ZWdduF9vt1sQlL/DWDzKDtgl/3 IOZg== MIME-Version: 1.0 X-Received: by 10.152.170.168 with SMTP id an8mr4775890lac.39.1389633666619; Mon, 13 Jan 2014 09:21:06 -0800 (PST) Received: by 10.112.141.65 with HTTP; Mon, 13 Jan 2014 09:21:06 -0800 (PST) In-Reply-To: <52D356A4.3010508@highlandsun.com> References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CD9F94.2090707@stroeder.com> <52CDC249.8050407@proseconsulting.co.uk> <52D356A4.3010508@highlandsun.com> Date: Mon, 13 Jan 2014 12:21:06 -0500 Message-ID: From: Charlie Cc: ldapext Content-Type: text/plain; charset=ISO-8859-1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 17:21:23 -0000 I (Charlie) said: > 2) POSIX group semantics are the bane of open-source LDAP. The > functional paradigm that a member is an attribute of a group is > fundamentally broken; group membership is an attribute of the member. > The security concerns frequently raised concerning this are all either > trivially solvable or pragmatically completely bogus. Howard replied: >Sorry but that makes no sense. It's the same as saying 'element e is a member of set S' >is true but 'set S contains element e' is false. If one is true then both must be true. Perhaps I'm not conveying the concept well. I'm talking about how something is expressed and the results certain semantics actually have on real life, on real human endeavors. I'm not talking about the academic equivalency of two forms of symbolic expression. But it's true that it's no more difficult to add a "memberOf" attribute to an object than it is to add a "Member" attribute to another object. The spurious efficiency of querying LDAP for a member list (at least one member of which will be queried *again* nearly one hundred percent of the time) instead of querying against a membership filter is a mental bugaboo that has retarded progress in LDAP-capable directory software. POSIX group lists are an ill-considered hack that somebody (I think Ritchie) haphazardly pasted onto Unix when they were still trying to interact with GECOS systems. They infect the filesystem paradigm and the user management paradigm and make *nix lamer than it needs to be. They discourage group nesting and just-in-time resolution and other desirable practices that exist in the real world that directories are trying to usefully represent. Their flat list design ignores human psychological and empirical organizational realities. Dynamic groups and/or stored group queries are better, although I've never seen an optimal implementation of either. The groups that people REALLY need to represent in their directories are things like "the set of people on site competent to reconstitute the threadline" and "the set of employees accessing the reactor robotics right now" and "the set of objects in route to Dusseldorf". Enterprise directories that try to accurately model reality as it exists will be far more pragmatically useful than those that simply regurgitate inherently error-prone and outdated static lists. POSIX groups suck. They are the second worst thing in *nix. OK, maybe the 3rd. A directory should never model /etc/groups... yes, it should be able to generate group lists for POSIX compatibility, but internally a directory should attempt a more powerful cognitive model than a grocery list. If people want to discuss this more, please split the topic off from Mr. Bannister's thread or contact me privately, since he's already replied to my post. --Charlie