Michael Ströder | 26 Sep 14:23 2014

Revive ldapext WG?

HI!

AFAICS independent draft submissions can only reach informational or
experimental status.

But I think it should be possible to reach standard status for some important
drafts (like ppolicy draft as discussed at LDAPcon 2013).

What do you think about it?
Should IETF WG ldapext should be revived?

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 5750 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 26 Sep 14:15 2014

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

HI!

I've sent this draft to the RFC editor for review.
Anyone here willing to act as reviewer?

Still sorting out some idnits issues for next version but those are only minor
details.

Ciao, Michael.

-------- Forwarded Message --------
Subject: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt
Date: Fri, 26 Sep 2014 04:59:34 -0700
From: internet-drafts <at> ietf.org
To: Michael Stroeder <michael <at> stroeder.com>, Michael Stroeder
<michael <at> stroeder.com>

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

Name:		draft-stroeder-mailboxrelatedobject
Revision:	06
Title:		Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class
'mailboxRelatedObject'
Document date:	2014-09-26
Group:		Individual Submission
Pages:		5
URL:
http://www.ietf.org/internet-drafts/draft-stroeder-mailboxrelatedobject-06.txt
(Continue reading)

Michael Ströder | 22 Sep 09:24 2014

Server implementations of Don't Use Copy control?

HI!

Which LDAP server implement Don't Use Copy control as defined in RFC 6171?
For which use-cases?

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Michael Ströder | 22 Sep 09:26 2014

Server implementations of LDAP transactions?

HI!

Which LDAP servers have support LDAP transactions as defined in RFC 5805?
Is it used with any particular use-cases?

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 3244 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Sean Leonard | 11 Sep 21:49 2014

New Version Notification for draft-seantek-ldap-pkcs9-00.txt

Hello ldapext list:

I posted this proposal to add definitions to the IANA registry. These 
definitions are from PKCS #9, which predates ldapext. However, the 
definitions in PKCS #9 never got added. This document adds them.

Feedback is requested, as well as suggestions on how best to proceed 
with this to get IETF consensus.

Thanks,

Sean

******
A new version of I-D, draft-seantek-ldap-pkcs9-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-ldap-pkcs9
Revision:	00
Title:		Lightweight Directory Access Protocol (LDAP) Registrations for 
PKCS #9
Document date:	2014-09-10
Group:		Individual Submission
Pages:		6
URL: 
http://www.ietf.org/internet-drafts/draft-seantek-ldap-pkcs9-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/
Htmlized:       http://tools.ietf.org/html/draft-seantek-ldap-pkcs9-00

(Continue reading)

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

Gmane