Alternatives to Active Directory and JumpCloud

[justinboyle]

Hello,

We currently have no central authority for machine authentication in our environment, and all of our users have local admin accounts (I know, I know). Our existing domain services solution is GSuite, and we have a moratorium on any on-prem solutions, so AD is out of the question (I looked extensively into Azure AD and discovered that it is not "AD in the cloud" as I had hoped, so that is not an option either). We looked at JumpCloud to try to bridge the gap, however it appears that that will not work for us either because it insists on, “acting as the authoritative source of identity and control to provision, deprovision, and synchronize users accounts and profile data in GSuite." We need to manage user accounts directly in GSuite, and are planning to automate these account management tasks using BetterCloud (when it gains support for our HR software later this year), so we can't allow JumpCloud to manage, "provisioning and deprovisioning of user accounts."

Are there any other cloud-based domain services solutions that would allow us to bind our machines or otherwise replicate the functionality of mobile accounts in OS X?

Thanks,

J

[thomascosby]

We are in an almost exact situation. I'd be anxious to hear of any solutions as well...

[gregorymkeller]

Greetings folks. My name is Greg Keller and I run product for JumpCloud. First, I hope to see you up at JNUC! Please let us know if you'll be there next week and we can get deep on all this stuff I'll mention below.

I think the crux of this comes down to workflow and a larger more pointed question: 'who owns the password'. As a directory, and one that focuses on ensuring access control to a wide array of services (Win/Mac/Lin systems, G Suite and O365, LDAP, RADIUS and SAML, etc. ) we need to be able to ensure one centralized user object and their creds can be bound to the total array of their assigned resources. As it relates to leveraging Bettercloud or even G Suite's admin interfaces, many of our customers absolutely use those for low-level management needs, but fundamentally, JumpCloud focuses on 'owning' only the following data for G Suite at this time:

-First Name -Last Name
-Email
-Password

To the subject of workflow, JumpCloud does not have to own the user account provisioning chore (and by that I literally mean creating, then pushing, a user object into G Suite). It is a productivity feature, but is not required. From a prototypical workflow perspective, many IT admins like to inject the account into their directory (JumpCloud) first, then push it out to the various resources bound to that user (typically done via our Group object). For example, if you choose to make G Suite access one of the resources you want controlled when it's bound to a user, we just need to 'bind' the JC user object to the pre-provisioned G Suite account. That way, in an off-boarding situation, JumpCloud will suspend them in G Suite, along with turning off access on their systems, networks and apps. <-- Directory 101 stuff. So, you can model your workflow to load the user object from your HCM system into G Suite first, then JC can import/bind to that when you need to take control of its password and account access. Moving forward, when your employee changes their password (often enforced with JC's password rotation rules), JumpCloud will propagate the updated password changes to G Suite at the same moment/simultaneously as the employee's other services. One password, all resources.

There are a number of nuances here that we can work through as it relates to the desired workflow. I just wanted to initially lay out some basics to start the convo.

Hope this helps and look forward to chatting/answering questions.

Greg

[jpartain89]

And this is the number one reason I quit using JumpCloud every time I get the itch to give em another chance...

That information that Greg posted? That is more information in that tiny post than a good half of the knowledge base articles on their website.

They seem to have their sales team doubling up as the KB writers, as they give JUST ENOUGH info to get you to try it out, but then you realize, once you're almost too deep in that, hey, this documentation I'm trying to follow along seems to be lacking in more than one step in almost every single article....

I am a fairly firm believer in the doctrine of "If the company that claims their product does a ton of stuff, but they can't tell ya how? They don't know either."