LDAP System Administration
Gerald Carter
Language: English
Pages: 312
ISBN: 1565924916
Format: PDF / Kindle (mobi) / ePub
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
If you want to be a master of your domain, LDAP System Administration will help you get up and running quickly regardless of which LDAP version you use. After reading this book, even with no previous LDAP experience, you'll be able to integrate a directory server into essential network services such as mail, DNS, HTTP, and SMB/CIFS.
distribution requires only a few familar steps. In most environments, the following commands will install the libraries and development files in /usr/local/: $ gzip -dc cyrus-sasl-2.1.9.tar.gz | tar xf - $ cd cyrus-sasl-2.1.9 $ ./configure $ make $ /bin/su -c "make install && \ ln -s /usr/local/lib/sasl2 /usr/lib/sasl2" The symbolic link is needed because the SASL library will look for installed mechanisms in /usr/lib/sasl2/ (as described in the cyrus-sasl documentation). Compiling
from the following two ACLs. What sort of access would be granted to the userPassword attribute? # Simple ACL granting read access to the world access to * by * read # Restrict userPassword to be used for authentication only, but allow users to modify # their own passwords. access to attrs=userPassword by self write by * auth The previous ACLs grant all users (anonymous and authenticated) read access to userPassword. This clearly isn't a policy you would want. To achieve the desired
####################################################### ## Partition on second server holding ou=hosts database bdb ## Define the root suffix you serve. suffix "ou=hosts,dc=plainjoe,dc=org" ## Define a root DN for superuser privileges. rootdn "cn=Manager,ou=hosts,dc=plainjoe,dc=org" ## Define the password used with rootdn. This is the Base64-encoded MD5 hash of ## "secret." rootpw {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy ## Directory containing the database files directory
the DN for the first entry would be cn=Jane Smith,ou=Sales,dc=plainjoe,dc=org. This design does not entirely eliminate the need for multivalued RDNs; we could still have two people named Jane Smith in the Engineering organization. But that will occur much less frequently than having two Jane Smiths in the company. Look for ways to organize namespaces to avoid multivalued RDNs as much as is possible and logical. Figure 2-2. A namespace that represents Jane Smith with a unique, multivalued RDN
attributes and object classes for storing information such as Unix user and group identifiers (numeric UIDs and GIDs), Unix-style home directory paths, and Unix login shells. So you can extend the Active Directory schema by installing the SFU package, and using the schema it provides—even if you don't intend to use Microsoft's NIS server itself. Another approach is to extend the Active Directory schema yourself. After all, it's really just another LDAPv3 server. The AD4Unix plugin developed by