In-Depth

Bridging the Directory Services Gap

Red Hat Directory Service helps join Windows and Linux environments.

• By Jeremy Moskowitz
• 02/01/2006

The directory is at the heart of your company. Your corporate directory contains phone numbers, user accounts, vital settings and much, much more. It often acts as the central hub for smaller directory services, such as Human Resources or the PBX system, and provides the infrastructure for user authentication and logon.

Microsoft Active Directory is the 800-pound gorilla in this space, outstripping contenders like Novell NDS. As the successor to NT 4.0, AD has a lot going for it, including identity management, delegated rights, deep third-party support and my personal favorite -- Group Policy Objects.

AD may be the de facto standard in the Windows world, but growing enterprise adoption of the Linux operating system poses a true integration challenge for AD shops. IT organizations are striving to find ways to bridge the platform gap in an effort to streamline processes and better utilize resources.

A Little Background Music
As has been the case in the Windows market, the multiple directory services in the Unix and Linux environment are slowly consolidating. Today, many organizations still employ NIS (Network Information Services), which is a fairly basic way to maintain a centralized password repository. Unfortunately, NIS has been proven time and again to be vulnerable to security exploits. Still, NIS is often implemented just about everywhere older Unix clients are found.

More recently, the OpenLDAP project has been steadily gaining steam. New Unix and Linux installations will typically install OpenLDAP, while many organizations using NIS are planning a move to OpenLDAP. Like AD, OpenLDAP uses the Lightweight Directory Access Protocol (LDAP) as the lingua franca for directory services. While OpenLDAP enjoys a wide and satisfied following in the field, the technology suffers from one significant shortcoming -- it's "single master." That is, only one OpenLDAP server can be "writeable."

By contrast, every domain controller in AD is multi-master/writeable. For instance, I can add 300 new accounts to DC 1, and add 200 new accounts to DC 2. After the two DCs are done talking, there are 500 new accounts available within AD. Moreover, if I edit Johnny's account on DC 1 and change the phone number field, and I edit Johnny's account on DC 2 and change the street address field, when the two DCs are done talking, both updates appear everywhere.

This idea is called "multi-master" replication and is an inherent AD selling point. If you stick a DC in a branch office, but the branch loses its connection to the main office, the administrator in the branch can still make updates to AD. When connectivity is restored, all the updates from the branch office get updated to the main office and vice-versa.

Single-master OpenLDAP requires every directory change to go to the one "primary" server, which is the only writeable server on the network. Other servers then pull updates from the writeable server as read-only copies. This presents two main problems. First, if the main server is in the United States, but the branch office administrator is in China, all requests to write data must go across the wire to the United States, then get pulled back down to the branch office server in China. Bigger issues crop up if the main server in the United States goes down, because nobody can update the directory until the machine is revived.

Enter Red Hat
Red Hat's foray into directory services attempts to rectify these problems with a true multi-master directory service. The directory service comes in two, easy-to-understand flavors:

• Red Hat Directory Server (RDS): This is the "supported" version of the directory server. Support is free, if you put the directory service on a Red Hat server for which you're already paying support.
• Fedora Directory Server (FDS): This is the 100 percent free version of the directory server. It's exactly the same code as the Red Hat Directory server, but is only community supported. It's unclear if the Fedora Directory Server's code base will stay the same as Red Hat Directory server or "fork" sometime in the future to add new features or other updates.

While Red Hat supports RDS, the company has established a soft limit of four multi-master, read/write copies of the database on a single network. Red Hat says the product is technically capable of thousands of read/write nodes (like AD), but in its initial launch, the company wants to minimize the number of scenarios it has to support. An unlimited number of read-only RDS servers is supported.

Installing RDS/FDS
For my testing, I used FDS running on Fedora Core 4. Again, the FDS code is identical to that found in RDS. I attempted to go by the book, using a set of online documentation found here and here.

Before I continue, let me jump to the end of my configuration story. I banged my head against the installation for several hours trying to get it to work. I wasn't aware that I needed to set up my machine as a DNS server first. Perhaps this should have been obvious to me (as it's the same prerequisite for AD), but I missed the boat. I followed the documentation and, as near as I can tell, there was no official prerequisite I didn't meet, leading me to believe the documentation needs work.

