Three Reasons For A Cloud-Based Directory

By Rajat Bhargava Posted January 20, 2015

Cloud-Based Directory Service

Apple. AWS. Google. They won’t be your directory in the cloud, but they are driving massive transformations in the IT industry that will catalyze the need for a cloud-based directory.

These companies are the face of three major trends:

  1. The move to non-Windows devices in the case of Apple.
  2. The commoditization and adoption of cloud infrastructure.
  3. Google’s enterprise G Suite (formerly known as Google Apps) services, which are pulling the rug out from under Microsoft Exchange.

Before diving into the reasons for these changes, it’s important to understand where organizations are coming from. Over the past two decades, directories such as Microsoft Active Directory® and OpenLDAP™ have been cornerstones of any corporate IT infrastructure. Outside of the physical network, the directory arguably became the most critical system in the organization. Without a properly functioning and maintained directory, IT had trouble providing employees access to the IT resources they needed, and it became a critical security choke point where access was granted and denied. Not to mention it became a frustration point for the employee.

In the pre-cloud days, organizations were largely homogeneous with Microsoft systems – desktops, laptops, and servers among print and file servers. Microsoft did a nice job of providing management tools to admins to reasonably manage their fleet of Microsoft systems, but didn’t have complementary systems for Mac computers or Linux systems. AD had built in policy management capabilities (called Group Policy Objects), along with the ability to script virtually any task that an admin wanted to execute on Windows-based systems. Further, an organization’s IT applications were largely Microsoft based and would authenticate against Active Directory. For organizations that needed Linux or UNIX systems, companies tended to create another directory structure leveraging LDAP which *nix systems seemed to more readily support. Active Directory was generally paired with Exchange. As a result, if organizations wanted to manage email systems, they automatically signed themselves up for AD.

Historically, AD and OpenLDAP lived on-premises with admins managing them on an on-going basis. But in the mid-2000s there were two fundamental shifts. First, Apple’s resurgence spurred a reinvention of Macs in the work space, including desktops, laptops and software. The second shift was when hosting servers and applications in the cloud became more commonplace. While trickle down effects have taken a few years to reach the directory, the cloud-based directory is now here.

Three Core Reasons for a Cloud-Based Directory

Leaders mentioned at the beginning of this piece (Apple, AWS, and Google) are pushing the trends with Mac and cloud-based solutions to the forefront of all IT organizations, resulting in three core reasons behind why the directory will be moved into the cloud.

1. Heterogeneity (Apple)

Apple

Microsoft is losing its grip over the operating system for desktops, laptops, and servers. They have most certainly lost it for mobile and tablets with Android and iOS owning the majority of the market share. But, as we know, most organizations still have the bulk of their productivity devices in the form of desktops and laptops, and Microsoft’s footprint is narrowing. More and more companies born in the last decade are choosing to use Apple Macs. This is driven by employee demand for easier user experience and better-designed form factor.

The few organizations that still rely on Microsoft PCs are often driven by Windows-only software requirements. However, even these organizations are seeing a greater number of Mac devices showing up in their network. In some organizations, the movement to bring your own device (BYOD) is opening the floodgates to a myriad of device types and operating systems used from literally anywhere in the world. IT admins struggle to bring these devices into the fold as traditional directories weren’t built to authenticate and manage different device types of machines that are often not on-premises. As such, Macs end up becoming largely unmanaged devices. This introduces a significant security risk to the organization as well as overhead to IT admins.

For those IT admins that would like to manage Macs, there are a few critical items to consider. Authenticating the user on a Mac is possible but painful and often requires additional software solutions. Macs, like Windows machines, need to be configured to communicate with the directory. It’s cumbersome to implement for Macs given the vast difference in OS. It’s possible to script it, but that does require access to the device. Among other items that can be accomplished with AD and Macs, is the ability to define home directories on Windows file shares and leveraging AD groups with the Mac. Unfortunately, that’s about all you can do when connecting Macs to the existing directory.

