Date: Sun, 18 Apr 2010 09:25:04 +0300 From: Valentin Bud <valentin.bud@gmail.com> To: Alejandro Imass <ait@p2ee.org> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Requesting community opinion regarding security/pam_ldap groupdn and member_attribute Message-ID: <n2k139b44431004172325ubb218a62ycc6a78a830f039bf@mail.gmail.com> In-Reply-To: <j2ra14066a01004170613hcdf555c9kcf14399322ef8e7b@mail.gmail.com> References: <n2z139b44431004160544ze930d367wbbe5dfa6dfaf68ae@mail.gmail.com> <j2ra14066a01004170613hcdf555c9kcf14399322ef8e7b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 17, 2010 at 4:13 PM, Alejandro Imass <ait@p2ee.org> wrote:
> On Fri, Apr 16, 2010 at 8:44 AM, Valentin Bud <valentin.bud@gmail.com>
> wrote:
> > Hello community,
> >
> > I am working these days on implementing a centralized
> [...]
>
> > The problem is that pam_ldap wants the memberUid attribute to contain the
> > user's DN and there is
> > no option to change this behavior.
> >
>
> Hmmm...
>
> > My question is: what is the argument behind this and do you think it
> should
> > stay this way or
> > could it be changed?
> > In my case I really need pam_ldap to check just for UID not DN of a user
> in
> > memberUid attribute.
> >
>
> I think you are a bit confused here, because dn is not an attribute,
> and you must revise RFCs 4510 to 4519,4530 (and others related).
>
> The DN is the Distinguished Name, which is basically the RDN + the DN
> of the parent node..... let's see where should I start....
>
> Ok, think of LDAP as 2 things: 1) a simple network protocol, 2) a
> database model that stores "entries" in a tree fashion (the Directory
> Information Tree or DIT). Each "entry" (the atomic unit in a DIT) has
> to derive from at least one structural Object Class (or more) and zero
> or more Auxiliary Classes. The structural class has one (or more -
> though it's not very common) MUST attributes, which _usually_ make up
> the entry's RDN (Relative Distinguished Name). So, the RDN is
> _usually_ conformed of the principal MUST attribute of it's primary
> structural class, and _usually_ it defines the "entry type"[1].
>
> I say usually because entries commonly derive from several classes,
> not just one, so in reallity you can use _any_ attribute for your RDN,
> as long as you make sure it's unique among siblings (other entries
> that share the same parent). When you position the entry in the DIT
> you conform what is known as the DN, which is the attribute(s) that
> conform the RDN + the DN of the parent node. It is also important to
> note that, and not many people know this, that both the RDN and DN
> could change during the life of an entry, and there is an operational
> attribute called the entryUUID which is sort-of a unique identifier in
> the DIT (RFC4530), and although it's not really meant to be used as a
> day-to-day identifier, may prove useful when integrating LDAP data to
> other data sources such as RDBMS. Oh, and entries can also have
> multiple DNs ("Alias Names" RFC4512, sect 2.6).
>
> So, back to your question, the short answer is that to find an entry
> in the DIT you HAVE TO use the dn, althoug the attribuites that
> conform that dn are really up to you. For example, if your entry
> derives from person and posixAccount you could use any of (or both) cn
> and/or uid in the RDN.
>
> Best,
> Alejandro Imass
>
> Notes:
> [1] The entry type, of course is what you want it to be, though many
> of your GUI tools will chose the principal atribute of the first
> objectclass to show you the node (they seldomly use the complete dn,
> so you kind-a think of that attribute as the "type" (organization,
> person, ou, etc.), but that may be missleading....)
>
>
> > I have asked our friend google what does he has to say about this and
> found
> > out that
> > there is a patch on Debian which can be found here:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341541
> > that gives the user the possibility to choose if the memberUid attribute
> > holds the DN or UID.
> > I would really like that feature so I have patched pam_ldap to no success
> > and since my C programming
> > skills are close to none I am stuck.
> >
> > Would you people think that the above patch would be useful? Please
> argument
> > on this. How
> > can I/we make that patch work?
> >
> > Thank you very much and a great day,
> > v
> >
> >
> > --
> > network warrior since 2005
> > _______________________________________________
> > freebsd-questions@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe@freebsd.org"
> >
>
Hello Alejandro,
Thank you for your explanation about LDAP. It has been helpful.
My problem though is WHY (argumented) does pam_ldap want to see the DN of
the entry
which matched the search for the uid attribute in the memberUid attribute of
the group I want to enforce users be a part of so they can login into the
system
using ssh.
Since memberUid attribute holds the value of posix uid I think is not
pretty correct
to find there a DN relating to the standards.
Thanks once again. A great day,
v
--
network warrior since 2005
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n2k139b44431004172325ubb218a62ycc6a78a830f039bf>