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 […]
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:
What LDAP Cannot Do
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:
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
Enterprise Networking Planet aims to educate and assist IT administrators in building strong network infrastructures for their enterprise companies. Enterprise Networking Planet contributors write about relevant and useful topics on the cutting edge of enterprise networking based on years of personal experience in the field.
Property of TechnologyAdvice. © 2025 TechnologyAdvice. All Rights Reserved
Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.