A Modern Ops Approach to Managing User Accounts on Your Cloud Servers

Shift to IaaS Breaks Traditional User Management

Organizations have traditionally leveraged Microsoft® Active Directory® (AD) for managing access to their IT resources, including their on-prem or colocated data centers and server/container infrastructure. AD has historically been the source of truth when it comes to who has access to what IT resources, including systems, servers, applications, data, and the network. An organization’s server infrastructure was generally “local” to a domain either by sitting within the domain proper via an on-prem data center or via a VPN to a third party data center. With Active Directory, direct local access was a requirement. 

As cloud infrastructure – otherwise known as Infrastructure-as-a-Service (IaaS) – has gained tremendous popularity, the dynamics of managing container and server user access have changed. No longer is server infrastructure “local” to the network structure. In fact, these days there may not be any infrastructure on-premises at all. It may be hosted at Amazon Web Services® (AWS), Google Cloud Platform®, Microsoft Azure®, or another cloud provider. This inherently creates significant problems for system administrators and DevOps engineers. They are faced with the decision of choosing to accept a significant security risk or undertaking dramatically more work. Alternatively, they can opt to spend significant money to purchase and manage a secondary enterprise identity management solution.

We’re here to offer a new way forward. The modern cloud ops approach extends Active Directory to AWS, while maintaining AD as the authoritative source of truth.

Exploring Traditional Solutions to a Complex Problem

Let’s start by taking a look at some of the less than perfect solutions that have traditionally been available to sysadmins and DevOps engineers:

• Manually managing cloud server accounts – Many admins choose perhaps the simplest way out of this predicament – manually create, manage, and delete users on their cloud servers. DevOps engineers will somehow be notified of who requires what access to the cloud servers, and will manually provision and manage those users on their cloud servers or now their container orchestration systems. This entails logging into the servers themselves and managing the user creation, modification, or termination process. The IT admins and DevOps engineers are in the middle of sending passwords or managing SSH keys between the server and the end user. As the number of servers and users grows, this presents some significant challenges around tracking access, not to mention inefficiency. In addition, adding capabilities like multi-factor authentication – a critical requirement for identity security – becomes problematic as those solutions often require a central directory or user store. Finally, many sysadmins in AWS simply leverage a single ec2-user account for access, thereby losing individual user access and any on-host auditing capability in the process.
• Network AWS cloud server to the on-prem AD instance – Another option often considered by sysadmins is to connect cloud servers back to the on-prem Active Directory instance via VPNs and networking. Because of the Active Directory security model, exposing the directory service to the Internet is not an option. Cloud servers, while being a hop or two away from the open Internet, are often behind firewalls and other intrusion detection equipment. The result is that it takes some networking gymnastics to connect cloud infrastructure back to the Active Directory server, which is usually located at the core of the on-prem network, also behind firewalls and other security equipment.
• Stand-up a cloud Active Directory instance – For some organizations, another option is to create another directory service instance in the cloud. This works well if the cloud setup is logically in a “VLAN” or equivalent enclave, where the directory server can talk to each of the servers. Remember that with Active Directory, IT resources must have a direct path to the identity provider to authenticate. For this setup, DevOps engineers and IT admins can take one of two approaches – connect the cloud Active Directory instance back to the on-prem AD server, or create separate identities in the cloud. Either way, this approach creates an extra layer of work in order to manage cloud servers. Some IT admins consider Azure Active Directory or AWS Managed AD. Unfortunately, Azure AD works in conjunction with AD, but only for Microsoft’s own cloud service Azure. AWS’s Directory Service offering is effectively AD without the server management. Of course, DevOps engineers will struggle with connecting non-Windows solutions to these Microsoft-focused platforms.
• Implement an on-prem directory extension – A whole category of directory extensions emerged shortly after Active Directory was introduced. These legacy solutions integrate with the on-prem AD server and extend AD identities to non-Windows IT resources. Because of the criticality of the infrastructure they manage, these solutions are often referred to as Privileged Access Management or PAM solutions. Part of the pitch with these solutions is that they enable you to connect remote IT resources back to Active Directory. The good news is that these solutions help with support for Linux servers. The bad news is that they still end up forcing IT admins to contend with the networking and security issues.

Unfortunately, Azure AD works in conjunction with AD, but only for Microsoft’s own cloud service Azure.

Common Problems with Traditional Solutions

As more organizations shift to cloud infrastructure hosted at providers such as AWS, it is critical to understand the core problems with connecting identities and access to these off-prem, cloud resources. Some of the main focal points are:

