Re: which attributes compose "Relative Distinguished Names"

[Jeff Clowser <jclowser@aerotek.com>]

Emmanuel JEGOU wrote:

> > > > > > 1.which attributes compose "Relative Distinguished Names"? It seems that
> > > > > > nothing
> > > > > >   in the configuration file indicates them.

Pretty much any attribute can be the RDN.  The RDN
is simply the part of the dn that uniquely identifies
the dn.  Take a tree containing the following dn's:

uid=jclowser, ou=IS, o=aerotek
cn=bill smith, ou=is, o=aerotek
ou=IS, o=aerotek

In the first example, uid is the rdn.  In he second,
cn is the rdn.  in the third, ou is the rdn.  The
left most attribute in the dn constitues the rdn.

The tree is structured as follows:
          o=aerotek
          /       \
         ou=IS    (other ou's like ou=hr, etc)
        /     \
uid=jclowser  cn=bill smith



> > > >   If we don't indicate which attributes compose RDN and their levels in
> > > > the tree, then we
> > > >   can have several different views of the database, for example:
> > > >
> > > >                   c=CN                                c=CN
> > > >                    /\                                  /\
> > > >                   /  \                                /  \
> > > >                  /    \                              /    \
> > > >                 /      \                            /      \
> > > >            o=org1      o=org2                ou=unit1      ou=unit2
> > > >             /\             /\                  /\              /\
> > > >            /  \           /  \                /  \            /  \
> > > >           /    \         /    \              /    \          /    \
> > > >   ou=unit1  ou=unit2 ou=unit1 ou=unit2   o=org1   o=org2  o=org1  o=org2

> > > No, you can't have several different views because you have the DN of each entry
> > > that identifie each one in the entire tree. For example, with the tree on the
> > > left, the bottom left entry is identified by : 'dn:ou=unit1, o=org1, c=CN' and
> > > the right one by : 'dn:o=org1, ou=unit1, c=CN'. The order in the DNs is
> > > significant so the two trees above are different.

Right - these are not the same tree.  The rdn does
not define the position in the tree, the dn does.
The rdn only defines the position within one level
of the tree (with the level being defined by the rest
of the dn).

> > > I am no sure you could have the tree on the right because I think you should have
> > > your Organization (o=org1) before your OrganizationalUnit (ou=unit1). But I am
> > > not sure of it.
> > Surely we human beings understand the right order, but how does the LDAP
> > software
> > know which order is right (the left one) and refuse to treate  "o=org1,
> > ou=unit1,
> >  c=CN" as a valid DN?

Both trees are technically valid.  How you organize
your tree has a lot to do with how you do business,
and with common practice (and with a little common
sense :)  ).  One method is that you build the tree
to reflect your business structure, but not in such
detail that you have to constantly restructure your
tree.  As an example, we operate in North America
and Europe.  There is interaction between America
and Europe, but each are pretty much independently
operated.  To address this, the top of our tree is
o=Aerotek.  Under this we have ou=North America and
ou=Europe.  We can replicate data between the two,
but for the most part each individually maintain
the structure under that.  However, for the most
part under ou=North America, we have ou=People,
ou=Groups, etc, based on common practice.  Many
people use their DNS domains (i.e. a suffix of
dc=aerotek, dc=com), but is only appropriate if your
business only uses one domain.  Going the x.500
way, the top of your tree may be c=US, with o=
companyname under that (think that's x.500 common
practices), but may not be appropriate if you are
a multinational company.  Common practice is to
use uid or cn as your rdn, but cn tends to have
duplicates (2 bill smiths, etc).  We use uid for
users, and cn for groups in our server.  It
can be just about anything, but it's best to stay
within "common" practices and defined schemas
(course it's sometimes hard to find a "defined"
schema or know which to use :)   ).

In any case, LDAP is a hierarchical database - the
order of the attributes in the dn is significant,
as it defines the path in the tree, right to left
in the dn is top to bottom in the tree - they just
have to match and be consistent.  Also, if you
define a node x=1,y=2,z=3, you also have to have
nodes higher up in the tree (i.e. y=2,z=3) defined
until you get to what you define as your suffix.
(i.e. if your suffix is y=2,z=3, you don't have
to define a z=3 record - you define the suffix and
everything below it).

Hopefully this clarifies some things rather than
making it worse (and hope there are not too many
errors in what I said - if there are, others will
point them out :)  )


--
 Jeff Clowser
 mailto:jclowser@aerotek.com       Hanover MD  21076 USA
 Phone: (410)-579-4328             7312 Parkway Drive