TOM KEMP'S CENTRIFY BLOG

Why was Centrify formed? Part 2 of 3

Wednesday, February 28, 2007

In Part 1 of "Why was Centrify formed?" I discussed how I and my fellow co-founders identified a need for Identity Management as well as policy and configuration management for the growing Linux market. Yet as we looked at what we could do in this market we were worried that we did not want to offer yet another directory that a customer would have to manage. Even if we built the best directory for Linux and beyond (e.g. UNIX), the reality was, and still is, that at least half of most organizations' infrastructure runs on Windows and, by default, they would have to be using Microsoft Active Directory.

The fact is, since it was introduced as a key feature of Windows 2000, Active Directory has become the key security DNA behind the Windows platform given the tie-in between Active Directory and the Windows desktop and applications like Microsoft Exchange. In other words, Active Directory is ubiquitous and irreplaceable, so it ain't going away anytime soon because Windows is not going away anytime soon. Over 60% of customers were running it in production in 2004 (I believe the number now in 2007 is over 85% of all small, medium and large companies have Active Directory deployed).

So the idea was hatched that, instead of building an "(Active) Directory server for Linux" to address the market for Linux-centric Identity Management, why not actually build a set of "Active Directory clients" for not only Linux, but also to the wide range of non-Microsoft operating system platforms (UNIX, Mac, etc.) as well as non-Microsoft application platforms (Java/J2EE, Oracle, DB2, SAP, etc.) that talk back to the Active Directory server? This approach would effectively enable UNIX, Linux and Mac servers and workstations to participate in an Active Directory domain, and enable an organization to secure their non-Microsoft systems using the same authentication, access control and Group Policy services currently deployed for their Windows systems. This meant that many of the classic Identity Management problems (e.g. controlling access, single sign-on, etc.) could now be solved for this new platform, but instead of deploying a new server infrastructure you could leverage an existing technology that you already have.

We thought this was a cool idea. Stepping back beyond just looking at the Linux platform, we knew that in today's IT environment it's a given that an organization's computing environment will be comprised of heterogeneous operating systems, network devices, storage systems, databases, applications, etc. We felt that with this idea implemented, we could make that heterogeneous environment look and feel like a homogenous environment from an authentication, authorization/access control and auditing perspective (the classic 3As of Identity Management). And we could do it by embracing and extending a technology that the customer has already deployed and has a deep skill set in — Active Directory.

We also liked this approach because most traditional Identity Management vendors were not going to go down this path because they already had their own competing directories to Active Directory, or they had too big of an investment in a synchronization-based approaches versus an Active Directory-centric "embrace and extend" approach. We also felt it would allow us to partner with a "Gorilla" in the industry but not be in a situation where that Gorilla would want to go directly into our space, because Microsoft has never shown an interest in building software on other platforms beyond Windows. And finally we also felt the technology approach we wanted to take would be appealing to customers because our implementation would not require any changes to backend Active Directory.

Finally, what made this idea very compelling was that really nothing much existed in the market for Active Directory-centric approaches to solving cross-platform Identity Management. We saw that there were bits and pieces of Open Source (e.g. MIT Kerberos, PADL's pam_ldap and nss_ldap, etc.) and a few small commercial solutions out there, but they were all just pieces of the 3A puzzle, were highly intrusive, and lacked an integrated architecture as well as basic enterprise capabilities like having centralized management tools. Ironically, the commercial solutions that were out there that had an Active Directory-centric approach were not even the first to market. In an odd twist of fate, it turns out that my two co-founder's former company actually built a commercial product called DirectoryPlus back in 2000-2001 that integrated non-Microsoft systems into Active Directory (for storage devices that ran Linux, making it the first commercial solution to integrate non-Microsoft systems with Active Directory), and we were quickly able to acquire that technology as "soup-starter" for our product development.

So with the idea in hand that met our criteria for a good business as well as initial technology to leverage, we decided to not really ramp up this new venture until we did one last key thing — validate that customers would really buy this stuff. That will be the topic of Part 3 of this blog post on "Why was Centrify formed?"

< Previous Article: Why was Centrify formed? Part 1 of 3
> Next Article: Why was Centrify formed? Part 3 of 3