Directory as A Service: Part 1 – Intro & Setup

Directory as A Service: Part 1 – Intro & Setup
Directory as A Service: Part 2 – vCAC Integration

jc_100_wI have been playing with an interesting new service from a startup based just down the road in Boulder, CO called JumpCloud.  In their own words:

“JumpCloud’s Directory-as-a-Service (DaaS) securely connects employees and IT resources through a single, unified cloud-based user directory. It is the single point of authority and authentication for a business’s many employees and access rules.”   link

I take this to mean it is a hosted directory service.  Interesting concept, which I bet is met with a ton of resistance from those that fight off-prem services but I’ll leave that topic for later discussion and focus on the technology right now.   I wanted to see how I could integrate this into VMware’s vCAC so that is what I built.   I’ll split this into two posts.  This first one will just cover setup, the second will be the integration.

First Impression
I have to admit, I really enjoy companies that make it super easy to try out their offerings.  JumpCloud offers 10 managed nodes for free then gives a one line exact syntax for how to deploy the service at the command line with your account credential already in place.  They also have a full example for Puppet and Chef similarly configured with your credential.   Literally cut, paste, go.  But more on this later.

Walkthrough of first time use

When you first login to the console you are met with a simple interface and nothing configured.  Let’s walk through initial configuration.

The first step seems to be to add users:

Snip20141016_28

Once we add our user, Mountain, we see his account is in a pending state.

Snip20141016_30

When the Mountain checks his email, he’ll see the activation message.

Snip20141016_31

And when he clicks on it he can set his own password

Snip20141016_32

And lastly, The Mountain is automatically presented with a multifactor authentication code that you can scan directly into Google Authenticator.  This is a killer feature in my opinion!

[ don’t worry about trying to steal these credentials, it won’t get you anywhere! ]

OK, now that the account is setup we see we have one more notification for this user:

Snip20141016_34

Tags seemed a little confusing to me when I got started.  They appear to be the only grouping mechanism, so it is how you associate users to systems.  My guess would be you would assign your developers to the development machine tag, and your system administrators to some sort of all machines tag.   I went ahead and created tags that JumpCloud used in a few of their demo scripts.

We setup a tag for all servers, and give the mountain access

Snip20141016_36

We continue on and create a few more

Snip20141016_37

Now the cool part.  Before when I mentioned I love when companies give simple ways to try a service?

Snip20141016_26

 

So we cut/paste this syntax in a newly provisioned CentOS VM and it does everything for you

Snip20141016_39

 They have some sort of dynamic HTML on many of the console web pages, so when this command is run the empty previous screen is replaced with a system listing.

Snip20141016_40

Notice we do get an alert regarding no tags automatically are assigned to the system.  I’ll explore this in my next post on integrations, but for now we do it by hand:

Snip20141016_41

I’m not clear what’s going on behind the scenes (if it’s a push to the agent, or a reoccurring check in or what) but shortly after we see that the mountain is added to the passwd file on this centos machine:

Snip20141016_42

Now if The Mountain tries to login at this point he will be denied?  Why?  Because if we look at the system details we see the default configuration is locked down pretty tight allowing ONLY public key authentication.

Snip20141016_43

If I go ahead and click each of those buttons to allow root, allow password auth, AND allow multifactor   (because I like to be safe and dangerous all at the same time….it’s a lab after all).  The Mountain is now happy he can login.  Notice the prompt for the multifactor token WITHOUT ANY OTHER MANUAL CONFIG ON THE SYSTEM.  That. is. awesome.

Snip20141016_44

 

Other stuff?
That’s it for the basics.  They have additional functional to configure sudoers via the JumpCloud console but I’ll leave that alone for now.

Overall thoughts
Given how young this startup is, I will give a pass on some of the few negatives I encountered (like UI problems in safari, maybe other features I would want to see like simple user grouping, on premies AD integration, windows host support).  What they have now works pretty well and they make it super easy to use.  It took me a little while to find the API information but when I did I was able to do the automation I will show next.    In short, this technology has promise for either the small environment that has absolutely no on prem environment, or for any sized organization to help with strictly access control on systems.


Full disclosure: I didn’t just happen to stumble upon JumpCloud as I know their Cheif Product Officer from the local cycling community here in Colorado, though I am not being influenced with free bike parts or beer to give their service a whirl.  Yet.

Tagged , ,

One thought on “Directory as A Service: Part 1 – Intro & Setup

  1. […] Directory as A Service: Part 1 – Intro & Setup Directory as A Service: Part 2 – vCAC Integration […]

Leave a Reply

Your email address will not be published. Required fields are marked *