On Fri, Apr 16, 2010 at 8:44 AM, Valentin Bud <valentin....@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-unsubscr...@freebsd.org"
>
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