A seasoned Linux associate helped me troubleshoot my woes. After determining what was wrong, I tore down my entire setup, loaded DNS (BIND version), set up a zone for my sample organization (company.com) and started again.

Now I was able to smoothly install FDS, with one small snag: One screen during the installation noted some tuning parameters and declared, "The above errors MUST be corrected before proceeding." According to my Linux associate, the "errors" were more like recommended real-world suggestions; in reality I was in the clear.

The installation now proceeded smoothly, and I was finally ready to actually do something with my new directory. Unfortunately, the documentation threw me again. I got to a line in the installation text that read, simply, "Launch Administration Server Console."

How? I was stumped. It took me another 20 minutes to find another RDS document, which described the commands required to run the console.

I launched the console and immediately got an explosion of arcane Java error messages for my trouble. As I learned from reviewing the FAQ, the console requires a package that wasn't present in my Fedora Core 4 installation.

Once that was solved, the console blew up again. This time, it took my Linux guru 20 minutes to determine that I had a simple DNS misconfiguration. The console simply couldn't find the server.

A seasoned Linux pro may sidestep these installation wrinkles, but many Windows admins will be climbing the learning curve with RDS/FDS. Something as simple as a walkthrough guide would have made my experience much less stressful. If the Red Hat team can firm up the documentation a bit, it should go a long way toward making RDS/FDS deployments less trying for Microsoft-centric shops.

Back in Business
With the console finally up and running, I was cooking with gas. Figure 1 shows the main Directory tab, where user configuration takes place. This is a nice improvement over OpenLDAP, which lacks an official console. And unlike OpenLDAP, FDS/RDS doesn't need to be specifically pre-populated via arcane Lightweight Directory Interchange Format (LDIF) files just to kickstart it.

[Click on image for larger view.]

Figure 1. The FDS/RDS GUI console allows administrators to perform some familiar tasks.

The administrative console is a bit clumsy, with a maze of tabs that configure the directory and users within it. But it does perform all the standard functions that seasoned AD admins have come to know and love: create users, groups, organizational units (OUs) and the like. Moving users from OU to OU isn't quite drag and drop -- it's more cut and paste -- but it works well. It's also convenient, because just about every directory attribute and configuration parameter is accessible via this one-stop console interface.

One oddity is that the same username can be shared by more than one user -- say two people named Sally Jones, each with a username of sjones. One can be in the Sales OU and one in the Marketing OU. Technically, these aren't the same account, because they're in different OUs, have different Distinguished Names and unique User ID numbers (UIDs), which are similar to AD Security Identifiers (SIDs). This is something an admin will obviously want to avoid -- it's confusing to have two users with the exact same username.

Setting up users and groups from start to finish can be a chore as well. This is because right now, RDS/FDS doesn't automatically dole out either UIDs for new users or Group IDs (GIDs) for new groups. The administrator is expected to manually enter these values.

This gets tedious fast, especially because the required attributes aren't enabled by default for any user. In short, it's a lot of clicks to add the attributes, add the UID, and then keep track of the UIDs in a spreadsheet, for example. If there was a better, more automated way of using the GUI, I didn't find it. If you manage thousands of users, you probably rely on scripting for heavy lifting while adding and deleting lots of user accounts in FDS/RDS. Still, a more streamlined GUI would be welcome.

More troubling is the fact that the RDS/FDS GUI console allows you to perform "illegal" tasks. For instance, it's natural to want to create an OU and put a user inside it. However, I was able to create a new user and put a new user inside it. Yes, you read that right -- the GUI didn't care that I wanted to put a user inside another user.

Once I set up a bunch of test users and groups, I was ready to have my Linux clients authenticate to RDS/FDS. I used the Red Hat documentation to authenticate my Fedora Core 4 client against it. I soon learned that the documentation was incomplete. Once again I turned to my Linux expert, who helped me enable Linux client computers to get home drives as they logged on. Lacking this crucial step, logons completely fail.

