Mark R Bannister | 14 Apr 01:07 2015
Picon

Comparing RFC2307, RFC2307bis and DBIS

I've now written up what I hope is a comprehensive comparison of 
RFC2307, RFC2307bis and DBIS (a proposed replacement for them).

I was motivated to do this after talking recently with some software 
vendors who seemed to misunderstand DBIS, thinking that they could get 
all the benefits of DBIS from their RFC2307 client software just by 
remapping some attributes.  The write-up below should hopefully shed 
more light on what you can do, what you can't do, and why DBIS is a big 
improvement over RFC2307 or RFC2307bis.

Feature comparison:
https://sourceforge.net/p/dbis/wiki/DBIS%20and%20RFC2307%20-%20A%20Comparison/

Schema comparison:
https://sourceforge.net/p/dbis/wiki/DBIS%20and%20RFC2307%20schemas/

Comments welcome as always.  Note that DBIS is still a work in progress, 
and I will gladly receive and consider feature requests. I'm also 
looking for individuals who can test DBIS on other platforms and provide 
patches where necessary, as I only have access to OpenSuSE, RHEL and 
Solaris hosts.

Best regards,
Mark Bannister.
Clément OUDOT | 18 Mar 10:37 2015
Picon

Working on password policy standardization

Hello,

following the mail of Ludovic requesting for help on drafts
standardization, and as proposed by Michael, I would like to start a
discussion on the password policy subject.

As a disclaimer, I would like to say that I never worked on publishing
drafts or RFC, it is my first attempt here. So please feel free to
point out all the mistakes I could do to help me improve this work.

1/ Current situation

We have two drafts on the subject:
* draft-behera-ldap-password-policy-10
* draft-zeilenga-ldap-passwords-00

I join them to this message.

As far as I know, the only implemented draft is the Behera draft, but
only in version 9. This is implemented at least in OpenLDAP, but also
in OpenDJ and ApacheDS (needs confirmation).

2/ Main drawbacks

A list of drawbacks of the Behera draft is presented in Zeilinga draft
in Appendix A. I will not reproduce them all here but focus on the
most important (from my point of view):
* The lock/unlock feature for directory administrators is not clear,
and relies on an operational attributes (pwdAccountLockedTime) that
should not be written by administrators
(Continue reading)

Michael Ströder | 11 Feb 12:24 2015

Re: Schema for posixGroup successor (RFC 2307 bis)

Simo wrote:
> On Wed, 2015-02-11 at 10:58 +0100, Michael Ströder wrote:
>> Since Kurt expressed to follow very strict guide lines forbidding altering
>> existing NAMEs and OIDs of schema descriptions especially in RFC 2307 the
>> question is how to define a new object class for POSIX groups in RFC 2307bis
>>
>> To preserve backwards compability I'd like to propose the following:
>>
>> ( <OID TBD>
>>   NAME 'posixGroup2'
>>   DESC '<TBD>'
>>   SUP ( groupOfEntries $ posixGroup )
>>   STRUCTURAL )
>>
>> With this definition..
>>
>> 1. posixGroup2 would have 'member' and 'memberUID' both as optional attributes,
>>
>> 2. the object class still can be found with (objectClass=posixGroup) and
>>
>> 3. the object class is STRUCTURAL and therefore one can assign a specific DIT
>> content rule to it allowing to preclude either 'member' or 'memberUID' with
>> NOT to meet local system requirements.
>>
>> 4. there's no conflict on LDAP servers with the old RFC 2307 schema already added.
>>
>> What do others think about this approach?
> 
> I'd call it posixGroupBis, but otherwise sounds like a good idea.

(Continue reading)

Michael Ströder | 11 Feb 10:58 2015

Schema for posixGroup successor (RFC 2307 bis)

HI!

Since Kurt expressed to follow very strict guide lines forbidding altering
existing NAMEs and OIDs of schema descriptions especially in RFC 2307 the
question is how to define a new object class for POSIX groups in RFC 2307bis

To preserve backwards compability I'd like to propose the following:

