A significant challenge to AWS users is the ability to manage server users. The advent of Infrastructure-as-a-Service has completely changed the game for IT organizations. What once was an on-premise, or within a data center solution has now been moved to the cloud, and with this shift has come a new set of challenges in managing access to those cloud servers and specifically, bridging Active Directory to AWS.
AWS users figured out ways around this problem. They managed users manually by logging into each server and provisioning / deprovisioning users. Others would script access through configuration automation tools such as Chef and Puppet. Some even created a second directory in the cloud through a Microsoft Active Directory instance or by using OpenLDAP.
However, though each of these workaround approaches solved some problems, they also left residual issues. For instance, manual and scripting methods were prone to errors, insecure, and time consuming. And adding another directory instance belies the purpose of a central directory. Some organizations that leverage AWS already have an on-premise directory, most often Active Directory (though in some cases companies use LDAP or Google Apps, although GApps isn’t really a directory and nor does it connect its user identities to AWS without a third party solution).
The core AD user store is where IT manages users and predominantly Windows-based assets. As such, IT admins would like to leverage the existing directory as the user store for their AWS infrastructure. The problem, of course, is how do you get each user store to talk to each other? Opening AD to the Internet is generally a bad idea, and further, many of the servers at AWS are Linux-based which doesn’t work seamlessly with AD.
At JumpCloud, we’re focused on solving the problem of managing cloud server users and a whole lot more with our Directory-as-a-Service® platform. Our goal is to be the core directory service for an organization and let users connect to whatever IT resources they need including systems, applications, and networks. As the market shifts to leveraging more AWS (and other IaaS providers), the central user store must be connected to these infrastructure components. The trick, though, is how to bridge the two together. We’ve figured that out. JumpCloud’s Directory-as-a-Service accomplishes this by securely bridging existing AD instances to cloud infrastructure.
Here’s how it works.
To bridge existing AD instances to cloud infrastructure, you install a lightweight agent on your AD server. That agent talks to JumpCloud to keep the users that you want to have access to the cloud in sync. Any change in AD is automatically replicated to JumpCloud—immediately. JumpCloud then securely manages access to the cloud servers. JumpCloud’s DaaS service integrates a lightweight agent that is installed on each cloud server and controls user access. In both cases, user data from AD is the source of truth for access.
With this approach companies benefit by having:
- one core user directory
- tightened security
- increased control, and
- improved visibility.
A central directory service takes the complexity of managing connections between users and IT resources and makes it as simple as possible. Manual and scripted user access changes are security risks as are sharing of passwords and keys. A cloud-based directory service to bridge access to AWS infrastructure ensures that IT has control of who has access to what and that all cloud infrastructure is being managed. And, Directory-as-a-Service provides clear visibility and accountability for access rights.
JumpCloud Can Help with Bridging Active Directory to AWS
If you have AWS infrastructure and aren’t leveraging your existing Active Directory to manage users, take a look at how JumpCloud can help. In just a few minutes you can completely bridge your Active Directory users to your cloud infrastructure. Sign-up for our free account—10 users are free forever—and give it a shot.