It's Time to Move to Azure Active Directory

Legacy

plural legacies 

1. a gift by will

2. something transmitted by or received from an ancestor, predecessor, or from the past

3. a candidate for organizational membership who is given special status because of a familial relationship to a member

adjective

1. 1: of, relating to, or being a previous or outdated computer system

2. 2: of, relating to, associated with, or carried over from an earlier time, technology, business, etc.

I earned my MCSE in a simpler time. Windows NT 4.0 and 98 were the kings of the block, Exchange Server had its own identity management component, and TCP/IP was still a pretty neat idea. The year was 2000, and like any good paper tiger of the time, I knocked out enough exams to qualify for the vaunted (but ultimately not very useful) MCSE +I. 5 points to anyone who remembers that certification.

Because TCP/IP was still functionally a novelty in corporate environments at the time, Windows NT’s security structures took a while to obsolesce. NetBIOS and WINS were critical to the success of a network, and even though you had to have DNS in the mix, no *real* admin of the time worried much about it: there were, after all, master browser errors to chase! WINS record to tombstone! One-way intransitive trusts to troubleshoot!

And along came Active Directory with Windows 2000 and everything changed. At first slowly, then all at once. Gone were concerns about promoting BDC’s or separate resource domains for devices and printers, and in their places were new authentication protocols designed to end reliance on LanManager! Enter the dawn of NTLM (& NTLMv2) and Kerberos!

In the time since, Kerberos v5 has become the single most prolific authentication protocol in business environments on the planet. Every SSO story has to have a Kerberos component—it’s just the Way of Things.

But y’all… Kerberos is really old. It’s like really, REALLY old. Kerberos v5 hit the streets back when I graduated high school… in 1993.

Ok, sure, there have been tweaks and revisions and RFC’s over the years, but even if we take those into account, the most recent stable build of Kerberos in Active Directory was introduced in November 2016. Behold this helpful and article from Microsoft touting the newest features.

Most folks didn’t even have a foot into the cloud by that time.

All of which is to say… Active Directory is a legacy product.

I’ll say it again: Active Directory is “of, relating to, or being a previous or outdated computer system” / “of, relating to, associated with, or carried over from an earlier time, technology, business, etc.” It’s time to move on.

Active Directory is old enough to drink legally. It’s graduating from college this year, and it needs to start supporting itself. Change the locks and throw its stuff in the yard, because there are new and better ways to manage identity in your environment.

That linked article from 2016 isn’t the only thing that stopped being new back then. When Server 2019 hit the market, there was notably NOT a new version of Active Directory with it. No schema updates, no new domain or forest functional levels, nothing. And while Microsoft still maintains a “what’s new in Active Directory” page, literally everything there (except an internal database update that just dropped earlier this month) pertains to Microsoft Identity Manager or ADFS.

There has not been a core functional change in Active Directory since 2016, and Microsoft does not appear to be investing in future development of the product. In fact, preview releases of Server 2022 still show 2016 functional levels and offer no changes in authentication support.

Now, obviously Microsoft is NOT out of the identity game. But they are betting big on the future of that game being cloud-based.

They’re also betting that most companies never really leveraged the full range of capabilities offered by Active Directory. Would you say you’re a big fan of Group Policy? Do you have multiple AD sites with a complex replication topology? Could you name two bridgehead servers in your environment? Did you routinely assign administrative rights to OU admins?

At a more fundamental level, did you constrain resource access to domain local groups, assign those groups to domain global groups reflecting job roles in your organization, and then add users to those domain global groups? Nobody did, and if they did, those “best practices” paradigms often crashed against the rocks of middle-of-the-night support calls, by the end of which the user(s) were directly added to the domain local groups.

Or diving deeper into design philosophy, how did you even organize your AD objects? Some folks left users and devices in their default containers, but almost every OU structure I’ve ever seen failed to scale with changes to the organization. In most organizations, every few years AD gets rebuilt, reorganized or just abandoned. My garden would make a good analogy in that there are still (some) flowers growing in it, in spite of my complete failure to maintain it over the past…let’s say 5 years.

