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 CarterLooking 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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access