( <OID TBD>
  NAME 'posixGroup2'
  DESC '<TBD>'
  SUP ( groupOfEntries $ posixGroup )
  STRUCTURAL )

With this definition..

1. posixGroup2 would have 'member' and 'memberUID' both as optional attributes,

2. the object class still can be found with (objectClass=posixGroup) and

3. the object class is STRUCTURAL and therefore one can assign a specific DIT
content rule to it allowing to preclude either 'member' or 'memberUID' with
NOT to meet local system requirements.

4. there's no conflict on LDAP servers with the old RFC 2307 schema already added.

What do others think about this approach?

Ciao, Michael.

(Continue reading)

Mark R Bannister | 1 Feb 23:33 2015
Picon

Re: LDAP work at IETF...

On 28/01/2015 14:14, Simo wrote:
> On Tue, 2015-01-27 at 20:50 +0000, Mark R Bannister wrote:
>> On 27/01/2015 15:47, Michael Ströder wrote:
>>> Mark R Bannister wrote:
>>>> The following internet drafts are intended to replace RFC2307 and RFC2307bis.
>>>> [..]
>>>> draft-bannister-dbis-mapping
>>>> draft-bannister-dbis-netgroup
>>>> draft-bannister-dbis-passwd
>>>> draft-bannister-dbis-hosts
>>>> draft-bannister-dbis-devices
>>>> draft-bannister-dbis-automounter
>>>> draft-bannister-dbis-custom
>>>> [..]
>>>> I would prefer to see RFC2307bis removed from the list to be considered above,
>>>> and replaced by the DBIS drafts.
>>> This probably won't happen because there are so many RFC2307(bis) deployments
>>> out there which cannot easily be migrated.
>> DBIS supports maps defined in legacy RFC2307 or RFC2307bis format, as
>> well as using the new format.  Migration is designed to be extremely
>> easy.  In fact, it took me next to no time at all to start using
>> directory entries defined in RFC2307 format from a DBIS installation, it
>> really is just a matter of defining a few configuration maps that do the
>> class and attribute remappings, and they are mostly standard.  See
>> https://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/
>>
>>> Also I have my own schema built on top of RFC2307bis (not published yet) which
>>> differs much from DBIS for very good reasons. I aim to present it at LDAPcon
>>> 2015 in Edinburgh (in case the program comittee agrees). A preview version of
>>> that is already in production for almost a year in a large data center.
(Continue reading)

Andrew Findlay | 29 Jan 14:49 2015
Picon

LDAPCon 2015 Call for Papers

LDAPCon 2015
============

The fifth International Conference on LDAP and Directory Services will be
held in the UK at the University of Edinburgh School of Informatics Forum.

Tutorials: 11th November 2015
Conference: 12th and 13th November 2015

Call for papers and tutorials
=============================

Topics

    You are using LDAP in interesting projects?
    You do LDAP client or server development?
    You have used LDAP in a new way?
    You have a proposal for a new LDAP standard?
    You do identity and access management on top of LDAP?

Why not share your ideas and experiences with others?

We are looking for speakers who are willing to talk about any topic
related to LDAP and identity management, including:

    LDAP technology implementation (Servers, API, User interfaces etc.)
    LDAP Usage (Schema, Security, Operations, Scaling, big data, etc.)
    LDAP related technologies (PKI, XACML, SAML, etc.)
    LDAP and Beyond (IAM, Identity Federation, Authentication on the web, etc.)
    Best Practices for directory services.
(Continue reading)

Ludovic Poitou | 25 Jan 21:36 2015
Picon

LDAP work at IETF...

 
Hi Everyone,

Over the years, there has been a number of documents related to the Lightweight Directory Access Protocol
(LDAP) that have been left unfinished or are slowly progressing.  

There are a number of individuals that have interest in re-forming an IETF Working Group around LDAP to
finish some of the work and make them on the Standard Track. Howard Chu and I are ready to lead that effort.  

I’d like to poll the audience of this mailing list on the interest of seeing this progressing. I would also
like to hear about volunteers to work on those documents, either contributing text or reviewing them
carefully.  