• One directory service of record – It is critical for organizations to have only one source of truth for users on the network. As you can imagine, multiple directories can easily cause conflicts and issues. The problems can be catastrophic. Imagine a disgruntled terminated employee still having access to a number of critical servers because there wasn’t an in-sync directory of users for server access. On the more mundane side, multiple directories create an additional layer of day-to-day work and complexity. As the organization grows, the complexity will increase. Multiple, disparate directories is never a good idea.
• Network configuration/security exposure – For many companies, the move to the cloud is an acknowledgement that networking and network related configuration isn’t an effective use of their time. Unfortunately, exposing your directory store to the Internet, networking cloud servers to the on-prem AD server, or standing up an additional directory store in the cloud each come with their network configuration and security requirements. You’ll need to be careful to walk through the right network-level access control to make sure that all of your machines can talk to each other properly – and over the right ports and protocols, securely. While not impossible, it is an added task, and one that most organizations moving to the cloud would rather not have.
• Reliability – A number of these solutions can have reliability issues. Manually managing user access is subject to human error. Did every person get the access that they needed, or did some users get too much access? Keeping track of this can require many hours of attention. In addition, creating the additional directory servers in the cloud starts a whole new chain of work. Directory servers need to be highly available and downtime can mean your users can’t do their work. Exposing your directory server to the Internet can invite DoS attacks or cause you to be subject to Internet connectivity issues between your cloud servers and your directory store. You’ll need to address those issues either through load balancing or increased capacity.
• Cost – Every one of these options can be expensive for organizations. While some may be expensive from a monetary standpoint, others may be expensive from a time and resources perspective. Either way, managing users across your organization, whether the access is needed on-premises or for your cloud servers, is often not a core competency. It needs to be done well and securely, but the costs of having resources focus on this task versus core tasks can be a significant opportunity cost.

A Modern Ops Approach

As IT and DevOps organizations aggressively leverage AWS and other IaaS infrastructure, the previous approaches all have too many drawbacks to be viable solutions. Innovative organizations are smartly and securely extending their on-prem Active Directory identities to their IaaS platforms through integration with a cloud directory service.

In this scenario, the on-prem Active Directory instance continues to serve as the directory service of record, with all identities stored within AD and updated there. From this core, authoritative identity provider, the integration platform is leveraged to federate identities to a cloud hosted directory service. Subsequently, this cloud identity provider controls user access to the cloud infrastructure. That infrastructure may be at one or a number of different IaaS providers. Additionally, this cloud identity bridge can also control access to other non-Windows and non-AD-bound IT resources, including Mac and Linux systems, web applications, WiFi access, and cloud storage systems.

A diagram of JumpCloud’s AD Integration Import is below:

The implementation and management process of a cloud identity bridge is quite simple. The first step is to install JumpCloud AD Import agent onto the on-prem domain controllers and the cloud servers. Those agents securely communicate with the cloud hosted directory service. All changes within AD are automatically replicated to the SaaS-based user management service as well as the cloud server infrastructure. No management and maintenance work is needed. IT admins and DevOps engineers simply assign what users should have access to – and JumpCloud’s Active Directory Integration does the rest. Access can occur via username and password or SSH keys. Both access methods can also be secured with 2FA (two-factor authentication).

A cloud identity bridge means that no VPNs are necessary between your cloud servers and your on-prem AD instance.

Benefits of Cloud Directory Integration

There are a number of benefits to this cloud identity extension model relative to the other options and approaches that IT and DevOps organizations often take.

• No network configuration required – Agents installed on each server talk back securely to the cloud-based, SaaS directory service. The agent keeps all users in sync without opening firewall ports or exposing your core directory to the Internet. That means no VPNs are necessary between your cloud servers and your on-prem AD instance.
• Increased security – Not only do you not have to expose your central directory to the Internet, all of your users are in sync all of the time and user access to your server infrastructure is tightly controlled. The number one risk for any organization is from compromised user accounts and keeping only the right users on every machine is critical.
• Little to no additional administration – Because your users are kept automatically in sync and your group membership is replicated to your cloud infrastructure, there is very little additional work to be done by system administrators. They create the accounts and give them the right privileges once and centrally. From there, the system does the work of securely replicating that information and creating the right access.
• Cost – A cloud directory service is far more cost-effective to implement and run. Organizations only need to pay for what they use and there is no hardware or software to purchase. Maintenance and management is the responsibility of the AD integration provider and not of the client organization.

Innovative organizations are leveraging this cloud identity bridge approach to enable their shift to the cloud. Identity management is a key part of any IT infrastructure and when thinking about leveraging cloud infrastructure such as AWS, IAM concerns abound. By leveraging JumpCloud’s Active Directory Integration, IT organizations can easily and safely unlock the cloud.