Why the Directory Services battle resembles a Groundhog Day

Groundhog day - Columbia Pictures

Another release, another day....

Many of us have seen or heard about the movie, in Groundhog Day, Phil Connors (played by Bill Murray) gets stuck in a loop in the same day (Groundhog day) in small town in Pennsylvania, only to break it when he changes from an arrogant to a humble individual.

In this opinion post, I examine the similarities between the strategies of many software provides in the context of Directory Services and I will use a very recent example to illustrate such point.  As long as we continue in the groundhog loop, organizations are subject to capability duplication and operational inefficiency.

But first, a quick primer.

Background

We are not going to go back into prehistoric times, let's just talk about the 80s and up.  I have observed 3 design philosophies when it comes to directory services:

1. A Directory service is just a directory, it should be fast, lightweight and efficient.  The best example of this is Netscape Directory.  Others worth mention, OpenLDAP, ADLDS, etc.  The biggest triumph of these type of directories is that they enabled the development of the internet that we know today.
2. A Directory service should contain complementary services and specialized clients:  Novell NDS, NTDS, eDirectory and Active Directory are good examples.  They come from vendors that had a stake on Enterprise Networks.
3. A Directory should be an end-all/be-all tool for consolidation (a Meta Directory) because the modern enterprise (partners and subsidiaries) are complex, therefore these requirements must be satisfied.  

The Pitfalls

Let's examine the common themes:

Groundhog bullet #1:  The just-a-directory approach does not meet the needs of an Enterprise - promotes IT fragmentation.

This is because ultimately a directory service needs an authentication and a policy enforcement mechanism.  So we eliminate philosophy # 1 because it suits internet directories, not enterprises.  The key approach here is OpenLDAP as an Enterprise Directory.  You have to couple it with Kerberos, NTP and some sort of policy engine to make it work in a Unix, Linux or Mac Environment.  So it is not a complete vision.  It also unfortunately requires that the data is synchronized from or to another directory.

Groundhog bullet #2:  Meta-directories are a necessary evil that is too commonly positioned

Anyone that has been involved in a sizable Identity Management project understands the need for a meta-directory.  Not all identity sources (directories) are authoritative for all objects and attributes.  The authoritative source for Employees is the HR System (e.g. PeopleSoft), for business extensions may be your PBX, for email it's  your enterprise messaging system; sub-organizations may be isolated. Meta-directories are the perfect solution for these types of problems, HOWEVER, they are often positioned incorrectly.  Great for the software vendor's consulting arm, but painful for customers.  Pain = too much money + too many resources + too much organizational impact.

Groundhog bullet #3:  Lack of Windows Client

NDS led NTDS and Active Directory in its initial roll-out for a reason they had an excellent client that worked on windows.  Any true Directory contender will have multi-plattform strategy that includes Windows.  Although many software providers don't want to work with Microsoft, but the Authentication Provider APIs (formerly known as GINA) are widely available and documented.  

Novell has been successful by having a multi-platform strategy that includes Windows.

An Example:  FreeIPA and SSSD

With the backing for RedHat, the FreeIPA project started with the right idea.  Let's become Active Directory, but for Linux.  And everything looks great so far:

• An LDAP server (389 Directory Server)
• An integrated Authentication Service (MIT Kerberos) and NTP for time sync
• Integrated DNS 
• Integrated Certificate Authority (Dogtag)

Looks a lot like the comparison I made in this post.  Here are some of my observations:

• FreeIPA overcomes the issue of IT fragmentation by providing an integrated package.  The current roadmap offers good hopes for Enterprises.
• Unfortunately, and probably due to the link to RedHat, FreeIPA's priorities are around Linux at this point, but hopefully they will include a Windows client.  
• Interestingly, and mostly due to avoid a Windows CAL use is a noble goal but the whole thing about implementing an additional directory will be a challenging proposition in any mature environment (maybe in a brand-new RHEL-derivative environment)?
  The CAL usage is not an issue in Enterprise environments.  See my comments about this topic below.
• Finally, the most interesting part is the client (SSSD), it's an improvement over Samba/Winbind or LDAP/Kerberos.

I love what FreeIPA means to competition and customers.  It forces the big players (Microsoft, Novell/NetIQ, etc) to stay on their toes and provide value.  What I don't like is the recommended deployment method summarized in this slide:

Source: This presentation

The meaning to any prospect looking at native AD integration with RedHat is that beyond 30 clients  a new infrastructure is required (IPA) with a Kerberos trust with Active Directory.

What about operational efficiency?  

At Centrify the "Unified Identity Infrastructure" theme is all over the place and on purpose, with no duplication of capabilities, the security and operational benefits can be obtained faster and the cost of compliance goes down.  What is an IT Manager going to say when they hear that they need yet another infrastructure to manage?

This is why at Centrify we always welcome competition during evaluations, it showcases the sad truth that "the devil is in the details" and at the end of the day, the more mature and easier to use solution that does not require additional infrastructure prevails.

I admire RedHat, they are good for the IT infrastructure industry because they provided an alternative to the expensive UNIX distributions, but in this context (AD Integration), instead of focusing on creating a true Active Directory client, they are optimizing SSSD to be a great FreeIPA client.  I also understand them, they don't have an incentive to strengthen Microsoft's position in the Enterprise, but what I don't agree on is when a RedHat salesperson says "With FreeIPA/SSSD you don't need Centrify" that is just simply not accurate and unfair to customers and prospects.

It's early in their strategy and I'm of the opinion that they can continue to develop SSSD's AD integration capabilities while developing a Windows client for FreeIPA;  this will position FreeIPA in a better position against AD and eDirectory; Who knows?  In time a Centrify agent for  FreeIPA can be viable based on market share and penetration.

I will continue to explore the new capabilities of FreeIPA/SSSD and we'll discuss what's new and what's improved in a later post.