Plays Nicely with Others
Despite the bumps in the road, it's clear that Red Hat tried to make RDS/FDS as "Windows-friendly" as possible. For companies considering a move off of NIS, this could motivate a migration to FDS/RDS instead of, say, OpenLDAP.

RDS/FDS ships with two Windows .MSI installation files, which install the running code on your DCs. One application is for a DC within an AD domain and the other for Windows NT domains. The .MSI files help automatically populate Windows accounts in RDS/FDS, so if someone creates a Windows user, that user has a replicated account in RDS/FDS. Then, when the user logs on to a Unix workstation or server, the account is validated against RDS/FDS. Voilà! Single sign-on across platforms.

[Click on image for larger view.]

Figure 2. RDS/FDS ships with software that runs on a domain controller to help with user and password synchronization.

Figure 2 shows the information required by the RDS/FDS application that runs on a DC. You need to tell your DC about the RDS/FDS server, the accounts to which it has access in order to perform updates. In my tests, I chose not to use SSL encryption, but having all data encrypted on the wire (if you use SSL and certificates) is certainly a welcome and suggested option.

The next step in getting your AD and FDS/RDS to work together occurs on the RDS/FDS server. The guide can be found here, but multiple documentation errors led me to contact Red Hat for direct support. The documentation should be corrected by the time you read this.

[Click on image for larger view.]

Figure 3. Connection Agreements allow you to bring AD OUs and folders to the RDS/FDS server.

I was able to set up the "Connection Agreement" as seen in Figure 3, which brought a specific AD OU (or folder, such as the Users folder) across to the RDS/FDS server. But without automatic UID and GID numbering for users and groups brought into RDS/FDS, you have to input the numbers manually, decreasing the synchronization benefits.

A Leg up on AD
RDS/FDS does offer a neat trick or two that might make users of AD a little jealous. First, RDS/FDS has the ability to create dynamic groups based on criteria. While I didn't specifically test this function, it seems like a promising idea. For instance, I'd love to be able to create a group in AD for anyone with "Nurse" in the "Description" field.

Another welcome feature is the ability to create a read-only copy of just what you need out of RDS/FDS. For instance, you could publish a corporate phone book right out on the Internet fairly safely with RDS/FDS: Just set up a replica server to be read-only and publish the fields you need, such as user name and phone number. With AD, all DCs are writeable, and when you replicate, you must replicate all fields and attributes to all DCs. Hence, leaving an AD DC out on the Internet to use as a phone book could be a potentially serious vulnerability.

Lastly, RDS/FDS does something many AD administrators have been clamoring for: per-OU (or even per-user) password policies. For instance, you can have different password lengths and expiration times between the Sales OU and the Marketing OU. RDS/FDS does this with relative ease.

Complaints about documentation aside, RDS/FDS is a very impressive product. With multi-master replication, built-in GUI and an AD-friendly approach, Red Hat's directory services offering seems well-placed for companies managing both Windows and Linux clients.

Room for Improvement
Red Hat faces a challenge of timing, however. OpenLDAP has already captured the allegiance of many Linux shops that have moved from aging directory services like NIS. Still, any IT department seeking to tighten integration between the Windows and Linux worlds can do so by deploying RDS/FDS.

Can RDS/FDS ultimately gain prominence in the Linux directory services space? Maybe, if Red Hat embraces three strategies to make it a reality.

1. Make the documentation much easier to understand and follow -- even for Windows administrators. Today, getting through the documentation and creating a fully functional RDS/FDS system is difficult at best. I had to contact Red Hat support and my Linux propeller-head friend multiple times to get it working right.
2. Make the product work the way administrators work. Today, the built-in GUI console is a nice differentiator from OpenLDAP (although there are GUI tools which can be used alongside an OpenLDAP implementation). Because RDS/FDS doesn't automatically assign UIDs or GIDs, click-click-clicking through the console becomes more of a burden than a boon.
3. Make the hard stuff easy. For instance, a wizard-driven interface could greatly simplify the setup of multi-master replication, dynamic groups or partial-attribute-set replication.

These shortcomings, however, don't preclude RDS/FDS from evolving into a complete directory services solution. As with so many 1.0 product releases, RDS/FDS should improve significantly as Red Hat irons out the wrinkles.