Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Your network is growing in size and complexity. It’s taking on a life of its own, spreading and growing and absorbing everything in its path. You’re tearing your hair out trying to keep track, and your users have somehow discovered your secret phone number and are pestering you with endless questions and demands — where do I find this; I don’t want to keep track of a dozen different passwords; nothing works like it should.
Of several possible solutions, consider two: 1) find a new hiding place, or 2) implement an LDAP server. While finding a new hiding place might sound ideal, it’s an option we’re going to have to save for a future article. This series will instead explain what LDAP is good for, detail how to build an LDAP server, and cover what you can do with it.
What LDAP Can Do
In a nutshell, LDAP provides central management of access, authentication, and authorization. It’s easily customizable and can:
- Centralize user and group management
- Centralize information stores
- Set security and access control
- Securely delegate read and modification authority
- Serve almost any platform
- Scale efficiently
What LDAP Cannot Do
- Be a heavy-duty relational or transactional database
- Be a filesystem
- Leap tall buildings in any number of bounds
The LDAP protocol is cross-platform, network-aware, and standards-based. There are all kinds of LDAP implementations from all kinds of vendors. This series will focus on OpenLDAP on Linux.
To DB or Not to DB
Let’s get like all pedantic for a moment (please put on your geek beard and pocket protector for this). LDAP – Lightweight Directory Access Protocol – is a protocol, not a database. It accesses a special kind of database that is optimized for fast reads. Use it for relatively static information, such as company directories, user data, customer data, passwords, and security keys. OpenLDAP uses the Sleepycat Berkeley DB. Having said all that, I’m not the pedant police; I’m OK with calling the whole works a database and being done with it.
LDAP is not a good choice, though, when you need fast, frequent changes — for a retail backend, for example. It’s not a relational database like Oracle, mySQL, or Postgres. In fact, its structure is very different from a relational database. Rather than storing information in columns and rows, and having a rigid set of indexes and fields, data are stored in attribute type/attribute value pairs. This structure offers great flexibility in designing records. A particular user record, for example, can have new types of data added without having to re-design the entire database. Any kind of text or binary data can be stored.
Roots and Hierarchies
An LDAP directory follows the familiar Unix filesystem structure — root directory at the top of the “tree,” with sub-directories branching off. A typical design is to have a single master root directory for the company. Sub-directories are then organized by department, location, function, who’s been naughty/nice — anything that works and makes sense for you. Not only is this a nice tidy way to organize the master directory, it lets you grant access permissions to specific pieces of a central data pool in a precise, controlled fashion.
The next step is distributing bits in a sensible fashion. Any individual subdirectory can be replicated elsewhere — for example, on a server in the department it belongs to. Updates from the master directory can be synchronized at whatever intervals you like, providing redundancy and faster access for users, and also placing less of a strain on the master server.
Updates can be initiated in either direction — or, if you want a reason to use buzzwords, “push” or “pull.” For example, the accounting department can make updates to their directory, then push the updates to the master server — again, saving the worthy sysadmin much tedious and unnecessary labor. This also conserves bandwidth and system resources.
Easy Upgrading
What’s really slick about the distributed nature of LDAP is you can start small. You can implement an LDAP directory in a limited way, testing and getting the hang of it, and then easily scale upwards and migrate more functions to it at your leisure.
Of ACIs and ACLs
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.
User Authentication
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 (see Resources).
The Cheese Stands Alone
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.
Coming Attractions
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.
Resources
»
See All Articles by Columnist Carla Schroder