Unlike Windows devices where there are hundreds, if not thousands, of group policy object (GPO) settings that can be managed through Active Directory, Macs have none. If Macs need to be managed, and the IT admin is thinking that AD can do it, they’re out of luck. Because Mac users are generally administrators on their devices, even if they connect to the domain, the user can easily disable the connection to it. Effectively, local users can do whatever they want to on their personal device, circumventing any controls that IT has implemented.

Cloud-based directories solve this issue because they are built with current trends in mind. One of the strongest aspects of cloud-based directories is that they can natively support the top operating systems, without need to favor one operating system over another. Further, the fact that a user/device pair may not be within the four walls of the organization doesn’t matter. The directory service is in the cloud and can reach all corners of the globe. Macs are clearly a critical part of the IT landscape and a modern directory needs to support the most common devices that employees are using. That support needs to include not only authentication, but management and full control over the device

2. Cloud Infrastructure (AWS)

One of the great innovations of the last decade was the introduction of Infrastructure-as-a-Service (IaaS). The development meant organizations no longer needed to invest money into purchasing their own data centers or spending the time installing, configuring, and maintaining those centers. IaaS enabled the rental of compute and storage resources, and it was a game changer for organizations of all sizes. The challenge, of course, was that the core infrastructure that used to be “in house” had now moved to being outsourced. As a result, the on-premise control of user access via the directory has been eliminated, or, at a minimum, dramatically changed.

AWS was an early entrant to the IaaS fray. Today, there are hundreds of companies providing these cloud hosting capabilities. In the modern cloud infrastructure era, there are very few reasons for companies to create their own data centers or host their own servers. It is easier to just purchase this as a commodity. But it’s important for organizations to consider the way they manage their new cloud-based infrastructures. This is especially true from a user management perspective. Currently, there are a few methods that organizations leverage to try to tackle the problem of managing users provisioned to cloud infrastructure:

  • Manual management or via scriptsarguably the most utilized method of managing users on cloud servers, the manual or scripted method is the least complex, but, obviously, the most work. Every change must be manually inserted into either a Chef/Puppet script, or executed on the server directly. Most admins opt for this method because it’s the least costly option. Of course, this method is prone to human error as it’s difficult to manage complex access, and there is no audit record of who did what.
  • Expose AD/LDAP to the Internet – another option that admins contemplate, but rarely use, is to expose AD or LDAP to the Internet. By enabling cloud servers to directly talk to their user store, they can make changes in one place and have them propagate to all of their devices. Of course, the risk here is that the AD or LDAP server could be compromised. AD and LDAP aren’t inherently secure—they are designed to be placed inside of a network with multiple layers of security around them. This is a high risk venture with limited upside.
  • Set up a point-to-point VPN tunnel – a variant of the previous option is to connect your cloud servers and user store together via a secure VPN. This is much more secure and likely a far better option. The downsides of this option are that it’s intensive to setup and manage. Further, as you add more cloud providers to the mix for redundancy, each of them will need a VPN set up to the AD or LDAP user directory. While a much stronger option than the two previous options, this shifts the pain to be network and configuration focused.
  • Replicate AD / LDAP in the cloud – another option that some organizations take is to spin up another instance of AD or LDAP at their cloud provider. With AD, a secondary domain controller or domain trust is often established. With LDAP, it’s often raw LDIF database replication. This option increases server cost, management overhead, and means more things can go wrong.
  • Purchase enterprise software to bridge – over the years, large enterprises have purchased solutions to “bridge” their AD or LDAP server to other data centers or remote offices. This same technology can be used to connect cloud servers to the AD/LDAP user store. These tools end up being enterprise-class tools, meaning that they take significant time and effort to install, are expensive, and are difficult to use. This path is effectively leveraging a legacy solution and model to solve a modern problem.
  • A cloud-based directory that can span multiple networks is the ideal choice to control and manage cloud-based infrastructure along with a company’s on-premise devices. JumpCloud® was built to solve this issue and also match the quick, agile approach of Infrastructure-as-a-Service. A cloud-based directory service can easily extend the key users of IaaS to those cloud servers without the expensive, manual effort or the security risks described earlier.