Please find below the list of documents that have been considered for the working group to finalise and get
published (in no specific order):  

draft-findlay-ldap-groupofentries  
draft-stroeder-namedobject  
draft-stroeder-hashed-userpassword-values (informational
draft-stroeder-mailboxrelatedobject  
RFC2307bis  
draft-behera-ldap-password-policy  
inetOrgPerson 2.0  

Ludovic  

--  
Ludovic Poitou
http://ludopoitou.wordpress.com

(Continue reading)

Michael Ströder | 23 Jan 17:22 2015

Re: LDAP work at IETF...

Ludovic Poitou wrote:
> Please find below the list of documents that have been considered for the
> working group to finalise and get published (in no specific order):

For a WG we probably have to write a charter.
Who's willing to draft one?

> draft-stroeder-namedobject 
> draft-stroeder-hashed-userpassword-values (informational
> draft-stroeder-mailboxrelatedobject 

Obviously I'm interested to proceed with these drafts under the umbrella of a
new/revived LDAP WG within IETF.

> RFC2307bis 

Recent work also raised my interested to get this in a really good shape as a
possible base line for more sophisticated approaches like DBIS or Æ-DIR (TBR).
So I'd be willing to act as an editor if Howard does not have the time for it.
Kurt recently raised the bar regarding IANA considerations though.

> draft-behera-ldap-password-policy

We already shortly discussed this at LDAPcon 2013. Anyone here?

> inetOrgPerson 2.0

This will be surely a larger work item with a lot of different opinions
(although most people are missing the same things).

(Continue reading)

Michael Ströder | 14 Dec 17:10 2014

why posixAccount MUST contain 'cn'?

HI!

Is there any strong reason why auxiliary object class 'posixAccount' has
defined 'cn' as being a mandatory attribute?

I'd be in favour of relaxing this to MAY cn in RFC2307bis.

Also what's the distinction of 'cn' and 'gecos' in 'posixAccount'. It seems
most NSS LDAP clients use attribute 'cn' as gecos field today.

Ciao, Michael.

Attachment (smime.p7s): application/pkcs7-signature, 5750 bytes
_______________________________________________
Ldapext mailing list
Ldapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
Sean Leonard | 13 Nov 02:51 2014

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

I added a discussion of privacy issues. That’s about it.

Begin forwarded message:

> From: internet-drafts <at> ietf.org
> Subject: New Version Notification for draft-seantek-ldap-pkcs9-02.txt
> Date: November 12, 2014 at 3:38:40 PM HST

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

Name:		draft-seantek-ldap-pkcs9
Revision:	02
Title:		Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9
Document date:	2014-11-12
Group:		Individual Submission
Pages:		7
URL:            http://www.ietf.org/internet-drafts/draft-seantek-ldap-pkcs9-02.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/
Htmlized:       http://tools.ietf.org/html/draft-seantek-ldap-pkcs9-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-seantek-ldap-pkcs9-02

Abstract:
  PKCS #9 includes several useful definitions that are not yet
  reflected in the LDAP IANA registry. This document adds those
  definitions to the IANA registry.

The IETF Secretariat
(Continue reading)

Sean Leonard | 26 Oct 23:59 2014

Fwd: New Version Notification for draft-seantek-ldap-pkcs9-01.txt

Hello ldapext:

draft-seantek-ldap-pkcs9 has been updated per the e-mail thread on the topic of “dateOfBirth”, among other things.

Some may disagree with the resolution presented in the new Section 4.1. I am happy write in whatever is the IETF Consensus on the matter.

Sean

Begin forwarded message:

Subject: New Version Notification for draft-seantek-ldap-pkcs9-01.txt
Date: October 26, 2014 at 3:56:06 PM PDT
To: Sean Leonard <dev+ietf <at> seantek.com>, "Sean Leonard" <dev+ietf <at> seantek.com>


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

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

Abstract:
  PKCS #9 includes several useful definitions that are not yet
  reflected in the LDAP IANA registry. This document adds those
  definitions to the IANA registry.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Gmane