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.

@dbeato Truth ^ ^ . To be a grown up directory and support a scalable architecture, this is why we implemented Groups and sunset 'Tags' - which were more of a model dedicated to matrix-based server/user account management.

@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.

@dbeato And this one... https://jumpcloud.com/engineering-blog/welcome-to-groups/

@dbeato The mother load: https://support.jumpcloud.com/customer/en/portal/articles/2703450-getting-started-groups

@dbeato The AD Bridge is in fact in the process of being upgraded. We recently made a fairly large overhaul to our grouping mechanism (it was the object called "Tags") to a proper grouping mechanism. We're re-working the APIs on our AD Bridge synch agent to point to the appropriate new objects.

@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!

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

@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)

Greetings folks!

Nice to see a few of you contributing to various JumpClodu threads. Let me give you a bit of background on 'why Servers' with JumpCloud...

Roll back time: It's where we began. The original instantiation of JumpCloud was to provide a central authentication and management console across Linux/Windows servers in any cloud service (e.g. AWS, Google Cloud, Rackspace, Softlayer and so on). The main thrust of what we were doing/offering (and still offer) fairly progressively, was to provide REST services to stimulate the efficiency of large-scale server infra - and mainly very ephemeral infra. The use cases varied but generally speaking, DevOps guys would bake our image into an AMI or similar image, and when they would light these up, they would perform initialization routines against the JC Directory....drop users accounts on, enable POSIX Groups, deploy sysadmins SSH keys, etc etc. It became a 'thing' and basically obviated the need for LDAP servers and wrangling with PAM. Yes, there are super elegant methods for this now....but mainly codified. e.g., Chef, Puppet, Salt, etc. These are actually used in concert with us but there is overlap.

FWIW, feel free to geek on this KB and go play with our APIs and SDKs on Github:
https://support.jumpcloud.com/customer/portal/articles/2429680

This use case is still extremely important for our customer base. We see a typical pattern of companies evaluating us, driven by DevOps where they get to get 100's or in the case of quite a few customers of our larger customers, 1-2K virtual servers. They find success and this bleeds to general IT *(e.g. those servicing rank and file employees and their personal systems, networks and apps).

So that's effectively the story, absolutely feel free to ping us to go deeper in the server management side of things!

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