Re: Five fundamental questions from a newbie

["Kurt D. Zeilenga" <kurt@OpenLDAP.org>]

At 11:04 PM 1/13/00 +0100, Marian Steinbach wrote:
>For a small university faculty I am testing OpenLDAP as central
>directory for UNIX accounts, e-mail-aliases, web authentication
>and so on, like many others do or have done succesfully. Now I
>have some questions dealing with the scheme and with the
>strategy for database maintainance as well as with the
>integration of different platforms.

I suggest grabbing a copy of "Understanding and Deploying LDAP
Directory Services" by Howes, Smith, and Good.  I'll try to
answer briefly.

>1) The Right dn
>
>Which attributes are used best for the dn?

Attributes who's values are unique, are immutable (or infrequently
change), and are publishable.

uid=foo or mail=foo@domain are good RDNs attributes for users.

>I have tried out the
>way that is described in the SLAPD/SLURPD administrator´s guide
>, taking the whole cn created by gn and sn as part of the dn.
>
>Like this:
>dn: cn=Marian Steinbach, ou=Design, o=Fachhochschule Koeln, c=DE

Organizational hierachy tend to change over time and hence
should be avoided.  Something like:

	mail=msteinbach@sendung.de, dc=sendung, dc=de

would be less likely to change and hence would be better.
(also note the use of dc= base DN is wise as it avoids having
to register your o with your national authority... your domain
is already registered (I presume)).

>For my name this is long enough, let allone "Catharina Erika
>Ortega Carrion" and those. The second problem is that people
>whon´t ever keep in mind which names they used for the account.
>So I plan to use a dn like

Use of mail as RDNs is good as users generally remember their
e-mail address.

>
>dn: uid=marian, ou=Design, o=Fachhochschule Koeln, c=DE

I suggest keeping trees as flat as possible.  If the adminstration
of the directory is same for all of the school, I'd suggest:
  mail=msteinbach@sendung.de, ou=Leute, dc=sendung, dc=de

Leaving other ou= for devices, groups, etc.
	
>Are there any disadvantages about this? To me this seems more
>usefull and I was wondering why the written guide used
>non-unique names...
>
>2) Different objectClasses in one entry
>
>What is it good for that one makes an entry belong to more than
>one objectClass? And what is the "top" class good for? For me it
>seems as if this was against real "order" in the directory tree.
>An example explaining the reason would help me a lot!

A entry is of one structural objectclass.  This class derives
properties from other "superior" objectclasses.  For example,
inetOrgPerson derives (indirectly) from person, so might xPerson.
I can search for objectclass=persoon and find all persons
regardless of whether or not they are inetOrgPersons, xPersons,
or any other objectclass derived from Person.

You can also use objectclasses to "mixin" additional attributes.
For example, if you want to use uid naming and the objectclass
doesn't allow uid, you can mixin uidObject auxiliary class
to allow uid to exist.

It is generally best to extended schema using auxiliary object
classes...

>3) Creation and Maintainance
>
>As the necessary user information is held in different sources
>(database, user and group files) I wrote a Perl script which
>merges the data into one large LDIF file. What will happen to
>the existing entries in the LDAP database when I (ldap)add data
>from a newer LDIF file? Are they supposed o be overwritten or
>will OpenLDAP respond with an error saying that the entry
>allready exists (which made an update quite difficult)?

ldapadd adds new entries.  An error should occur if the entry
already exists.

>4) Macintosh Integration

Likely.

>5) Windows NT 4 Intgration

Same as above.

----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>