[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldap-nis] alias



An alias just allows a DN to refer to some other object.
The alias itself only contains the minimal information
needed (namely the name of the aliased object).

There is no standard track representation of aliases in LDAP.
OpenLDAP approach is to use "named aliases" (similar to
"named references").  Unfornately, I haven't had time to
write an I-D detailing our approach.

LDAP, the protocol, provides no join mechanism.  Some
servers may provide such... that's part of what "meta"
directories are about.  I note that back-meta (HEAD only)
is our experimental work in this area.

Kurt

At 08:18 AM 6/22/2001, Jehan PROCACCIA wrote:
>I already tried all alternatives of the -a option.
>After re reading the (expire) draft:
>http://globecom.net/ietf/draft/draft-byrne-ldap-alias-00.html
>I noticed that an entrie containing a aliasedObjetcName "SHOULD NOT be
>combined  with other objectclass" which is what I am doing !. I begin to
>think that alias are only a mean to rename an entrie, but in any way not
>a tool to link entries in order to retrieve attributes from both of
>them, actually not a kind of a key to join tables in RDBMS.
>
>Is there any developement in the openldap/ldap to support that kind of
>links ?
>
>"Erik A. Larsson" wrote:
>> 
>> Jehan PROCACCIA wrote:
>> >
>> > I runned a test to use the alias objectclass. however an ldapsearch on
>> > an entry containing the aliasedObjectName attribute did not returned the
>> > attributes from the entry pointed by that aliasedObjectName dn !?. I am
>> > misusing/misunderstanding the role of the alias objectclass ? is there
>> > something to do on the server itself to enable the use ("following") of
>> > aliases ?
>> >
>> > Thanks a lot for your help .
>> >
>> > Here's the DIT I runned the test on:
>> >
>> > -dc=int-evry,dc=fr
>> >         -adm
>> >           -eph
>> >            -staff-eph
>> >             - administrative information about the person (1)
>> >         -services
>> >           -unix
>> >            - unix account(2) (with attributes from posix and shadow account)
>> >           -mail
>> >            - mail information (3) (rfc822 ...)
>> >
>> > here's what le leafs (1,2,3) of the above DIT contains
>> >
>> > (1) # Jean-Pierre LEVREY,Staff-Eph,Eph,Adm,dc=int-evry,dc=fr
>> > dn: cn=Jean-Pierre LEVREY,ou=Staff-Eph,ou=Eph,ou=Adm,dc=int-evry,dc=fr
>> > objectClass: person
>> > objectClass: organizationalPerson
>> > cn: Jean-Pierre LEVREY
>> > sn: LEVREY
>> > telephoneNumber: 01 60 76
>> > title: Maitre de conf
>> >
>> > (2) # levrey,Unix,Services,dc=int-evry,dc=fr
>> > dn: uid=levrey,ou=Unix,ou=Services,dc=int-evry,dc=fr
>> > uid: levrey
>> > cn: J-P Levrey
>> > objectClass: organizationalUnit
>> > objectClass: posixAccount
>> > objectClass: top
>> > objectClass: shadowAccount
>> > objectClass: alias
>> > aliasedObjectName: cn=Jean-Pierre
>> > LEVREY,ou=Staff-Eph,ou=Eph,ou=Adm,dc=int-evr
>> >  y,dc=fr
>> > ou: unix-eph
>> > shadowLastChange: 11277
>> > loginShell: /usr/local/bin/tcsh
>> > uidNumber: 14521
>> > gidNumber: 145
>> > homeDirectory: /mci/eph/leverey
>> > gecos: JP Leverey EPH
>> > userPassword:: e2NyeXBQfWdkUVZkb1dhcmptQkU=
>> >
>> > (3) # levrey,Mail,Services,dc=int-evry,dc=fr
>> > dn: rfc822ForwardingMailbox=levrey,ou=Mail,ou=Services,dc=int-evry,dc=fr
>> > objectClass: organizationalUnit
>> > objectClass: rfc822Delivery
>> > objectClass: top
>> > objectClass: alias
>> > aliasedObjectName: cn=Jean-Pierre
>> > LEVREY,ou=Staff-Eph,ou=Eph,ou=Adm,dc=int-evr
>> >  y,dc=fr
>> > ou: Mail
>> > mailAcceptingGeneralID: jean-pierre.LEVREY
>> > rfc822ForwardingMailbox: levrey
>> >
>> > When I run an ldapsearch on the unix account (2), I get what I entered
>> > in the original ldif file to create the entry, but not at all the
>> > attributes from the entry pointed by the aliasedObjectname dn , cf
>> > below. When I select only the "title" attribute (attribute present in 1)
>> > to be shown from the ldapsearch, i get nothing :-( proving that the
>> > alias seems useless !!?
>> >
>> > $ldapsearch -h servfax -p 9999 -b"dc=int-evry,dc=fr" -s sub -x
>> > "(uid=levre*)" -a never
>> > version: 2
>> >
>> > #
>> > # filter: (uid=levre*)
>> > # requesting: ALL
>> > #
>> >
>> > # levrey,Unix,Services,dc=int-evry,dc=fr
>> > dn: uid=levrey,ou=Unix,ou=Services,dc=int-evry,dc=fr
>> > uid: levrey
>> > cn: J-P Levrey
>> > objectClass: organizationalUnit
>> > objectClass: posixAccount
>> > objectClass: top
>> > objectClass: shadowAccount
>> > objectClass: alias
>> > aliasedObjectName: cn=Jean-Pierre
>> > LEVREY,ou=Staff-Eph,ou=Eph,ou=Adm,dc=int-evr
>> >  y,dc=fr
>> > ou: unix-eph
>> > shadowLastChange: 11277
>> > loginShell: /usr/local/bin/tcsh
>> > uidNumber: 14521
>> > gidNumber: 145
>> > homeDirectory: /mci/eph/leverey
>> > gecos: JP Leverey EPH
>> > userPassword:: e2NyeXB0fWdkUVZkb1dhcmptQkU=
>> >
>> > Thanks.
>> >
>> > PS: ldapsearch returns "version: 2" even with the option -P 3 , how run
>> > all this on V3 ?
>> >
>> 
>> The ldapsearch option -a allows you to specify how you want to handel
>> aliases.  -a always will always dereference aliases.  This works in
>> OpenLDAP 2.x anyway.  I'm not certian if the nss-ldap module will
>> dereference aliases, or if the code is easily hacked to do so.  (Actually,
>> as soon as I get the basic NSS LDAP working on my system, I'm going to have
>> to figure this issue out as well, since I have user objects scattered
>> throughout my tree and want to create a "management OU" for my UNIX systems
>> containing only aliases to the user objects allowed on that particular UNIX
>> host.)
>> 
>> --
>>  ________________________________________________________________________
>>  Erik Larsson                                    mailto:erik@eLarsson.net
>>  Student Systems Administrator                   http://www.eLarsson.net/
>>  Drew University Academic Technology               +1 973-408-5904 (home)
>>  To send encrypted mail, get my PGP key at:        +1 973-408-5020 (work)
>>  http://www.eLarsson.net/erik_larsson.asc          +1 732-319-4710 (cell)
>
>-- 
>Jehan Procaccia
>Institut National des Telecommunications| Email:
>Jehan.Procaccia@int-evry.fr 
>MCI, Moyens Communs Informatiques       | Tel  : +33 (0) 160764436 
>9 rue Charles Fourier 91011 Evry France | Fax  : +33 (0) 160764321