By Greg Keller Posted January 3, 2017
With the move to cloud infrastructure, there is a challenge that IT admins and sysadmins are facing. How do users leverage their core identities to connect to their cloud servers? As infrastructure has shifted, the identity has not.
The problem becomes whether you can authenticate cloud servers against Active Directory. Unfortunately, this is a significant problem without an easy answer when you leverage Microsoft Active Directory.
When Active Directory Could Do It All
AD was created in a different era of IT infrastructure. The world was virtually all Microsoft Windows and hosted on-prem. Users would log into their devices and through the domain controller be connected to whatever internal IT resources they were authorized to access. This often included their on-prem servers. Those were usually hosted in their local data center or connected to a remote facility via a VPN. This era may have been closer to True Single Sign-On™ than when many web application SSO providers entered the market.
Decentralized IT in the Cloud
The IT landscape dramatically shifted with the advent of AWS. While not the first Infrastructure-as-a-Service provider, AWS brought the concept of cloud servers to the masses. With over one million customers today and growing, IT organizations have shifted their approach to the data center.
A variety of management challenges have come with that shift. Most IT management solutions were for on-prem systems. As the cloud has emerged, so, too have management tools. Among others, those management tools include Automox cloud server patching solutions and VictorOps monitoring tools. However, when it comes to controlling user access to cloud servers, most IT organizations were struggling with how to connect those cloud servers back to an on-prem AD server.
Mismatch Between Cloud Server Authentication and Active Directory
The challenge to authenticate cloud servers against Active Directory is twofold.
First, all of those cloud servers need to be directly connected to AD. So this means that you need to have a VPN connection from your cloud infrastructure back to your on-prem systems.
Next, you need to ensure that your AD server isn’t exposed to the Internet because of all of these networking adjustments. Other approaches to authenticating users to those servers could be to put an additional AD instance in the cloud, leverage OpenLDAP, or just manually manage the users via scripting solutions such as Chef / Puppet or individual commands.
None of these approaches really solves the problem for IT admins and sysadmins. Ideally, their cloud server infrastructure would seamlessly integrate with their identity management platform. It shouldn’t matter what provider (AWS, Google Cloud, Azure, etc.) or what platform (Windows or Linux), but users should be able to be centrally controlled.
There is a solution to this problem that doesn’t involve the hoops and hurdles of Active Directory.
Try JumpCloud® on for Size
Directory-as-a-Service® is a cloud-hosted directory service that integrates with cloud servers and leverages a single identity for each user. In addition to connecting users to their servers, this IDaaS platform connects users to their on-prem systems (Windows, Mac, and Linux laptops & desktops), cloud and on-prem applications, and WiFi networks. Think of it is as returning to the days of True Single Sign-On from the past.
If you would like to learn more about how to authenticate cloud servers against Active Directory, or how to leverage a modern Identity-as-a-Service platform instead, drop us a note. Also, please sign up for a free account of our cloud server user management platform. Your first 10 users are free forever.