Review
Product Description
Be more productive and make your life easier. That's what LDAP System Administration is all about.
System administrators often spend a great deal of time managing configuration information located on many different machines: usernames, passwords, printer configurations, email client configurations, and network filesystem configurations, to name a few. LDAPv3 provides tools for centralizing all of the configuration information and placing it under your control. Rather than maintaining several administrative databases (NIS, Active Directory, Samba, and NFS configuration files), you can make changes in only one place and have all your systems immediately "see" the updated information.
Practically platform independent, this book uses the widely available, open source OpenLDAP 2 directory server as a premise for examples, showing you how to use it to help you manage your configuration information effectively and securely. OpenLDAP 2 ships with most Linux® distributions and Mac OS® X, and can be easily downloaded for most Unix-based systems. After introducing the workings of a directory service and the LDAP protocol, all aspects of building and installing OpenLDAP, plus key ancillary packages like SASL and OpenSSL, this book discusses:
- Configuration and access control
- Distributed directories; replication and referral
- Using OpenLDAP to replace NIS
- Using OpenLDAP to manage email configurations
- Using LDAP for abstraction with FTP and HTTP servers, Samba, and Radius
- Interoperating with different LDAP servers, including Active Directory
- Programming using Net::LDAP
From the Publisher
About the Author
Excerpted from LDAP System Administration by Gerald Carter. Copyright © 2003. Reprinted by permission. All rights reserved.
One of the most important applications of a directory is storing email addresses and other contact information.Although many ad hoc solutions to this problem have been implemented over the years,LDAP provides a natural online publishing service for this type of data.This chapter explores the ins and outs of integrating email clients (MUAs) and mail servers (MTAs)with an LDAP directory.It covers the configuration details of some of the more popular email clients,including Mozilla Mail, Pine,Microsoft Outlook, and Eudora.We ’ll also discuss the schema required to support these clients and the types of LDAP searches to expect when the application attempts to locate a user in the directory.
On the server side,we ’ll discuss three popular email servers —Sendmail,Postfix,and Exim —all of which can use a directory.We will cover the level of LDAP support within each MTA,the schema needed to support this integration,and the configuration process for integrating an LDAP directory into a production email environment.
This discussion assumes that you are familiar with basic MTA administration and the interaction between SMTP servers.
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.Cartersn:Carter
mail:kcarter@plainjoe.
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.
roomNumber:102 Ramsey Hall
telephoneNumber:222-555-2356uid: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.
