Michael Ströder | 10 Jan 20:32 2014

Re: DBIS - new IETF drafts

Simo wrote:
> On Thu, 2014-01-09 at 21:45 +0100, Michael Ströder wrote:
>> Simo wrote:
>>> On Thu, 2014-01-09 at 19:08 +0100, Michael Ströder wrote:
>>>> Simo wrote:
>>>>> The full schema definitions can be found here:
>>>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60basev2.ldif
>>>>
>>>> Looked at the schema:
>>>>
>>>> I'm a bit confused by some object classes directly referencing MAY memberOf.
>>>> '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 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 the
>> group entry. When the attribute value is actually created (on modify or on
>> read) is not relevant for memberOf semantics. Or did I get you wrong?
> 
> It is not a backlink in FreeIPA.
> 
> If you have:
> groupA:
>    member: GroupB
> 
> groupB:
(Continue reading)

Mark R Bannister | 10 Jan 15:13 2014
Picon

Re: DBIS - new IETF drafts

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
(Continue reading)

Michael Ströder | 10 Jan 11:40 2014

Re: DBIS - new IETF drafts

Simo wrote:
> On Thu, 2014-01-09 at 21:36 +0100, Michael Ströder wrote:
>> Simo wrote:
>>> On Thu, 2014-01-09 at 16:48 +0100, Michael Ströder wrote:
>>>> 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.
>>>
>>> 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.
> 
> It's an 80/20 thing, the most common case is 2 levels deep, so the worst
> case is not usually a big issue.

But if you don't enforce the 2-level-nested-groups limit the client has to
search for nested groups and deref control does not help.

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
(Continue reading)

Michael Ströder | 9 Jan 21:45 2014

Re: DBIS - new IETF drafts

Simo wrote:
> On Thu, 2014-01-09 at 19:08 +0100, Michael Ströder wrote:
>> Simo wrote:
>>> The full schema definitions can be found here:
>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60basev2.ldif
>>
>> Looked at the schema:
>>
>> I'm a bit confused by some object classes directly referencing MAY memberOf.
>> '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 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 the
group entry. When the attribute value is actually created (on modify or on
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.
> 
> Not sure where's the confusion.

I'm confused by seeing an operational attribute like 'memberOf' being defined
in user schema.

Ciao, Michael.
(Continue reading)

Michael Ströder | 9 Jan 21:36 2014

Re: DBIS - new IETF drafts

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.
> 
> - 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.
> 
> - 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 ?
(Continue reading)

Michael Ströder | 9 Jan 19:08 2014

Re: DBIS - new IETF drafts

Simo wrote:
> The full schema definitions can be found here:
> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60basev2.ldif

Looked at the schema:

I'm a bit confused by some object classes directly referencing MAY memberOf.
'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 reason
to do so.

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Mark R Bannister | 8 Jan 21:36 2014
Picon

Re: DBIS - new IETF drafts

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 
(Continue reading)

Mark R Bannister | 6 Jan 22:29 2014
Picon

Re: DBIS - new IETF drafts

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 
(Continue reading)

Mark R Bannister | 5 Jan 21:21 2014
Picon

DBIS - new IETF drafts

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 <at> proseconsulting.co.uk
Michael Ströder | 8 Aug 09:24 2013

Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-04.txt

HI!

Some modifications based on comments I received off-list.

Please review this draft intended to be published as informational RFC.
Thanks in advance.

Ouch! There's a typo in DESC of object class definition. Will change this to
RFC 2821 in next version.

Ciao, Michael.

-------- Original Message --------
Subject: New Version Notification for draft-stroeder-mailboxrelatedobject-04.txt
Date: Thu, 08 Aug 2013 00:20:29 -0700
From: internet-drafts <at> ietf.org
To: Michael Stroeder <michael <at> stroeder.com>

A new version of I-D, draft-stroeder-mailboxrelatedobject-04.txt
has been successfully submitted by Michael Stroeder and posted to the
IETF repository.

Filename:	 draft-stroeder-mailboxrelatedobject
Revision:	 04
Title:		 Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class
'mailboxRelatedObject'
Creation date:	 2013-08-08
Group:		 Individual Submission
Number of pages: 5
URL:
(Continue reading)

Michael Ströder | 7 Aug 20:56 2013

draft-stroeder-mailboxrelatedobject-03.txt

HI!

Please review this draft intended to be published as informational RFC.
Thanks in advance.

Ciao, Michael.

-------- Original Message --------
Subject: ***UNCHECKED*** New Version Notification for
draft-stroeder-mailboxrelatedobject-03.txt
Date: Wed, 07 Aug 2013 11:54:54 -0700
From: internet-drafts <at> ietf.org
To: Michael Stroeder <michael <at> stroeder.com>

A new version of I-D, draft-stroeder-mailboxrelatedobject-03.txt
has been successfully submitted by Michael Stroeder and posted to the
IETF repository.

Filename:	 draft-stroeder-mailboxrelatedobject
Revision:	 03
Title:		 Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class
'mailboxRelatedObject'
Creation date:	 2013-08-07
Group:		 Individual Submission
Number of pages: 4
URL:
http://www.ietf.org/internet-drafts/draft-stroeder-mailboxrelatedobject-03.txt
Status:
http://datatracker.ietf.org/doc/draft-stroeder-mailboxrelatedobject
Htmlized:        http://tools.ietf.org/html/draft-stroeder-mailboxrelatedobject-03
(Continue reading)


Gmane