Why was Centrify formed? Part 3 of 3

Thursday, March 1, 2007

In Part 1 of "Why was Centrify formed?" I discussed how I and my fellow co-founders identified a need for Identity Management for the growing Linux market, and in Part 2 I described how we translated that need into a solution we thought customers would want — the ability embrace and extend Active Directory to non-Microsoft systems, applications, databases, etc. to address their identity and access management needs. But would customers buy it?

So in early 2004, with our idea in hand, we next set about validating if customers would really go for this concept before we put our foot on the accelerator and built a company around this idea. I think we have all seen many software startups have a great idea on paper, raise money and develop a product that maps to that idea, and find that when they actually enter the market they have missed what customers are really looking for and/or their solution is perceived as not being a "must have." The end result is that one to two years of investment (and money) is down the drain, and they must dream up a Plan B real quick to survive. We obviously wanted to avoid that scenario and were curious what real customers thought of this idea, even if they had never considered it possible to use an Active Directory-centric approach to solve their cross-platform identity and access management problems.

Going into this validation process we believed the two biggest hot buttons for customers to our Active Directory -centric approach would be in the areas of (a) improving security (reducing the number of identity stores and thereby reducing the likelihood of having orphaned user accounts, being able to apply a consistent security policy across disparate systems, etc.) and (b) improving the efficiency and productivity of both the end user community (by giving them single sign-on) and the IT community (by reducing the calls to the helpdesk, reducing the number of tools they would have to use, etc.).

I distinctly recall the very first customer validation meeting that we did in early 2004. We were in a room full of UNIX and Linux admins (there was not a Windows or Active Directory -centric person in the room) at a large Bay Area-based company that had 600+ UNIX/Linux systems. After intros I went ahead and did a three-minute verbal spiel on how our solution will extend Active Directory to UNIX/Linux; how we will provide an agent that is an "Active Directory client" that in effect makes a UNIX/Linux box look and feel like a Windows box from an authentication, authorization and Group Policy perspective; how we will give end-users single sign-on leveraging Kerberos; how we will eliminate having to create user accounts on each local system; blah blah blah, etc. I then paused and decided to stop and get immediate feedback to this elevator pitch and asked "so what do you think so far?"

There was stunned silence. I don't think any of them had even thought about this approach we were embarking on, because, after all, Active Directory had always been a LDAP/Kerberos-based system that just worked for the Windows environment, and was not something they could or would consider for their non-Microsoft platform. "Oh oh" I thought to myself, "these UNIX guys are clamming up because they don't like the idea of using Active Directory for their UNIX boxes."

But a few seconds later I saw that the folks in the room began to nod their heads, signaling their positive interest in the idea, and the manager of the UNIX group then spoke up and said to the effect of "Actually, this is a good idea because we are getting slammed on SOX compliance, and this can definitely help us address it." He then went on to say, "This seems like a much easier-to-deploy solution and much cheaper way to address compliance than the alternatives we are considering." Then he and his team started giving examples of how many of their UNIX systems did not support password aging, so they had admins who had not changed the root password in years, etc. (I could not write down all the examples because they were going so fast). The net net was that in effect they knew they were out of compliance and our Active Directory -based solution would make it easy for them to become compliant. I will devote a separate blog entry on how Centrify addresses compliance, but feel free to check out three compliance whitepapers we have posted here.

Now we always felt back in early 2004 that compliance would be a key driver for our solution, but once we started talking to customers we quickly found it was THE "hair on fire" top priority, much more so than improving security or giving end-users single sign-on, etc. And because we solved this problem in a creative and cost-effective manner, I think it overrode any potential biases people may have had about using Active Directory for non-Microsoft systems.

I also think UNIX admins that we talked to then and today also like the way we went about this Windows-UNIX integration by supporting UNIX standards such as Pluggable Authentication Module (PAM), Named Service Switch (NSS), RFC 2307, etc., so they have a warm fuzzy on how we are going about things. And once some of the UNIX-centric people found out that Active Directory was not only a robust LDAP directory but also offered great features such as Kerberos and Group Policy (which other directories do not provide, including UNIX-based ones), and it was already successfully deployed within their own environment and was working quite well, it then became seen as actually a safe technical choice. (I will further address the question of "why use Active Directory" in a future blog post.) Finally, what we also found back in 2004 — and it is even true today — is that a lot of the biases against Microsoft and Active Directory that people may have had a few years earlier had in fact faded, because Active Directory is being used by the UNIX admins every day as part of accessing Exchange. Customers have not had any problems with Active Directory availability and reliability, and they have accepted it as a key part of the DNA of their IT environment.

So what we learned through this important validation process was that customers did in fact really like our "embrace and extend" approach because it allowed them to leverage a pre-existing infrastructure and pre-existing skill set. And it was (and still is!) perceived to be a much more economical approach vis-a-vis the big ticket items being sold by legacy identity management vendors to address the same problem. Not only did we get validation of that, we also got a greater appreciation surrounding our solution's ability to address compliance that made it a must have solution, so customers would have a sense of urgency to purchase our software, which is always a good thing if you are a software vendor. That knowledge also helped us further shape the product and helped us in the future better describe how we can meet a customer's compliance issues. So with clear guidance from customers that our proposed solution was something that addressed a real point of pain and was an innovative and cost-effective approach to their problems, we put our foot on the accelerator and started hiring like crazy, raised a bunch of money, and started building a great product. And so far so good, as the market has validated our product and approach with 200 customers in a year and a half of selling software and just three years since formation.

So that's the three-part story on why and how Centrify was formed. Now that I covered the raison d'être regarding Centrify, in some of my upcoming blog posts I will talk about where Centrify is heading with its technology.

Bookmarks:

< Previous Article: Why was Centrify formed? Part 2 of 3
> Next Article: Mac Attack!!!