Subject: [ldapext] why posixAccount MUST contain 'cn'?

From: Michael Ströder <[email-masked]>
Date: Sun, 14 Dec 2014 17:10:36 +0100

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.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 14 Dec 2014 08:43:19 -0800

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

See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changing previously published schema definitions.

---

From: Michael Ströder <[email-masked]>
Date: Sun, 14 Dec 2014 18:35:13 +0100

> See BCP 118 [RFC 4521], Section 5 concerning IETF rules for changing previously published schema definitions.

Yes, but RFC2307bis also changes posixGroup schema.

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 14 Dec 2014 10:50:07 -0800

> On Dec 14, 2014, at 9:35 AM, Michael Ströder <[email-masked]> wrote:
> 
> Kurt Zeilenga wrote:

Don’t expect I-Ds which violate BCPs to become RFCs.

— Kurt

> 
> Ciao, Michael.
> 
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Sun, 14 Dec 2014 20:42:38 +0100

> Don’t expect I-Ds which violate BCPs to become RFCs.

Are you saying that draft-howard-rfc2307bis will never become an RFC because
it changes the declaration of 'posixGroup' ('member' instead of 'memberUID')
defined in the experimental RFC 2307?

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 14 Dec 2014 12:05:11 -0800

> On Dec 14, 2014, at 11:42 AM, Michael Ströder <[email-masked]> wrote:
> 
> Kurt Zeilenga wrote:
>> 

I won’t say “never” as well BCPs themselves are subject today…   but I can tell you that I, as the IESG’s appointed LDAP registries expert to IANA, have and will reject requests to register LDAP parameters which purport to modify previously published LDAP schema definitions.  Of course, such actions are appealable.

— Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 14 Dec 2014 12:06:04 -0800

> On Dec 14, 2014, at 12:05 PM, Kurt Zeilenga <[email-masked]> wrote:
> 
> 
> I won’t say “never” as well BCPs themselves are subject today…  
s/today/to change/

>  but I can tell you that I, as the IESG’s appointed LDAP registries expert to IANA, have and will reject requests to register LDAP parameters which purport to modify previously published LDAP schema definitions.  Of course, such actions are appealable.
> 
> — Kurt

---

From: Michael Ströder <[email-masked]>
Date: Sun, 14 Dec 2014 21:19:53 +0100

Kurt Zeilenga wrote:
> I won’t say “never” as well BCPs themselves are subject today…   but I can
> tell you that I, as the IESG’s appointed LDAP registries expert to IANA,
> have and will reject requests to register LDAP parameters which purport to
> modify previously published LDAP schema definitions.  Of course, such
> actions are appealable.

So RFC2307bis must start over with completely new NAMEs
for e.g. posixGroup?

(Personally I don't care about assigning a new OID because most LDAP client
implementations don't handle OIDs anyway.)

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 14 Dec 2014 13:11:02 -0800

> On Dec 14, 2014, at 12:19 PM, Michael Ströder <[email-masked]> wrote:
> 
> Kurt Zeilenga wrote:
>> 

Yes, as posixGroup has already been published, if you don’t want to use it as published, you need to create a replacement for it… and that replacement has to have a new OID and a new NAME.

- Kurt

---

From: Michael Ströder <[email-masked]>
Date: Sun, 14 Dec 2014 23:49:35 +0100

Kurt Zeilenga wrote:
> Yes, as posixGroup has already been published, if you don’t want to use it
> as published, you need to create a replacement for it… and that replacement
> has to have a new OID and a new NAME.

Hmm, I respect that decision and thanks for the clear words.

But it's clearly a problem with all the existing NSS LDAP client
implementations/deployments which already use RFC2307bis posixGroup>member
draft schema.

So the question is: How to correctly push that forward?

Some more nitpicking:
The RFC 2307 defined OIDs are not listed here only the base OID:
http://www.iana.org/assignments/ldap-parameters/ldap-parameters.xhtml

Ciao, Michael.

---

From: Hallvard Breien Furuseth <[email-masked]>
Date: Mon, 15 Dec 2014 01:17:28 +0100

On 14/12/14 17:10, Michael Ströder wrote:
> (...)

cn is UTF-8.  The gecos attribute is IA5 String - i.e. ASCII.
One of many ways rfc2307 does not fit the real world too well.
memberUid is another IA5 too, both it and uid are case-insensitive
even though rfc2307 is for case-sensitive Unix, etc.

---

From: Jim Willeke <[email-masked]>
Date: Mon, 15 Dec 2014 07:03:06 -0500

And then there is also...
http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html
ᐧ

--
-jim
Jim Willeke

---

From: Mark R Bannister <[email-masked]>
Date: Mon, 15 Dec 2014 22:04:24 +0000

On 15/12/2014 12:03, Jim Willeke wrote:
> ?
> On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Breien Furuseth 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

Indeed, as Jim pointed out, I have been working on a replacement for 
RFC2307 and RFC2307bis in my
spare time for over 18 months now.  I first released some new IETF 
drafts in August last year, and I've
just published the first working reference implementation this month.

Kurt - as LDAP registries expert would you help to shepherd these 
internet drafts through the IANA
publication process, as I'm not sure what my next step should be now?

In DBIS I have fixed the case insensitivity issues that were present in 
RFC2307, and I believe it is compliant
with BCP 118 [RFC 4521] section 5 as I use new names and OIDs for any 
attributes or object classes
that I needed to change.  I've introduced 'posixUserAccount' to replace 
'posixAccount' which does not
use 'cn', the gecos field can be set to point to any attribute you like, 
I've introduced 'posixGroupAccount'
to replace 'posixGroup', as well as a host of other improvements.

The drafts are:

draft-bannister-dbis-mapping 
<http://www.ietf.org/id/draft-bannister-dbis-mapping.txt> (DBIS Mapping 
Objects)
draft-bannister-dbis-netgroup 
<http://www.ietf.org/id/draft-bannister-dbis-netgroup.txt> (DBIS 
Netgroups and Netservices)
draft-bannister-dbis-passwd 
<http://www.ietf.org/id/draft-bannister-dbis-passwd.txt> (DBIS Users and 
Groups)
draft-bannister-dbis-hosts 
<http://www.ietf.org/id/draft-bannister-dbis-hosts.txt> (DBIS Hosts, 
Networks and Services)
draft-bannister-dbis-devices 
<http://www.ietf.org/id/draft-bannister-dbis-devices.txt> (DBIS Devices)
draft-bannister-dbis-automounter 
<http://www.ietf.org/id/draft-bannister-dbis-automounter.txt> (DBIS 
Automounter)
draft-bannister-dbis-custom 
<http://www.ietf.org/id/draft-bannister-dbis-custom.txt> (DBIS Custom Maps)

