Author: JT Smith
vendors large and small, commercial and open source alike, have embraced
LDAP as a centralized service for authentication and ‘white pages’ type
information. These days, if you’re not wearing a ‘got root?’ t-shirt and
yelling at the suits to get LDAP, you’re probably the suits wondering if
LDAP is right for your environment. With features for security and
integration far beyond that of other services, LDAP is probably something you
should spend at least a bit of time discovering. Let’s get started!
I’ve asked a number of friends (including consultants, administrators, and
managers) about the idea of migrating to LDAP. Generally they get a look on their face like I just asked them to quit smoking or
stop eating fast food. The look says, “I know it’s probably the
direction I should be going, but I dunno.” Then they usually ask
something like “Where do I start?” or “Will it work with (insert name of
application or platform here)?”. This, the first of a new series of weekly
columns on Linux.com for system managers, offers a few things to consider
before beginning the migration, and lays out some steps you can follow to
get you moving.
Why Move to LDAP?
Let’s start by taking a look at some of the reasons behind a
migrationto LDAP:
- Sun will discontinue NIS and NIS+
Sun reportedly will not
bundle NIS server or client software in the next release of Solaris. NIS+ will
stay around for another version, but even Sun’s NIS+ clients have been advised
that they should begin migrating, as NIS+ will also be going away sometime
after the release of Solaris 10. If you’re unfamiliar with NIS and NIS+, have a
look here
for a 5-minute crash course, or see the Sun docs on NIS
and NIS+.It probably comes as no surprise that what Sun is recommending as an
alternative to these solutions is their own SunONE Directory software
(formerly iPlanet Directory server), which is conveniently bundled with Solaris
9. Some of the reasons Sun recommends LDAP are the same reasons I’ll discuss
here. - Security
I don’t like to expound upon things about which I have little knowledge, so
my security comparison will be NIS-specific — though the facts I give you
about LDAP should be readily available for comparison with whatever naming or
directory system you currently use.Due to the fact that LDAP is not a database, but rather a standardized
protocol for accessing your directory’s data, LDAP makes a fitting
gatekeeper for your environment’s information. There are clear and visible
lines between the implementation of the protocol and the implementation of the
data storage mechanism. (The two parts can be configured separately.) As such,
the data storage mechanism can concentrate on storing data, while the access
protocol can be configured to secure it.LDAP is designed for very granular security. This is at least partially
attributable to LDAP’s data model, which looks similar to an object/attribute
hierarchy rather than a flat file full of strings. For example, the fields of a
user entry stored on a Linux box in /etc/passwd as a single string would be
quite different in LDAP, which identifies a user as a single object in the
directory, and all of the other /etc/passwd fields (login shell,home directory,
GECOS, etc.) become attributes of that object. This means you can
restrict access at the attribute level — the equivalent of being able to
restrict access to individual fields in any given NIS map.Furthermore, access can be configured using access control lists (ACLs) that
restrict not only which pieces of data can be accessed, but the operations
that can be performed on the data. For example, you may allow anybody to read
the list of user names on a system, but not allow them to read
the encrypted password string for individual users. And while a user can certainly
be granted read access to all of the data pertinent to himself or herself, you may
decide to standardize things like the GECOS (optional information
about the user) field, and deny write access to it,
reserving that right only for administrators. - Integration
I don’t think the powers-that-be would be silly enough to try to push
administrators toward a NIS/NIS+ replacements that won’t give them at
least the same level of integration as these two services. Over the years, naming and directory
services tend to become dependencies for most applications in
the environment in which they’re working.
Although there are still a few areas where LDAP support is not where it
should be, for many environments LDAP works with everything NIS does, and then
some. A couple of quick examples:
- Apache can use LDAP to perform authentication.
- Sendmail can use LDAP for authentication, mail routing information,and
alias lookups. - Samba can use LDAP as a backend authentication mechanism.
- Autofs can retrieve automounter maps from LDAP.
- FreeRADIUS can authenticate against LDAP
Wow! And these examples are just the tip of the iceberg. In addition to
system services, many companies use LDAP as a corporate “white pages” solution,
because so many email and calendar applications are LDAP-compatible. Netscape,
Mozilla, Evolution, Outlook, KMail, and many more email clients have
robust support for LDAP, and even text-based clients like Mutt and Pine can do address completion based on an LDAP search.
For the discriminating administrator, though, this won’t be enough. LDAP
plays quite nicely with PAM (Pluggable
Authentication Modules), and can be put in place of ‘nis’ for virtually
every line in your /etc/nsswitch file (‘man 5 nsswitch.conf’). Once your
nsswitch and PAM config is all set up for using LDAP (largely automated on
systems which have the ‘authconfig’ utility), most other system-level
mechanisms — like mapping UID numbers to names inls -l, TCP
wrappers, and id — “just work.”
Where do I start?
- Evaluate your environment
While it’s easy for me to sit here and say, “The answer is LDAP, what was the question?” I’m all too aware of the fact that LDAP is not a panacea for all that ails your environment. Even if I did somehow sell you on that, it would still be wise to figure out exactly what you want to use LDAP for.
In some instances, you may have homegrown applications whose login routines might need to be altered to use LDAP. In other scenarios, you might decide that while LDAP can be used immediately for authentication, automounter maps are going to stay in files or maps for now. Don’t go planning a NIS server shutdown party just yet! Choose a NIS map — any NIS map — and focus on all of the services, applications and systems which depend on that map. Then make sure that they support LDAP, or can be made to support LDAP. You would not be pleased to find out, after 6 months of server regression testing, that a mission-critical application’s vendor has never heard of LDAP.
In my experience, this early stage of LDAP deployment is the longest and most arduous. Once this is out of the way, well, I won’t say it’s all downhill, but it certainly gets a lot easier, and progress moves faster.
- Evaluate possible server choices
Next (or, concurrently, depending on the size of your team), you’ll need to figure out which implementation of LDAP to use. I found this to be an easier choice than I thought it would be. I tested Novell’s eDirectory and Sun’s SunONE Directory Server software, along with OpenLDAP.
In all fairness, these are all wonderful applications.
In fact, I actually came quite close to choosing the Novell product (which runs nicely under Linux, by the way) for a deployment. The team at Novell has done a wonderful job at making LDAP accessible to even mere mortal administrators. Clear, thorough tutorials and documentation emanate profusely from their Web site, and I found that those who frequented the support forums on Novell’s site were very friendly, and extremely knowledgeable (some of them were Novell employees).
The Sun product is also nice, although the GUI interface was a bit more intimidating than Novell’s. I also historically have been unable to make friends with the digital labyrinth that is the Sun Web site. Though I did find documentation regarding LDAP, I sometimes found different versions of the same document, conflicting documentation, and steps that were just plain wrong. This has also been my experience in searching for documentation regarding Solaris LDAP client configuration.
In the end, I chose OpenLDAP mainly for its simplicity. It’s essentially an implementation of what you can read in the RFCs about the LDAP protocol. Any other fancy stuff can be built on, customized or added later. The terms used in the RFCs and the old bible ‘Understanding and Deploying LDAP Directories’ (which is how I learned LDAP) are the same terms used in the interfaces, documentation and configuration files for the OpenLDAP suite. This was comforting.
Novell and Sun both lack this simplicity. Novell began to show its complexity as soon as I wanted to do something simple like map a user’s home directory. The interface, by default, is configured to assume that your user directories reside on a NetWare volume. It also seemed to me that eDirectory was adding a whole list of data attributes to my entries (upon inspection of the data exports) that I hadn’t defined in the GUI. The Sun product had similar problems, making all kinds of assumptions about my environment and setting up what it thought I would want.
These tools just didn’t fit my brain very well. You very well may fall in love with them. Price is probably not an issue unless you are a government or some other similarly large corporation. Novell and Sun both allow you to use the software for free (without support, of course) up to so many hundreds of thousands of object entries. However, I felt that if I ran into really big trouble, I was going to find a larger community around the free/open source OpenLDAP than commercial tools from anyone else. Besides, OpenLDAP is, for the most part, built on Linux, for Linux. That’s something that the others can never honestly say.
- Start with the Clients
The four words that make up the title of this section comprise the most valuable advice I can think to give anyone approaching an LDAP deployment. Don’t go spending time porting applications, cleansing and moving data, and maintaining a directory server until you first test that the clients can actually do what they claim they’ll do them the way you want them done.
In my eyes — remember, I’m a systems administrator — client testing starts at the system level. Authentication must work with all of the functionality currently in use. Host resolution, if currently done with something other than DNS, must go off without a hitch. Password policies, tcpwrappers, compat modes, and remote mounts must perform with no perceivable difference on the part of the end user in terms of performance and functionality.
Start with a small set of test data, consult your list of what LDAP is going to be responsible for and which applications it will support, and start reading the man pages, vendor docs, and online tutorials. Join a couple of forums, and join any mailing lists that are pertinent to your project.
Also, return here on occasion, as I’ll be writing more on LDAP migration in the coming weeks and months – see you then!
