Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AE11A1B51 for ; Wed, 17 Dec 2014 01:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu83HrlD96sq for ; Wed, 17 Dec 2014 01:21:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC761A079A for ; Wed, 17 Dec 2014 01:21:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tr6so14599752ieb.31 for ; Wed, 17 Dec 2014 01:21:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cVlghpTksbFPgL4Y9/uksosVqX4bgdRmb/RiNYAypLI=; b=DpbZ1C8QumZmaxV388tko5B16E8QrmnLTj22x4fdPXg/A/gcukMdPtR66ksPBxN5sQ ji7zU9bhcLX9wKDHt76hy7o8wV731v7r5Y6SmAevmoUFXtIxwDRy3JtQA2nCivryQ+9Y DHa5HDUBcKQXWQlwBDAxWZSPyS7n5riMJLg9LiMhRphssImu7VPDBj/B6ffpKQLhMCgK KoGbTVUTOY4lkt/lI5NLA/cRFGm5d7SFKoO5+1eE1f3S3AfIeTQY/oS75jC56uavE01r vMGRDrNJs+XZdAOXoCjvGLg/LPJUiHoHPngOUh+PxW23TkG4QtaSJYQso4n8j8iqW7L8 5mWg== X-Gm-Message-State: ALoCoQl4BKutcFrimhtaVVaYFsFPp9YAGHFD0MBT1QiKuawLhMeCtljKuO0dze3Hl+GTPeSuWYMm X-Received: by 10.42.11.15 with SMTP id s15mr29587870ics.18.1418808098957; Wed, 17 Dec 2014 01:21:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.24.162 with HTTP; Wed, 17 Dec 2014 01:21:18 -0800 (PST) In-Reply-To: <5490AE1C.6010004@stroeder.com> References: <548DB67C.5060009@stroeder.com> <5490AE1C.6010004@stroeder.com> From: Jim Willeke Date: Wed, 17 Dec 2014 04:21:18 -0500 Message-ID: To: =?UTF-8?Q?Michael_Str=C3=B6der?= Content-Type: multipart/alternative; boundary=20cf30434866be452d050a6600b9 Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/dSVvWoLmxmIFpk7I3ttFuQgWcFo Cc: ldapext Subject: Re: [ldapext] why posixAccount MUST contain 'cn'? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 09:21:41 -0000 --20cf30434866be452d050a6600b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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). =E1=90=A7 -- -jim Jim Willeke On Tue, Dec 16, 2014 at 5:11 PM, Michael Str=C3=B6der wrote: > > Charlie, > > Charlie wrote: > > 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." > > 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 GECO= S > field or a short description for a demon's system account. My personal > usage > of finger is 17+ years ago. > > > I have never seen an LDAP implementation where GECOS and CN were > > 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. > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > > --20cf30434866be452d050a6600b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 uniqu= e and static to the organization.
Using multiple values whi= ch are derived from other LDAP attributes is more difficult as some mechani= sm must be used to maintain the "duplicate" GECOS value(s).
=

=E1=90=A7=

--
-jim<= br>Jim Willeke

On Tue, Dec 16, 2014 at 5:11 PM, Michael Str= =C3=B6der <michael@stroeder.com> wrote:
Charlie,

Charlie wrote:
> Michael asked,=C2=A0 "Also what's the distinction of 'cn&= #39; and 'gecos' in
> 'posixAccount'?=C2=A0 It seems most NSS LDAP clients use attri= bute 'cn' as
> gecos field today."

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.

> I have never seen an LDAP implementation where GECOS and CN were
> synonymous.

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

Anyway this is one more reason to question whether posixAccount (or a futur= e
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 G= ECOS 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.


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext

--20cf30434866be452d050a6600b9--