Linux.com

Approaching LDAP Migration

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."

1. 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.
   
   
2. 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.
   
   
3. 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.