Re: [ldapext] DBIS - new IETF drafts

[Ludovic Poitou <[e-mail]>]

> Michael Ströder <mailto:[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ldapext
> Mark R Bannister <mailto:[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ldapext
> Howard Chu <mailto:[e-mail]>
> 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 <mailto:[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ldapext
> Howard Chu <mailto:[e-mail]>
> 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
>