Transforming your organization to cloud-only: Retiring the On-Premises Active Directory

Transforming your organization to cloud-only: Retiring the On-Premises Active Directory

I’ve been delighted in recent months when more and more projects I work with are starting to consider retiring the on-premises Active Directory infrastructure. This is a massive change in terms of thinking – as, for the past ten years, Active Directory has been so crucial for all operations within companies. In this post, I plan on outlining the things to consider and the approach to retiring the AD infrastructure. In another post, I plan on documenting this in practice.

Where is Active Directory (still) used?

Everywhere, it seems! It hosts the local users, groups, computer objects, printer settings, file share settings, permissions, and admin accounts. DHCP and DNS are often AD-bound, which made sense years ago when most compute workloads were still on-premises.

Employees would arrive at the office in the morning and log in to their workstations – laptops and workstations. They’d authenticate with corporate credentials, usually in the form of DOMAIN\first.last – or perhaps in a slightly more modern syntax by using their email address. They can now access email (hosted locally, in the cloud – or even in a hybrid configuration) and files in file shares. Plenty of internal business apps would rely on the exact authentication also.

Often the AD infrastructure has been put in place around 2000 to 2005. It has a long history and plenty of cruft from past migrations and upgrades. User accounts are no longer used, numerous groups that might be automatically provisioned (but not cleaned up when no longer needed), and so many manually set file and folder permissions that nobody knows why anymore.

Key reasons to retire Active Directory

I want to be clear that I am not advocating for a black-and-white model, where the on-premises AD always has to be retired – and the only option is for an all-in cloud deployment. Yet, that is the model that fits very well for many companies. Large enterprises, perhaps, will still require a hefty and sizable on-premises footprint for decades to come – but for everyone else, less so.

Companies are now seeing less need for on-premises infrastructure. In a typical small or medium-sized business, the core infrastructure needs usually are:

  • Wi-Fi
  • DNS (for both internal and external name resolving)
  • DHCP
  • Printing capability
  • File shares
  • Firewall

And that’s about it. These can be implemented in a lightweight manner without utilizing the on-premises AD today. Once this opportunity opens up, many times, I hear – why, exactly, do we need the on-premises AD? It adds up to cost, and primarily those crucial domain controllers are often hosted within a hosting partner that tends to charge ludicrous sums of money to keep the power on.

Towards Azure Active Directory

Then, the direction is obviously towards Azure Active Directory. It’s a great set of services, but it isn’t a 1:1 match with the on-premises AD. We could synchronize our identities from AD to Azure AD for about a decade now. It’s a trustworthy service, very well managed by Microsoft, and also very affordable to use.

Since we (usually) already have our identities in the cloud, the first – and admittedly furthest – step has already been taken. It’s now up to retiring the on-premises AD and utilizing the services Azure AD provides to replace the ones we will not host locally.

Retiring on-premises Active Directory

How challenging can it be? Just run a demotion of the domain controllers in the local on-premises AD and call it a day. Right? Well, maybe yes if you’re in a single-person environment.

More often than not, the key reasons to retire AD are also the key reasons AD retirement takes a relatively long time.

Let’s review the key reasons and the cloud equivalent services once more:

  • Wi-Fi: Obviously, this will not utilize AD any longer but something the Wi-Fi infrastructure provides – such as client certificates for stronger security.
  • DNS: Internal can still rely on Microsoft-based DNS services, but usually by utilizing Azure DNS. External is usually offloaded to your Internet-provider’s preferred DNS services.
  • DHCP: Same as Wi-Fi, usually something the local network has a service for – usually for Wi-Fi clients and printers.
  • Printing capability: Utilize Universal Printing
  • File shares: Migrate to any of the reasonable new platforms, such as Microsoft Teams (nee SharePoint Online), or Azure File Shares
  • Firewall: Same as Wi-Fi and DHCP — utilize something the local network equipment can provide

To retire the on-premises AD, ideally, you choose to use Azure AD only (and not just migrate your AD domain controllers to the cloud as virtual machines). See detailed technical guidance here.

Workstations, including laptops, must be managed elsewhere than with the traditional domain-joined approach. Microsoft’s preferred method is utilizing Microsoft Endpoint Manager, which includes Intune.

In closing

In a way, moving towards cloud-only identities and reducing the on-premises footprint is a straightforward journey. At the same time, each environment has its technical debt, restrictions, and requirements that make it a custom-fitted approach. The wheel, in a sense, has already been invented, but the ability to utilize that imaginary wheel differs significantly.

Based on this high-level approach, I plan to write more about these approaches in the coming months.