So if if your AD environment is half as overgrown as my garden, what does AAD offer to solve these challenges?

Well for one thing, it’s flat. Initially that had my traditionalist AD brain on the ropes, but there are some inherent advantages to removing the depth, like a design that simply scales without consideration.

The second is that, as a result of that flatness, all organization structures are groups. This has some pretty awesome impacts in terms of repeatability and scalability of management techniques. A user can be in hundreds of groups in AAD, but only ever one OU in AD, even if that OU is nested inside another. Seasoned AD admins (and by “seasoned” I mean those who’ve made enough mistakes to know where the mine-fields are) know the inherent risk of an inadvertent drag & drop of an OU in ADUC. Congratulations: everybody now has a complete mystery set of policies ready to pounce on their session! Hope you can undo that before too many prairie dogs pop up over the cube walls, but first you have to figure out where you dropped it, where it came from, and if your newly applied policies take any settings out of the “not configured” state, because you can’t go back to that easily.

It’s no wonder people don’t much care for GPO’s. Speaking of which, they’re replaced in AAD with Intune configuration profiles, and the capabilities FAR outstrip those of GPO’s, especially for scenarios with startup and shutdown profiles that require line-of-sight to a DC. Windows Updates, features updates, app deployment & protection, encryption, all of it in a single place with actual reporting and built-in conflict detection.

Third, groups can be of one type and used for anything. Domain local, domain global, universal, distribution? Nah: Microsoft 365 group. One-stop shopping. Make it dynamic if you want. Add a role directly to the group. Apply default sensitivity. They’re your groups: use ‘em how you want! And yes: you CAN nest them, though there are some limits. You want go super over-the-top and build out whole roles with automated multi-step approvals, access reviews, self-service provisioning, and expiring access? Get on with the gettin-on and build out Identity Governance with app catalogs and everything. It’s there: go forth and prosper!

Replication? Not a thing. At least not a thing you can manage or worry about. Ever tried to fix a Replication Island in AD? Those days are gone.

But we started our day talking about authentication protocols, so let’s turn our attention to what that looks like in Azure. Part of what makes Kerberos a ‘legacy’ protocol is that it can literally ONLY handle authentication, which is only part of the story in a ‘zero trust’ world. We need to process authentication and authorization in the same breath, something only handled by protocols that support ‘modern’ authentication.

Modern authentication enables scenarios like native multi-factor authentication. Active Directory does not support native MFA, and never will. Modern authentication also enables real-time conditional access assessment, which is critical to defining the right amount of access at the right time for the right person to the right systems. That also extends to privileged identity management, allowing us to dramatically reduce the attack surface presented by administrative role-holders.

Modern authentication delivers on the promise made by ADFS all those years ago, to the point where Microsoft is now officially recommending that people retire that complex system. I can personally confirm that I’ve been a part of more ADFS removals than installations, and several were “unscheduled” removals. Let’s not even call ADFS a legacy system: it’s an anchor tying you to servers, certificates, DMZ’s and a host of resources you’ll be able to shove off the loading dock by moving to Azure AD SSO, and there’s even a built-in tool to help you migrate those complicated claims policies to AAD.

Modern authentication goes beyond MFA now, too, to enable passwordless authentication and one-time access codes, and extends those controls to both internal and external entities.

Oh yeah, external entities! Bringing external users into Active Directory is a journey. In Azure AD it’s just an invitation, but you get to leverage the external user’s own identity protections in addition to your own to ensure the safety of your systems.

Printers? We just got those, too.

The short and sweet is that Azure AD can do literally everything Active Directory can do, more securely, with greater reliability and zero infrastructure, and without line-of-sight or VPN requirements for anything. It’s no wonder we’re seeing more and more companies reaching out for plans on how to migrate away from legacy on-prem security models to the power of cloud intelligence.

What about you? Are you still feeding servers their monthly updates to process local authentications in a 21-year-old system for users who aren’t ever fully returning to the office?

Would you like to find out more about Azure Active Directory? Learn how you can deploy Azure Active Directory today.