Bridging the Directory Services Gap

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.

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.

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.

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.

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.

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.

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.

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.

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.

More Information

Using Active Directory To Manage Linux Directory Services

Red Hat FDS/RDS offers a welcome bridge between the Windows and Linux worlds,
allowing some account information to flow between FDS/RDS and Active Directory.
But you can also centralize all your account management within AD. There are
a couple of options available to IT managers:

Use a third-party tool: There are two tools that can help you utilize AD as
your "go to" point for Linux clients: Quest/Vintela
VAS or Centrify DirectControl.
These tools have native installers for all sorts of Unix and Linux platforms.
Once loaded, the Unix and Linux clients authenticate directly to AD.

Use SFU 3.5 or Windows 2003/R2 to "enhance" the AD schema: It takes some work,
but IT managers can manually configure each Unix/Linux client to use the enhanced
AD schema. The process can be time-consuming, but in the end, you can have your
Linux clients authenticate directly to AD. The Reader’s Digest version goes
like this:

Tell each Linux client to look up AD account information via LDAP.

Authenticate to AD via Kerberos.

Tell each Linux clients where in AD to find Unix account information (which
is different for SFU 3.5 than for Windows 2003/R2).