The intention is for these to obsolete RFC2307 and RFC2307bis.

Also of interest:

    * DBIS Reference Implementation on SourceForge <http://dbis.sf.net> 
(dbis.sf.net)
    * Three articles about DBIS from last year on my blog 
<http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html> 
(technicalprose.blogspot.co.uk)

The reference implementation works fine with Python 2.7 (tested on 
OpenSuSE 12.x), and I hope
to get it working on Python 2.6 this week or next (for RHEL 6 and 
Solaris 11 users).

Best regards,
Mark.

---

From: Charlie <[email-masked]>
Date: Tue, 16 Dec 2014 12:50:44 -0500

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

CN stands for Common Name.  GECOS stands for General Electric
Comprehensive Operating Supervisor.

The GECOS field in POSIX was created to hold non-unix attributes
required by the GE COS operating system, because Denis Ritchie and Ken
Thompson could not afford a printer, and had to print through a GCOS
system, which required user attributes Unix does not use.  Those
attributes were stuffed into the GECOS field.

Today the GECOS field is subfielded, holding multiple data items,
which might include the common name associated with the user of a
POSIX account, as well as things like office location, extension, and
home phone.  Tools like finger, chfn and adduser expect subfields
within the GECOS field, separated by commas.

I have never seen an LDAP implementation where GECOS and CN were
synonymous.  But the world's a big place, I guess!  When we create or
modify a user account, we maintain the same data in the appropriate
GECOS subfields as we do in attributes like l and homeTelephoneNumber.
This gives us broad compatibility across OSes and tools.

Sorry about the late answer...

--Charlie

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 16 Dec 2014 10:09:53 -0800

> On Dec 15, 2014, at 2:04 PM, Mark R Bannister <[email-masked]> wrote:
> 
>> http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html <http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html>
>> ᐧ
>> 
>> --
>> -jim
>> Jim Willeke
>> 
>> On Sun, Dec 14, 2014 at 7:17 PM, Hallvard Breien Furuseth <[email-masked] <mailto:[email-masked]>> wrote:
>> https://www.ietf.org/mailman/listinfo/ldapext <https://www.ietf.org/mailman/listinfo/ldapext>
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/ldapext <https://www.ietf.org/mailman/listinfo/ldapext>
> 
> Indeed, as Jim pointed out, I have been working on a replacement for RFC2307 and RFC2307bis in my
> spare time for over 18 months now.  I first released some new IETF drafts in August last year, and I've
> Kurt - as LDAP registries expert would you help to shepherd these internet drafts through the IANA

Mark,

As far as next steps, depends on whether you intend to pursue publication through the IETF or through the Independent Submission Editor (ISE).  The former is appropriate for all standard track document or any non-standard track document for which you want to publish community consensus.  If however you want to publish your own personal views, then ISE is more appropriate.

If the latter, the next step would be to submit the I-Ds to the ISE. The process is roughly outlined at <https://www.rfc-editor.org/indsubs.html <https://www.rfc-editor.org/indsubs.html>>.

