By Greg Keller Posted October 15, 2015
Sysadmins spend so much time on the same set of tasks: the creation, provisioning, management and de-provisioning of user accounts across server infrastructure.
These process are already labor intensive and prone to mistakes when everything is on one operating system. But today’s sysadmins are being asked to provision a user account across infrastructure (on-prem and cloud) as well as across operating systems (PC, Mac, and Linux). This multiplies the complexity of the problem across potentially hundreds of servers.
The problems often revolve around the various identity stores required to get the job done. These include Active Directory for Windows hosts and LDAP with PAM for Linux servers, as well as disparate mechanisms requiring an elaborate array of expertise in each domain to get it done right.
Windows Azure, like other popular Infrastructure-as-a-Service (IaaS) providers makes it incredibly easy to spin up servers in seconds. Yet tethering these virtual servers to pre-existing identity management solutions (again, AD or LDAP) is a complicated affair. In the case of Windows servers on Azure, they require on-prem Windows Server Domain Controllers, configured and networked to connect to connected to Azure AD infrastructure. Similarly, Linux servers need to be networked and connected to self-managed LDAP servers. The problem is not unique to Azure and similar issues exist to efficiently tether virtual instances to core identity management solutions (e.g. directories).
In this article we will show how JumpCloud’s Directory-as-a-Service can be utilized to simplify and control user access to cross-platform servers on the Microsoft Azure cloud service, demonstrating user account provisioning and access to Windows and Linux servers.
Setting up Servers in Azure
We’ll defer to Azure’s ample documentation on spinning up servers within the Azure hosting platform. For this walk through, two servers have already been created and are active on the Azure platform:
The process is extremely simple. It’s similar to the process found in other IaaS admin products such as Amazon Web Services or Google Compute Engine. In this case, a Windows 2012 R2 server and Linux Ubuntu server were created. With the infrastructure built, the only available option for implementing user accounts was to directly SSH and/or RDP into each respective instance and utilize the OSs native user management processes to build accounts. The Azure Active Directory user store does not directly enable the servers to be authenticated by this list of users. The Azure AD store is primarily leveraged for application authentication. It isn’t really designed for server user management in its current form. Therefore, server user management requires an elaborate creation of traditional Active Directory Domain Controllers managed on-prem (or virtually) and sophisticated networking connectivity between the servers and domain controllers.
JumpCloud’s Role in Managing Azure Server Users
First, if you do not have a JumpCloud account, please sign up here to evaluate a fully functional version of JumpCloud’s Directory-as-a-Service which is free for 10 users. It will provide you ample visibility into the product’s functionality.
To simplify the chore of user management across your infrastructure, JumpCloud can be utilized to simultaneously manage a singular user account and emit and control the account to various services the user requires access to, such as these Azure-hosted servers, their personal workstations, or wifi networks and more. With the Azure servers created and active as indicated above, we’ll discuss the following:
- Establishing connection to the Azure servers
- Creating users in the JumpCloud Directory
- Provisioning these users to the independent Azures servers
Establishing connection to the Azure Servers
This process is accomplished by the installation of JumpCloud’s system agent. The JumpCloud agent is responsible for:
- Receiving instructions for user account creation/modification/disabling
- Receiving instructions for executing commands and scripts which need to be run across the servers
- Providing event logging for the system
Complete documentation on getting started with systems (and the agent) can be found here.
a. RDP into the Windows instance on Azure using the Administrative account used when the server was established.
b. While on the Windows system, log into the JumpCloud Admin Console and proceed to the Systems tab and ‘Add System’
c. Select the Windows tab of this UI and download the Agent installer. You will be required to utilize the unique key on this UI during the install process:
a. SSH into the Linux instance on Azure as root
b. Log into the JumpCloud Admin Console and proceed to the Systems tab and ‘Add System’
c. Select the Linux tab of the UI and copy the curl script
d. Return to your SSH session shell and paste this curl script in and execute to trigger the agent download and installation:
With the agent installed, the JumpCloud UI will report back status in its System UI:
Note: The agent, once installed on the host, requires only an outbound port 443 connection back to JumpCloud for communication needs.
Deploying Users to the Azure Servers
The process of creating users within the JumpCloud Directory is simple, and is fully documented in our Knowledge Base. A user for this tutorial has already been created and activated (via implementing a password). This user is “BillyChristianson”(username: billyc):
With the active user ready, the user must then be bound to the Azure servers. This process is done via “Tags” (now Groups) within JumpCloud. A step-by-step walk through on Tags is found here, but the process is extremely simple.
- Create a Tag or Edit an existing Tag. For this tutorial, we’ve created a Tag called “Developers – Azure” to assign users with the two Azure servers we set up above:
- Select the Azure servers on the left, and the user (billyc in this case) on the right and Save:
Once ‘Save’ is performed, JumpCloud will instruct the agent to build the local user account along with locally caching and encrypting the user’s credentials.
On the Windows Server we can see the local account created here after the Tag was saved above:
Running net user [username] in PowerShell results in further details about Billy:
For the Linux Server, the process is similar using the finger command:
In each circumstance, JumpCloud will utilize the native processes to build local user accounts on the system. This applies to Windows, Linux and Mac OS X.
Similarly, shutting down user account access to the Azure Server can be done extremely quickly. Simply uncheck the user (or a specific system) the user is currently bound to and Save. This will result in an account de-activation to deny access to the system. In the case of the Azure Windows Server, it was simply unselected from the Tag, the Tag saved, resulting in user billyc being de-activated immediately:
User account management on remote servers, as you can see, is simple with JumpCloud. It enables to you manage user access across any cloud, and across multiple OSs. Directory-as-a-Service will enable these same identities to be centralized and bound to many other IT resources as well…from LDAP-backed applications, employees personal workstations to office WAPs.
We invite you to try JumpCloud to manage your Azure server user accounts today. Visit JumpCloud today to signup and evaluate the product in its entirety.