JumpCloud CEO Rajat Bhargava
Startup JumpCloud was making waves with its server management tools when it occurred to them what they really had was a cloud-based alternative to Active Directory that could address all those resources AD can't reach -- like Macs, tablets, Linux servers and smartphones. Network World Editor in Chief John Dix caught up with JumpCloud CEO Rajat Bhargava to learn about the effort.
You recently repositioned your product to offer a cloud-based directory service. Tell us how that came about.
There were two core components to our product. One was server user management, basically controlling who can access servers and how and when, and all that stuff. The second was for server orchestration, which is basically executing tasks on servers. Over the summer some customers and prospects said, "If you look at this 15 degrees differently, you're actually solving a really interesting problem. You guys have created a system that for servers today, can authenticate, authorize and manage those devices. And if you take those three words -- authenticate, authorize and manage -- that's what Active Directory does. So If you were able to solve that for desktops and for Macs and started being more cross-platform and put it in the cloud, you've come up with a next generation, cloud-based alternative to Active Directory."
So we thought
that was really interesting. We didn't set out to do that, but we can understand how people may want that. So we dug in over the summer and started researching who was doing a cloud-based directory. But we couldn't find anybody positioning themselves as a Directory-as-a-Service or a cloud-based directory, so that's when we started getting really interested.
Obviously there's this fear that, if no one is doing it, why aren't they doing it? It seems sort of obvious. And we kept asking every VC and every analyst we could find, "Why aren't people doing this?" As far as we can tell, basically Microsoft had a stranglehold on enterprise networks and only in the last two, three, four, five years did that change. Mac devices are much more prevalent, you've got Gmail intruding on Exchange, you've got AWS taking all these servers out to the cloud, and it's more Linux based than it is Windows based.
So we think it is really sort of a timing thing. If you would have started a cloud-based directory four or five years ago, you would have run straight into Active Directory and there would be no real reason to change. But today there are so many components of an IT infrastructure that need to be connected to a directory, that it presents an interesting opportunity. We launched that positioning in late September and the difference in term of uptake and understanding of what we were doing was immediate.
Are you doing that solely now? Did you give up on server management?
No. The functionality of the product hasn't changed. We have server user management, we have server orchestration. All those capabilities are still in there, it's just positioned differently as a directory. If you think about it, one of the core components of Active Directory is an orchestration thing they call Group Policy Objects, GPOs, which is how admins control and manage devices. We have that too. We just call it something different. A core part of our product and of Active Directory is that.
And if you're trying to build a next-generation Active Directory you've got to be able to execute tasks on devices. That's how our server orchestration stuff has morphed into what we call device management. Literally all of the functionality is still in the product. It's predominately just a change in how we position it.
When we talk to people about Directory-as-a-Service they instantly get it. They understand what category we're in and what we're doing, even though it's literally the same functionality we do today.
So the problem you see people having with Active Directory today is the range of resources they need to support?
Right. They're struggling with all the resources people need to access. If you have AWS servers, that becomes a separate directory or managed manually. If you've got Gmail, that's outside of Active Directory. If you've got Mac or Linux devices, those are outside. If you've got iPhones and tablets, those are outside of Active Directory. The number of things that Active Directory used to control was virtually 100%. Today it is a different story, so the question is, "How does IT manage all these resources and make them available to employees?"
You want to have one central directory because you want to control one central ID. You don't want to create an ID in AWS, then create another one in Gmail, you don't want to create an ID separately or manage a separate ID for your Mac devices, etc.
How does it work in your world? Every directory call goes out to your cloud?
Not in all cases, but in a lot of cases the auth would come to us, but you can also keep the auth local. We have an agent that sits local and that gives you survivability as well. But the idea is you have this cloud-based system that's across the globe and, if you need to authenticate, you just auth to the closest thing, which could be on your device.
A user I know who is trying to move away from Active Directory says it is hard because it has seeped into everything. Does that represent a challenge for you in terms of replacing some of that?
At bigger companies it's going to be a challenge. That's why we do a couple of things. One is we have what we call an Active Directory Bridge. The bridge can actually work with AD as they have it today, but start to centrally control AWS, Mac devices, Linux devices, all those things.
So you can marry AD to the stuff that is out of reach today.
Right. We bring it into the fold. Active Directory is still the authoritative directory. It just now can extend to everything else. That's thing one. Thing two is, in small organizations with 50 to a couple thousand people, they have an easier time moving. Either they don't have a directory or they're using Google Apps or they're using LDAP, so it's easier to switch them. Or, if they're using AD, it may not be as deeply rooted as in the case you mentioned, and it's a little bit easier for them to pull out.
Over time, I think the number of things that will connect to AD will continue to decrease because you're switching to Gmail, you're switching to more web-based apps, so I think the trend works in our favor. There clearly will be some places that won't be interested in this approach, and some people are going to be scared about having the directory in the cloud, from a security perspective, so they won't do it either.
How do you address that?
We've done a bunch of things. One is, obviously we care a lot about encryption and making sure that the identities are hashed and controlled. We also have built a bunch of layers of network security, and we also create layers with an API key and a connect key. You've got to have a couple of identifiers to even auth with us. So if you've got an application or a server in the cloud they would get these keys, if you will, and without them, your users would never connect with us. We've taken multiple layers to protect everything that's based out in the cloud.
Will your tools stand up to compliance regulations?
We haven't certified ourselves yet, but we're in the process of doing that. In fact, we think we might be an easier alternative for people if they're dealing with compliance regulations such as PCI because then people wouldn't have to deal with all of that stuff themselves. They can just hire us to do it. Our vision long term is that the directory is actually more secure in the cloud because we have layers of security, but also because we will be able to detect when there's compromises on identities. That's part of our path. Today directories have no security built in to them. They might have encryption, but it's not like they detect when an identity has been compromised, and we think that's a pretty big opportunity for us.
Are there any compliance specs you don't think you'll be able to meet?
The only ones we have shied away from completely, that we're going to spend zero time on, are the DoD, military ones. It's funny, we were at AWS Re:Invent and a couple of DoD people said, "No, you really should look at it." We've worked with the military in the past, and everything had to be on-prem and secured and air-gapped, etc., so when they came up we said, we're not a good solution for you. But they were like "No, no, no, you don't understand. We're changing." We're a little skeptical of that one but we'll see.
We haven't spent a ton of time on all the regulations yet but we will over time. I don't see that there should be any significant issues. It's just work.
Is there a sweet spot in terms of the size of companies you target?
Initially, a few hundred people to maybe a thousand, two thousand people. I think that's going to be the sweet spot. Rather than size, it is going to be people that have Macs, that use AWS or have Gmail. Those are great targets for us because they've already taken that step to the cloud and they've already got stuff that AD can't control.
Any pieces you have yet to fill out? Do you have everything you need at this point?
There is more we need to fill out. We have this core directory and we have some major protocols, but we want to surround that with all the major protocols. We have LDAP. We have SAML. We'll do Kerberos; we'll do all these different protocols so any type of application or device that needs to auth, we'll support that protocol.
So you aren't LDAP based?
The database is not LDAP based but we expose LDAP so you can auth with us via LDAP. Part of the reason we built around a proprietary database is because we wanted to surround it with all the open protocols. If we base it on LDAP then the question is how do you hook it to Kerberos? How do you hook it to SAML? How do you hook it to IWA? How do you hook it to RADIUS, all these other things?
So we said let's build our own and then we'll build the interfaces for the protocols we need. That's not something that directories have done. There's two directories out there, really. There's AD, which is effectively based on LDAP and Kerberos. Then you've got LDAP, which is obviously based on LDAP. Nobody has said, "Let's build this directory and give you every single major protocol as a way to auth and control." If somebody builds an application that needs OAuth2, okay, great. You can auth with us via OAuth2. Or somebody builds one that's LDAP based. Great. Use that. That's the thinking.
What is the penetration of LDAP at this point? I presume it's a fraction of the AD base.
Your guess is as good as mine. The numbers we hear are AD is 90%, LDAP and OpenLDAP are around 10%. Who knows? It's amazing that it is so predominately AD though. It's like this silent thing that they don't talk about but over the last 15 years they have created this massive monopoly on the directory side and the directory side is so important because it connects every user to theoretically all IT resources. What piece of software is as important as that? Not too many. You start to think about it and you're like -- Holy Cow!
How do you get in the door? What's your elevator pitch?
It depends on who you're talking to, but basically the pitch is, we're doing Directory-as-a-Service. It's that simple. Everybody is moving to SaaS based services. So, do you want to consider moving your directory to a SaaS based service versus having on-prem hardware, software and all the management headache? You can move that to the cloud as a managed service. That's pitch number one.
Then the questions we ask are, "Do you have AWS, or do you have cloud infrastructure, do you have Macs, do you manage them, do you have Gmail?" Then we dive into, "How do you manage the users on that platform? How do you manage AWS users?" If they say they do it manually or use Chef or Puppet or whatever, we say, "Well, gosh, wouldn't you like that to be tied to your core directory? It's hard but we'll make it easy for you."
Or, "You've got Gmail and you've got AD on-prem. Why did you just move Exchange out? Why didn't you try and move AD out?" "Well, we don't have an alternative to AD." "Do you want to keep AD?" "Well, no. We'd like to be completely in the cloud." "Okay. If you'd like to be completely in the cloud, here's another way you can move more stuff to the cloud."
What about all this talk about federated directories? How do you fit in with that kind of discussion?
Our view is yeah, absolutely you need to have the identities connect to all the IT resources you need. Some people put the fancy name of federation on it. We basically say you have to have one directory and, if its authoritative, it's got to live somewhere and you have to be able to connect that to all the IT resources. So federation is the word people use to say, "I'm taking my AD and then I'm federating it to AWS." We agree you need to do that. Or, "I'm federating it to all my web based apps." Yep. You need to do that too. There are players like the single sign-on guys who have done that for web based apps, but that's only a small portion of the resources everybody needs. They still have their devices, they still have internal apps, they still have servers that they need to manage, all that stuff.
How are you selling it?
Basically it's all online. We do have inside sales too, but basically it's online. You can come in, we give you ten users free forever so people can get used to it, and then from there decide whether it works for them.
Is it pay per seat?
Yes. Ten dollars per user per month. If they have a lot of users, then we'll do a flat-rate deal or give them a discount. It gets cheaper as you buy more.
How does that compare, do you think, with the cost of running AD internally?
We actually have a calculator that we worked up with one of our customers who just signed up. Their contention was that we were definitely in the ballpark, probably cheaper, even over three to five years. We actually built the calculator with them. It was pretty cool.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.