3. Bifurcation of AD/Exchange (Google)

Google

What started as a free consumer email service in 2004 quickly became a way for organizations to outsource their entire corporate email needs. G Suite (formerly known as Google Apps for Work) has literally ripped the email infrastructure out of companies and easily placed it in the cloud with their enterprise Gmail services. Prior to the advent of corporate G Suite, organizations relied on Microsoft Exchange. The hardware and software would be generally hosted on-premises and managed by the IT team. Of course, in order to use Exchange, Active Directory was required as well. This duo was the gold standard at organizations large and small for the better part of the last decade.

As G Suite (formerly known as Google Apps) was introduced, organizations realized that they didn’t need to manage their own email. Effectively, email became a cloud service. Since most organizations also had AD, they often left that in place to continue to manage users, Windows devices, and printers. Over time, Google created a syncing method between G Suite and the on-premises AD. IT admins began to question why they needed to have email in the cloud and the directory on-premises. Unfortunately, there was no option to move their directory to the cloud, and Google Cloud Directory (GCD) – formerly known as Google Apps Directory (GAD) – did not function as an AD equivalent. GCD is effectively a contact database. Google ended up creating “syncing mechanisms” to connect on-premise directories such as AD or LDAP with G Suite. These were called Google Cloud Directory Sync (GCDS) and G Suite Password Sync (GSPS).

Both of these agents ran on Active Directory and helped ensure that the AD user store was replicated with Google’s user store. The problem was that admins were left with an on-premise server that they’d rather have in the cloud. Microsoft realized that Google had been stealing their email customers. So they stepped into the game with Office 365 and Windows Azure Active Directory (WAAD) services. The idea was to extend the on-premises Active Directory to Azure. This would enable single sign-on for cloud applications as well as provide Azure cloud servers integration. This was clearly a move by Microsoft to lean into the cloud era. It was also an attempt to reduce further account loss to Google’s email and apps solutions. However, users cannot leverage WAAD without an on-premise AD system. That, of course, completely misses the point of moving both email and the directory to the cloud.

As more organizations leverage cloud-based email, an equivalent cloud-based directory will be required. GCD and WAAD are, unfortunately for users, not the option for a cloud-based directory. Both solutions end up forcing admins to keep their on-premise directories. A true cloud-based directory will allow organizations to move their email and directory to the cloud.

Learn More About Cloud-Based Directory Services

jumpcoud Directory-as-a-Service

These critical trends and companies are driving a new vision for IT. A vision that is heterogeneous and cloud-based. As core network infrastructures move to the cloud, so too must directory services, and the shift couldn’t have come at a better time. Organizations are conscious of their digital security and want complete control over who has access to what resources. IT organizations will need to control and manage user access, their devices, IT applications, and networks they utilize. On top of this, they need to do it despite the globalization and scattering of employees.

A modern, cloud-based directory is at the core of safely and effectively leveraging these critical trends. Directory-as-a-Service® solutions service all types of users, devices and IT applications. DaaS authenticates, authorizes, and manages those resources for IT admins from one central web-based console providing simplicity and security. If you would like to learn more about the innovative cloud-based directory Directory-as-a-Service, drop us a note. We would be happy to talk about whether our Directory Services are right for you. Alternatively, feel free to sign up and try out DaaS for yourself. Your first 10 users are free forever. 

Rajat Bhargava

Rajat Bhargava is co-founder and CEO of JumpCloud, the first Directory-as-a-Service (DaaS). JumpCloud securely connects and manages employees, their devices and IT applications. An MIT graduate with two decades of experience in industries including cloud, security, networking and IT, Rajat is an eight-time entrepreneur with five exits including two IPOs, three trade sales and three companies still private.

Recent Posts