If the former, the next step would be to contact an App Area AD <[email-masked] <mailto:[email-masked]>> and ask for guidance.

Lastly, I note that intend to continue reducing my IETF activities around LDAP as I no longer work day-to-day with LDAP.  So I’m saying “no” to requests to get involved beyond my current very limited role as the LDAP registries expert.

— Kurt

> 
> In DBIS I have fixed the case insensitivity issues that were present in RFC2307, and I believe it is compliant
> with BCP 118 [RFC 4521] section 5 as I use new names and OIDs for any attributes or object classes
> that I needed to change.  I've introduced 'posixUserAccount' to replace 'posixAccount' which does not
> use 'cn', the gecos field can be set to point to any attribute you like, I've introduced 'posixGroupAccount'
> draft-bannister-dbis-mapping <http://www.ietf.org/id/draft-bannister-dbis-mapping.txt> (DBIS Mapping Objects)
> draft-bannister-dbis-netgroup <http://www.ietf.org/id/draft-bannister-dbis-netgroup.txt> (DBIS Netgroups and Netservices)
> draft-bannister-dbis-passwd <http://www.ietf.org/id/draft-bannister-dbis-passwd.txt> (DBIS Users and Groups)
> draft-bannister-dbis-hosts <http://www.ietf.org/id/draft-bannister-dbis-hosts.txt> (DBIS Hosts, Networks and Services)
> draft-bannister-dbis-devices <http://www.ietf.org/id/draft-bannister-dbis-devices.txt> (DBIS Devices)
> draft-bannister-dbis-automounter <http://www.ietf.org/id/draft-bannister-dbis-automounter.txt> (DBIS Automounter)
> draft-bannister-dbis-custom <http://www.ietf.org/id/draft-bannister-dbis-custom.txt> (DBIS Custom Maps)
> 
>    * DBIS Reference Implementation on SourceForge <http://dbis.sf.net/> (dbis.sf.net)
>    * Three articles about DBIS from last year on my blog <http://technicalprose.blogspot.co.uk/2013/08/introducing-dbis.html> (technicalprose.blogspot.co.uk)
> 
> The reference implementation works fine with Python 2.7 (tested on OpenSuSE 12.x), and I hope
> to get it working on Python 2.6 this week or next (for RHEL 6 and Solaris 11 users).
> 
> Best regards,
> Mark.
>

---

From: Michael Ströder <[email-masked]>
Date: Tue, 16 Dec 2014 23:11:40 +0100

Charlie,

> 'posixAccount'?  It seems most NSS LDAP clients use attribute 'cn' as

Ah, someone answers my original question! Thanks! :-)

> Today the GECOS field is subfielded, holding multiple data items,

Frankly I never saw more things like the user's full name put in the GECOS
field or a short description for a demon's system account. My personal usage
of finger is 17+ years ago.

> synonymous.

Hmm, one can only have either LDAP attribute 'cn' or 'gecos' appearing as
passwd's GECOS field.

Anyway this is one more reason to question whether posixAccount (or a future
object class serving the same purpose) should have 'cn' (or similar name
attribute) as mandatory attribute.

In one of my recent setups the NSS LDAP clients can't even read 'cn' or
'gecos'. So "getent passwd" will simply return an empty GECOS field. The
system admins are supposed to use LDAP client to find out more about a user's
account. Yes, it's a paranoid setup.

Ciao, Michael.

---

From: Jim Willeke <[email-masked]>
Date: Wed, 17 Dec 2014 04:21:18 -0500

Usually see only one value in GECOS.
Most of the ones we deal with are when we are doing conversions from NIS or
NIS+.

Sometimes it is used to hold the employeeNumber or something unique and
static to the organization.
Using multiple values which are derived from other LDAP attributes is more
difficult as some mechanism must be used to maintain the "duplicate" GECOS
value(s).

ᐧ

--
-jim
Jim Willeke

---

From: Luke Howard <[email-masked]>
Date: Thu, 18 Dec 2014 11:43:03 +1100

It is a bit tricky to remember why I made “cn” mandatory but it probably had something to do with (erroneously) conflating accounts and people. Something that should be addressed in future specifications (if they ever happen).

The only issue might be that some clients reject entries that are missing “cn”.

-- Luke

--
www.lukehoward.com
soundcloud.com/lukehoward

---

From: Andrew Findlay <[email-masked]>
Date: Thu, 18 Dec 2014 09:53:17 +0000

> The only issue might be that some clients reject entries that are missing “cn”.

That would be an error in itself, as even mandatory attributes can be
hidden by access control and the GECOS field is often empty in
/etc/passwd entries so it is clearly not essential.

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 Ströder <[email-masked]>
Date: Thu, 18 Dec 2014 12:07:40 +0100

> /etc/passwd entries so it is clearly not essential.

Yepp. That's the case with my paranoid setup where person's name must not be
disclosed to the attached systems. AFAICS the modern NSS clients can deal with
that.

Ciao, Michael.