Best posts made by gregorymkeller

Greetings folks. My name is Greg Keller - I'm JumpCloud's Chief Product Officer ...so the product, its concept, and execution, falls on me. I am here to keep it technical and non-trolling (I would appreciate that of vendors on the threads I visit too). What I see here is deep passion ...and I love that. Our product was conceived initially to manage server infrastructure, primarily Linux (as was suggested above) before moving into the more traditional 'directory' space. So yes, we are covering user management, event logging, script execution and MFA (Linux and Mac) for desktops or virtualized Linux, Windows or Mac. I speak with 100's of customers a month either in person/directly in their company or via phone or webex and I hear a same constant story. Those who approach us almost exclusively have no Microsoft expertise on staff and are not interested in running directory software or servers any longer. In those cases, it is extremely hard for them to manage Microsoft. We target non-Microsoft organizations in large part. In most of these cases there 'may' be an LDAP present, but very likely their Directory literally is Google (G Suite) and have no strong unification of identity (e.g. covering their machine, web app or network authentications). The pattern is almost identical and they gain value nearly immediately (most typically leveraging LDAP-as-a-Service or RADIUS-as-a-Service features before moving deeper into other integrations). So, sincerely, our small yet growing company is seeing fairly substantial success in these profiles of customers...thousands of them...and they honestly may not look like yours. I would love to chat at any time with any of you but we first invite you to look at the product for free to truly assess for yourselves. It is exactly why we offer our free version...as well as to ensure small companies who can't afford time or capital for Directories have a great system to ensure better security for their own growing companies. Thanks for taking the time to read. Regards - Greg.

Hey folks! Let me provide some feedback for you all on this thread. Absolutely feel free to ping us - our support engineers and my product team and I can dive deep with you to problem-shoot your implementation ideas and strategies.

@bigbear - You are correct in that we are not, in the exact sense, a Remote Desktop Session Host provider. Lots of customers, do, drop the JC agent on the virtualized Windows system, bind the users they want deployed on the box to access it, apply policy on the box via our commands execution facility and finally RDP into the system. But you are correct, that is not exactly what we've built. We're also not quite an AWS-style Directory Service - which really is designed and positioned to synch with on-premise ADs to authenticate servers and VDIs in AWS. It's truly more core AD alternative and specifically the base authentication for our customer's system (Mac/Win/Lin), networks (via RADIUS) and apps (via LDAP and SAML). As for DaaS versus some other acronym - we're all certainly flooded with them...Directory as a Service is what it means and what the public started calling us early on. Probably before 'Desktop as a Service'. We liked it...stayed with it.
@dbeato Spot on.
@scottalanmiller You can't change a password locally on the host (yet)...all changed to all endpoints connected to the identity get updated instantly when the employee changes through their web portal. This said, the credentials on a system are locally cached and remain encrypted, not unlike a Windows host bound to a domain does when it's off the domain or off VPN. It will use the last good/known hash to authenticate.

Hope this helps you all and thanks for the great discussion!
Greg

@scottalanmiller Ah! Well, in fact, that is architecturally what's going on. In all of its nerdtastic glory...

(hit this link if image doesn't display: https://www.evernote.com/shard/s33/sh/4ef4d6a3-f38d-4217-a8ff-2a28fa63ef1b/92cb5a9f8d997ff4)

@scottalanmiller Grazie! Your markup skills are better than mine apparently!

@bigbear - I pinged the crew to see if they have any direct customer experiences and the team indicates it should work fine. The agent gets dropped on the RDSH and when we provision or bind to local accounts on that box, we drop those users in the RDP user group too. That system can not be domain joined obviously (the agent install will reject it, regardless). Give 'er a try!

@dbeato The Group, and our microservice/graph engine behind, it is the key here: the Group is bound to 'things' (RADIUS servers, systems, LDAP RBAC and SAML apps - more soon). Users get added, they get access to the connected 'things'). User is removed, they are revoked access. So think network, application, and system resources here.