How To Connect Microsoft Active Directory To Google Compute Engine

By Greg Keller Posted December 9, 2014

Connect

Most organizations use Microsoft Active Directory as their core user directory service and many of them leverage Google Compute Engine for their server infrastructure. But organizations using this technology combination are faced with a particular challenge: How do you leverage GCE, but also have the users managed by AD?

The problem is rooted in the fact that IT admins are loathe to expose AD to the Internet for security reasons. As a result, each GCE instance must be networked to connect to AD. This, almost always, adds significant overhead to already busy sys admins. Even if you can connect the cloud servers and AD, there’s still the issue of operating system compatibility. Many cloud servers are Linux and, therefore, connecting AD to them is difficult. Connecting an existing AD server to your cloud infrastructure is often the desired goal, but often not easy.

The good news is, a new generation of technology has emerged to help businesses solve this issue.

Directory-as-a-Service®, or DaaS, is the answer. A cloud directory services solution is a cloud bridge that connects your on-premise AD to GCE cloud servers (also see our article on bridging AD to AWS). The hosted directory services solution replicates existing AD out in the cloud. Users that need access to GCE are mirrored into the DaaS solution. So, for instance, if a user is terminated from the organization, that person’s access is fully terminated immediately from any GCE servers. The converse is also true where a new user can be easily and quickly provisioned to all of the servers that person needs.

In this way, IT admins are able to get what they want and need—complete control over GCE user management from one central location.

So, How Do You Connect Active Directory to Google Compute Engine?

Bridging AD to GCE via a Directory-as-a-Service solution is quite simple.

First, a small agent is placed on the AD server. The purpose of this agent is to securely connect AD to the cloud-based directory. Any users specified by the IT admin are replicated to the DaaS solution via this agent. Further, any changes to those users are also automatically mirrored in the DaaS solution.

From there, the SaaS directory services solution controls users on cloud servers. There are two ways that this can occur. First, if organizations want to leverage LDAP as the protocol, DaaS can serve as an virtual LDAP server for those cloud servers. Second, if an organization would like greater control over the devices, a small agent can be placed on each server. This agent also talks back to the cloud-based directory service and securely creates user access, terminates it, or changes it as desired. As a result, IT admins maintain full control over user management of GCE servers, but effectively through their AD instance.

One of the issues with Infrastructure-as-a-Service solutions at large, has been the fact that they exist outside of normal IT operations. With Directory-as-a-Service, access control over GCE can now be controlled via AD —or many organizations, their core user directory store.

If you would like to learn more about how Directory-as-a-Service can help you with your Google Compute Engine infrastructure, drop us a note.

Greg Keller

Greg is JumpCloud's Chief Product Officer, overseeing the product management team, product vision and go-to-market execution for the company's Directory-as-a-Service offering. The SaaS-based platform re-imagines Active Directory and LDAP for the cloud era, securely connecting and managing employees, their devices and IT applications.

Recent Posts