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 scripts a 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.



LDAP System Administration
LDAP System Administration
ISBN: 1565924916
EAN: 2147483647
Year: 2006
Pages: 129
Authors: Gerald Carter

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net