LDAP System Administration [Electronic resources] نسخه متنی

7.1 Representing Users

The server you will build combines the white pages server you created
in Chapter 4 and the server for administrative
databases you created in Chapter 6 as a
replacement for NIS. You already have a head start on integrating
user account information because both servers used the
ou=people container for storing user account
information. With only a few modifications to your directory, the
posixAccount
and inetOrgPerson
object classes can be used to store a single user entry for both
authentication and contact information.

Here's an entry for "Kristi
Carter," which is similar to those presented in
Chapter 4:

dn: cn=Kristi W. Carter,ou=people,dc=plainjoe,dc=org
objectClass: inetOrgPerson
cn: Kristi W. Carter
sn: Carter
mail: kcarter@plainjoe.org
labeledURI: http://www.plainjoe.org/~kristi
roomNumber: 102 Ramsey Hall
telephoneNumber: 222-555-2356

In Chapter 6, this same user might have been
presented as:

dn: uid=kristi,ou=people,dc=plainjoe,dc=org
uid: kristi
cn: Kristi Carter
objectClass: account
objectClass: posixAccount
userPassword: {crypt}LnMJ/n2rQsR.c
loginShell: /bin/bash
uidNumber: 781
gidNumber: 100
homeDirectory: /home/kristi
gecos: Kristi Carter

Looking at both examples side by side, some differences can be noted.
The first is that the RDN used for each entry is different. It
doesn't really matter whether you choose
cn=Kristi W.
Carter or uid=kristi. Since
Unix accounts must already possess a unique login name, the
uid attribute is a good choice to prevent name
conflicts in ou=people.

The second issue is more serious and shows
why the initial
directory design should not be rushed. Both the
account and inetOrgPerson
object classes are structural object classes. Remember that an entry
cannot have more than one structural object class and that once an
entry is created, its structural class cannot be changed. Some LDAP
servers may allow you to reassign an entry's object
classes at will, but do not rely on this behavior.

To solve this dilemma, initially create each entry with the
inetOrgPerson class and then extend it using the
posixAccount auxiliary class. The means that the
account entry will have to filtered from the output of
PADL's migration scriptsa simple task using
grep:

$ ./migrate_passwd.pl /etc/passwd | grep -iv "objectclass: account" > passwd.ldif

The combined user entry now appears as:

dn: uid=kristi,ou=people,dc=plainjoe,dc=org
objectClass: inetOrgPerson
objectClass: posixAccount
cn: Kristi Carter
cn: Kristi W. Carter
sn: Carter
mail: kcarter@plainjoe.org
labeledURI: http://www.plainjoe.org/~kristi
roomNumber: 102 Ramsey Hall
telephoneNumber: 222-555-2356
uid: kristi
userPassword: {crypt}LnMJ/n2rQsR.c
loginShell: /bin/bash
uidNumber: 781
gidNumber: 100
homeDirectory: /home/kristi
gecos: Kristi Carter

One final note before we begin looking at specifics of email
integration: the mail attribute is optional in the
inetOrgPerson schema definition. However,
it's clearly mandatory when you're
trying to support mail clients and servers.