Why Cloud Server User Management has been a Challenge
Organizations have traditionally leveraged Microsoft Active Directory (AD) or OpenLDAP to manage access to their on-prem or colocated server infrastructure. LDAP and AD have historically been the source of truth when it comes to who has access to what on an organization’s infrastructure.
Servers such as file and print servers would be located on-premises within a server closet, and if the organization was large enough, their server farm for applications and data would be within their own data center or a colocation facility. It was generally straightforward to make those directories talk to their servers since everything was “local” or within the domain through VPNs and MPLS infrastructure.
Over the last decade, though, cloud infrastructure or Infrastructure-as-a-Service has gained tremendous popularity. The 2018 State of the Cloud survey discovered the following from their participants:
- 96%: leverage the cloud in some way
- 79%: of their workloads run in the cloud
- 21%: of their workloads run on-prem
Exploring Traditional Solutions to a Complex Problem
Manually managing cloud server accounts
Many sysadmins and DevOps engineers choose perhaps the simplest way out of this predicament – manually create, manage, and delete users on their cloud servers. Sysadmins will somehow be notified of who requires what access to the cloud servers, and they will manually provision and manage those users on the cloud servers.
This entails logging into the servers themselves and managing the user creation, modification, or termination process. As the number of servers and users grow, this presents some significant challenges around tracking access.
Also, adding security features such as multi-factor authentication becomes problematic to enforce at scale without a central directory or user store. Finally, many sysadmins in AWS simply leverage a single ec2-user account for access largely because it’s easier, but losing any on-host auditing capability in the process.
Expose LDAP or AD to the Internet
Another option often considered by sysadmins is to expose LDAP or AD to the Internet and let the servers talk directly to the directory service. Note that this requires that the cloud servers have Internet access and the ability to talk to the user directory.
Through additional security and configuration, the LDAP or AD servers can be locked to only talk to certain servers or through VPNs. Depending upon the network architecture and growth of servers this may or may not be an option. If it isn’t, then the user directory store is available to be queried by anybody on the Internet.
Stand up an entirely new LDAP or AD instance in the Cloud
For some organizations, a viable option is to create another directory store. Generally this involves standing up a new instance of Active Directory or OpenLDAP 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.
Additionally, the cloud directory will either need to be synchronized with the main directory service or will need to be manually updated. This creates an extra layer of work for sysadmins but does give them the ability to manage users for their cloud servers via either OpenLDAP or Active Directory.
While one of the methods mentioned above may be the quick fix that you need for cloud server user management, none of them will enable you to remain agile and competitive in the long term.
Common Problems with Traditional Solutions
Decentralized Identities
It is critical for organizations to have only one source of truth for users on the network. As you can imagine, multiple directories or manual management can easily cause conflicts and issues. The manifestations of problems in this category can be catastrophic such as a terminated employee still having access to a number of critical servers because there wasn’t an in-sync directory of users.
The less catastrophic and more mundane consequences of multiple directories is a layer of additional work and complexity. As the organization grows, the complexity will increase. Multiple, disparate directory services is never a good idea.
Network configuration/security exposure
The move to the cloud for many companies is an acknowledgement that networking and network related configuration isn’t an effective use of their time. Unfortunately, exposing your directory service to the Internet or standing up an additional directory service in the cloud each come with their network configuration requirements.
You’ll need to be careful to walk through the right access controls to make sure that all of your machines can talk to each other properly – and, over the right ports and protocols. While not impossible, it is an added task and one that most organizations moving to the cloud would rather not have.
Reliability Concerns
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 they get too much access? Creating additional directory servers in the cloud starts a whole additional chain of work.
Directory services need to be highly available and downtime can mean your users can’t do their work. Exposing your directory service to the Internet can invite DoS attacks or cause you to be subject to Internet connectivity issues between your cloud servers and your identity provider. You’ll need to address those issues either through load balancing or increased capacity.
High Costs
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 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 expensive.
Two Modern Solutions for Cloud Server User Management
Solution 1: An On-prem Directory Service with an Identity Bridge
One option to solve this problem is to fix a central directory service with either OpenLDAP or Active Directory internally. This directory service becomes the identity provider of record.
From this central directory store, organizations create a secure identity bridge to their cloud server infrastructure. That infrastructure may be at one or a number of different IaaS players.
Solution 2: Cloud Directory Service
The other option is to centralize the entire identity management infrastructure with a cloud directory service. This modern cloud directory will connect user identities to cloud servers, on-prem systems, web applications, file servers, networks, and more.
There is no requirement for VPNs, networking, operational management, and the other heavy lifting of managing your own directory service. In fact, sysadmins and DevOps engineers outsource the work and infrastructure of a directory service, yet they get the benefit of centralized access control, especially over their cloud servers.
A Closer Look at the Benefits of a Modern Approach
Smart organizations will leverage a SaaS-based cloud directory service because there are numerous benefits to this modern approach.
No Network Configuration Required
Agents installed on each server talk back securely to the cloud-based, SaaS directory service.
Increasing Security
You don’t have to expose your central directory to the Internet, and user access to your server infrastructure is tightly controlled. Because 81% of data breaches have been the result of weak or stolen passwords*, the number one risk for any organization is compromised user accounts. Knowing for certain who has access to what is crucial in fighting this attack vector.
* 2017 Verizon Data Breach Investigation Report
Little to No Additional Administration
IT admins and DevOps engineers simply load their users into the cloud identity provider and provision the appropriate access without having to deal with infrastructure and management.
Looking For More Information?
Consider reading one of the case studies above and see how JumpCloud has enabled many organizations to achieve centralized user management across all IT resources. The Tamr Case Study in particular is a great example of an organization using JumpCloud to centralize user access to 300 remote servers, G Suite, LDAP, SAML apps, WiFi, and systems. Additionally, you can find more information on our blog, YouTube Channel, and Knowledge Base, or you’re more than welcome to drop us a note.