LDAP access control instances (ACIs), which collectively form an access control list (ACL), allow extremely fine-grained control. Here are a few examples:

• Users can modify their own personal information--such as home address, phone extension, work email, etc.--but no one else's.
• All of the information for a particular user can be kept in a single record, but access to individual entries is completely configurable.
• Give managers a precise level of read and read/write permissions for their group. A popular need that this satisfies is giving managers sufficient access to monitor project documents and reports, but not monkey with them.
• Let groups or group leaders determine who gets what kind of access to resources under their control. I absolutely love not being pestered for minor chores like sharing documents and project directories. Power to the people.
• Put passwords and usernames, and other sensitive data, under the iron control of the diligent sysadmin.

LDAP supports SASL (Simple Authentication and Security Layer), which incorporates Kerberos, GSSAPI, and DIGEST-MD. Adding LDAP user authentication to an existing network is not too dreadful at all. There are several very good utilities for migrating your existing user and password data provided by PADL Software.

It's recommended to run OpenLDAP on a dedicated, standalone server. On a smaller, low-demand network you can get away with using a shared server. In the documentation, you'll see many references to slapd and slurpd. slapd is the LDAP daemon, while slurpd handles replication.

In part 2 we'll step through installation, configuring the server, and creating LDAP records. Part 3 will cover user authentication and creating a single login.

« Back: What LDAP Can and Cannot Do