Demystifying the art of Active Directory Multitenancy

Demystifying the art of Active Directory Multitenancy

A quick google search of Active Directory Multitenancy could leave you more confused rather than informed, so this blog aims to provide some guidance as to how and where it makes sense.  I will also try to clear up some of those misconceptions that you might find in your search results.

So first let’s define what Active Directory Multitenancy is, much like any other Multitenancy its essentially many customers sharing one Active Directory (AD), think of it like the following diagram:

Now, why do want to do this?  The answer here is we need to take what could be a complex setup and we want to commoditize it so many customers can benefit from the service or application. 

The aim of the game is to:

1. Invest the time up front building out our infrastructure.
2. Implement a means for customers to onboard quickly with minimal configuration effort.

By doing this the cost of the shared infrastructure largely remains static, as we add each new customer our profit margins go up and things start to make good business sense.

The most common scenario and where Active Directory Multitenancy really took off was with Hosted Exchange.  If we roll back to the days before Office 365 and think of email, your choice was fairly limited, you either had a bunch of POP3 mailboxes provided by your ISP or you built your own Exchange server.  If you were a small business and you wanted those cool features like Out of Office auto replies, you had hefty cost to justify in building your own Exchange server.  A Hosted Exchange provider, however, could offer all of those benefits at a few dollars per user per month by letting customers share a single deployment of Exchange. For a customer, the economics of the decision was simple.

So, whilst Hosted Exchange probably isn’t where you would start your Cloud hosting business today, there are many other ERP, Accounting, and Line of Business applications out there that customers have built their businesses around.  Many of these applications have had years of development and empower companies to work efficiently, but unfortunately, like Exchange Server, it was up to a business to build and run its own infrastructure needed to get the job done.

Here is where the opportunity exists, if you’re an application developer that is reliant on AD or you run a consulting business built around supporting an application that is dependent on AD, you have an opportunity to take that application and make it a Cloud-delivered service.  You build the environment once, which means you only have one environment to maintain.  Then by allowing each new customer to share the AD and resources, you can build a business model where a company with just one user can still be a valued customer.

As I mentioned in the beginning, there are some misconceptions that you might find on your quest for enlightenment, I found 4 common ones across the various Blogs and Forums I looked at and I will cover theses below;

Misconception 1:    Stop looking at Active Directory Multitenancy, what you really need is a Cloud Identity Tool!

Cloud Identity tools are cool, they let your users have a single logon that can be used for various Cloud services, however, if the application or service you plan to deliver still relies on AD, then this isn’t your silver bullet.  You’ll still have to build AD either multi-tenant or single-tenant for that application.

Misconception 2:    In this modern world of Cloud, spinning up a VM for an AD server is child’s play, that’s what you should do for every customer.

Now, this is a valid statement, Cloud has certainly made getting a VM up and running much quicker.  If you’re clever with scripting you might even be able to automate the build and setup of that AD server, where this generally falls over is in the cost model.  By limiting ourselves to dedicated AD’s per customer, we also limit our Application, Desktop and Database servers to just that customer. If we come back to our commoditized consumption model where we want all customers to share the costs, this simply doesn’t work.  To be dedicated the service price for that one customer has to be high enough to cover all of the cost and maintenance of that dedicated infrastructure, this is where you’ll often see minimum user quantities for a service.  Introducing minimum user quantities introduces barriers that can affect your potential market.

Misconception 3:    Sharing an Active Directory is a terrible idea, how could you lock all your customers into one AD, that’s bad practice to lock someone in like that.

I wouldn’t say we’re are locking a customer into our Active Directory, often a customer may still have their own Active Directory on-premise, the Multitenant active directory is simply providing an authentication method that suits the service or applications we are delivering, much like Office 365 requires you have an Azure Active Directory identity over and above your existing on-premise Active Directory.

If your service allows a customer to run their entire business, such as hosted desktops.  Then some customers will be happy trade off ownership of their own AD for a flexible service model.

Misconception 4:    It’s too complex, Active Directory was never designed to be multitenanted.

In part this one is true, building a multitenant AD is a complex process.  Without the required knowledge and some level automation to introduce consistency and to remove human error, some might say you would be mad to try it.  So this is where Atria steps in, I know it’s a shameless sales plug, but in nutshell, Atria takes control of Active Directory and places management into an easy to use web portal that removes complexity for you and saves your sanity.  

So, to summarize, Multitenancy of Active Directory is possible with the right help.  It forms a crucial part in enabling you take applications you might build or support and offer these to your clients as a Cloud Service.  This method of delivery enables speed to market with consistent results. 

I hope my explanation here has in some way helped and if you would like to talk more on the topic, please reach out to us we’d love to chat.