In-Depth

Bridging the Directory Services Gap

Red Hat Directory Service helps join Windows and Linux environments.

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.

You look nice in that Fedora.
[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.

Thank god for user and password synchronization.
[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.

Do you agree to take this AD OU to your RDS/FDS server?
[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.

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).
  • Configure your Linux clients to create home drives when users log on.

-- J.M.

comments powered by Disqus

Reader Comments:

Thu, Jan 7, 2010 eda

hi, i found a new website that has unlimited text to all network not only that you can find new friends and chat with them, here's the site http://www.txtmate.com/.

Thu, Jan 7, 2010 eda

hi, i found a new website that has unlimited text to all network not only that you can find new friends and chat with them, here's the site http://www.txtmate.com/.

Wed, Apr 30, 2008 Adam Hamilton Edinburgh

FWIW, AD can now do read-only DCs and per-OU password policies in its Server 2008 flavour.

Tue, Oct 31, 2006 Carsten Due Virginia

I guess Lunx Means Linux :)

Tue, Oct 31, 2006 Carsten Due Virginina

This article was exactly what I was looking for and a quick email to the writer (Jeremy Moskowitz) confirmed what I needed to know, the two way synch between LDAP and AD. Now there is many directions this can take and the particular direction I was looking for was the migration path from LDAP to MS AD. Also I cannot agree more with Jeremy's comment about the documentation available for Lunx based Software. Its scaringly inadequate and makes far too many assumptions. I will make sure to check out his other articles as well since I DO like realistic facts based on actual testing and discovery. Thanx a Bunch!!!

Tue, Aug 29, 2006 Richard Anonymous

Not sure where the better than NDS/eDirectory came from. Combine eDirectory with DirXML and you have the worlds best Identity Management suite. Everything from Peoplesoft to SAP can come to the party. AD works well for Windows clients, but it is not the most mature feature complete product, you are just forced to use it if you want to use Exchange!

Sat, Jun 17, 2006 Bryan J. Smith Orlando, FL

iPlanet-Netscape Directory and Certificate Server have been major staple in many cross-platform enterprises, and has been for the past half-decade. Sun licensed the LDAP portion for its Sun One years ago. Red Hat just secured the rights to GPL-MPL pretty much the whole thing (sans a few Java-based admint tools) as of late 2004, and this occured as of May 2005. RHDS 7.1 was the initial product and now, in late 2005/early 2006, FDS 1.0 is the result of the new, "cleaned up" (license-wise) codebase that could be considered "7.2".

I am a MCSA-MCSE (including the Security specialty) and have worked with many, many large, Fortune 100 enterprises. iPlanet-Netscape IS MISSION-QUALITY and has been since BEFORE ADS was even available. Integrating iPlanet-Netscape and ADS, including synchronization between their trees, is COMMONPLACE in such enterprises.

Fri, Jun 9, 2006 PowerEds Philippines

Im very excited to test FDS and "join" it with AD. It looks very promising and I hope that UID/GID generation will be automated soon. FDS will be very useful when using Domino in AD and Postfix in FDS.

Tue, Apr 11, 2006 Frank South Africa

RDS/FDS is based on the excellent UMICH LDAP codebase which was bought by Netscape and is proven to be faster than OpenLDAP and many times more scalable.

Wed, Mar 15, 2006 Anon Michigan

FDS has catching up to do to reach AD. AD has catching up to do to reach NDS. NDS has catching up to do to reach ???. Things to make you go hmmmmmmm!

Tue, Mar 14, 2006 Anonymous Anonymous

AD - oustripping NDS?

FX Snigger!

Tue, Feb 21, 2006 Wilmer van der Gaast Netherlands

Mr. Anonymous, without the "unlike Windows, Linux is not intuitive and is practically useless without Man pages and documentation" part, maybe your comment would be credible. But I think most people here are too mature to believe that kind of nonsense. Nothing related to computers is even remotely intuitive. Not Windows, not MacOs, and not Linux.

I just hope companies don't really employ people who think they can administer their important servers with just "intuition".

Mon, Feb 13, 2006 Edwin Antczak USA

Valuable insights to progress of DS for the masses.

Sat, Feb 11, 2006 Raymond Rohnert Park

FDS sure has a huge potential. I have been playing around with it and really document is right now the most important thing they need to do. They have a lot of info but not enough on the basics. Again, documentation is key. I have been working on a project, trying to get FDS to work for Authentication and single sign on, and using Linux for a desktop environment with a KDE platform, which with the Kiosk Admin Tool allows you to lock down a desktop either by user or groups, sort of like group policy. Using Open Office and Evolution as an Email Client, and something like OpenGroupware.org for an email server. Haven't quite worked it all out yet but the pieces are starting to come together and I believe can provide a good cost saving alternative to Microsoft AD Network. Which for a business can have the benefit of saving thousands of dollars. Yet Fedora Directory Server definitely still has a lot of growing but keep your eye on it. It can turn out to be the Microsoft killer.

Thu, Feb 9, 2006 Anonymous Anonymous

"It's a nice little start, but I wouldn't recommend this any time soon. AD is still the enterprise level solution, 6 years ago W2K was better than this so RH got a lot of catching up and polishing to do, not to mention documenting (unlike Windows, Linux is not intuitive and is practically useless without Man pages and documentation). If RH can make their directory service at least a good, robust etc as W2K AD, I may run it instead of Microsoft, after all it's free. Wouldn't pay for this over AD though..."

Oh please give me a break. AD is only an enterprise directory service if you have a predominately Windows base. Nobody else would consider AD a viable directory service. AD was not better than this six years ago, it is still inferior today to the Sun/Netscape server on which FDS is based, as well as Novell E-Directory. RH does not have to make this product as robust as AD, it is already better than that. Sites based on this code run government directories and commercial directories with hundreds of thousands or even millions of users. Yes, if you are running nothing but Windows, AD has been highly customized and is probably your best bet. But, don’t be so clueless as to think AD is a true cross-platform enterprise solution.

Thu, Feb 9, 2006 Anonymous Anonymous

It's a nice little start, but I wouldn't recommend this any time soon. AD is still the enterprise level solution, 6 years ago W2K was better than this so RH got a lot of catching up and polishing to do, not to mention documenting (unlike Windows, Linux is not intuitive and is practically useless without Man pages and documentation). If RH can make their directory service at least a good, robust etc as W2K AD, I may run it instead of Microsoft, after all it's free. Wouldn't pay for this over AD though...

Wed, Feb 8, 2006 Anonymous Anonymous

"One oddity is that the same username can be shared by more than one user"

Sorry, but this is not an oddity, it is the way LDAP works. The RDN of an entry must be unique to other entries of a common parent, but this behavior is the norm.

Tue, Jan 31, 2006 Ro Hart City of Savage

We are an organization that incorporates Windows and open source technologies into our network and just want to comment that I really appreciate articles like Bridging the Directory Services Gap and Worry-free Web Server(Apache). We currently are using OpenLdap, but I have wanted a multi-master directory service that runs under Linux. Thanks for suppling invaluable information to those of us who run Microsoft and Open Source.

Ro Hart
MIS Administrator
City of Savage

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.