Don Jones

Tech | Career | Musings

AD turns 17 this year. That’s a long darn time for a directory service, and you might wonder how much life it’s got left in it. Oh, I don’t mean as in, “Windows Server 2018 is going to eliminate AD!!!!” No. Whatever happens with AD will be an evolution, not a revolution. And I’m not even sure Microsoft has a firm marching plan on this – I think they’re kind of playing it by ear.

But it’s fun to look at what they’re doing, and guess where they might go next.

First, Microsoft has increasingly been breaking down larger, monolithic services into smaller, point services. AD today performs a variety of functions – authentication, a degree of authorization, a kind of configuration management, a literal directory, and so on. I could definitely see those being broken out.

Configuration management is the easiest one to imagine. Rip Group Policy right out and replace it with Desired State Configuration. Oh, not the DSC you know today – no, no. DSC with a smarter Pull Server that can assemble multi-part configurations based on of-the-moment criteria – just like Group Policy does as it assembles GPOs today, but with far greater reach than just the registry and handful of other things GPPs can touch. This wouldn’t even be all that noticeable to users, and barley noticeable to admins. Slap a nice Policy Editor GUI on top of it all, and you’d never need to really know that the policies were in a MOF file instead of an ADMX or whatever. This’d be easy.

Next I think you’ll see your on-prem domain controllers become subordinate to your in-the-cloud Azure Active Directory. That is, you’ll manage your directory in the cloud, which will then replicate down to the office for people to authenticate against. Very small businesses might opt out of an on-prem DC entirely. Yeah, there’ll still be some edge cases that need an offline, on-prem DC for whatever reason (“we don’t have Internet in the coal mine”), but those are called “edge cases” for a reason. This main-directory-in-the-cloud will make identity federation a lot easier and more transparent, since Microsoft will do all the hard work to make it function. Again – largely transparent to users, minimal changes daily processes for admins, but an important structural change. It’s kind like when Apple switched from the Mac being the “digital hub” to their cloud being your hub, and your Mac simply being another device attached to the hub, rather than the center.

Various on-prem options could be brought into play for integration. Deploy an on-prem agent to sync local HR data to Azure AD, for example. That kind of thing. You’d never need to worry about “losing” your directory, because it’d live in a highly resilient cloud. Schema extensions? So 10 years ago. Like, I think even Exchange Server wishes it hadn’t gone that route. Something like an on-prem AD AM could be deployed to accommodate that, if needed.

This certainly fits the model Microsoft has been moving toward: C&C in the cloud, telling on-prem resources what to do. Microsoft’s gone all-in on “hybrid,” that way, to a degree that other cloud vendors haven’t. And, truthfully, can’t.

As the centerpiece of your network, AD plays a crucial role that we all too often don’t think about, because it more or less “just works” all the time. So it’s interesting, for me, to think about where it might go next. Yeah, there’re challenges to be solved – PII issues, for example – but those are solvable. Remember, we’re not looking at what Azure AD is today; we’re thinking about what it, and AD itself, might become. 

What do you think might happen?

Categories: Tech

6 thoughts on “Let’s Talk About Active Directory’s Future

  1. Keith Graves says:

    I think you’re right that AD will be broken up into smaller services. For example in large “cloud” environments, where we dynamically spin up and tear down VMs, or move services to containers, the act of joining and removing machines from AD seems like it will cause more and more problems. I could see a split where user or application level authentication is still done with a central database or directory service, but administrator and system level authentication would be done with some kind of PKI solution, which eliminates the need to join a machine to AD. Especially since Microsoft is pushing solutions that work in a more heterogeneous environment, not just a Windows environment.

  2. cwestwater says:

    Now that Windows can run container via Docker how about those AD modules running as containers?

  3. Chris Simmons says:

    Great thoughts, as always Don.
    For me I really want to see Azure AD Domain Services developed as far as it can be. I feel like that is the next generation of Active Directory. I can easily see an end game of Azure AD DS being your authoritative domain in the Cloud, with various integrated and supporting services…

    – Azure AD Domain Services Domain.
    – Azure AD Directory Tenant.
    – Domain join VM extension.
    – Domain join App Service extension.
    – Next-gen DSC as you described.
    – Azure AD DS Agent role in Windows Server, for attachment of local RODC-like nodes.
    – Native Azure AD DS join ability for Windows & Windows Server (part way there).

    I’ve had that end DSC vision in my head since I first learned of DSC 🙂

  4. A DSC type take over of GPO with https pull would completely change managed IT services for SMB. I could start a small office on a basic workgroup linked to a pull server. Add a private chocolatey repo, some basic event forwarding, SQL, and SQL reports on one Azure virtual server. I would have the power to control the OS, install software, update software, and provide basic audit reports with-out having to remote control any client desktops. Then As needed a full feature directory service in the cloud to control networks with more users or just to control hosted software access. It would be just a great way to setup a small medical practice and meet the security and audit controls required by the by the Federal Code of Regulations AKA HIPAA.

    I’m always stuck between the need for AD and GPO to keep a small network of 5-25 PC functional and ‘safe’ and the ability to sell the client on the cost of a local server. Then I still have all these unconnected local servers to deal with.

  5. sumdog says:

    I don’t really see companies removing on-premises AD domains. There might be a few use cases for small startups, but for a lot of shops, things should be designed so that at least some business can continue to run, even if you lose Internet connectivity. Sure loss of connectivity will kill IT dev and operational work, but people scanning documents or editing photos should still be able to work even if other services fail. Sure Windows boxes can still auth with their last password if the domain goes away, but there are a lot of other tasks and jobs that may fail if your authentication system is suddenly gone.

    I have not had to use Azure yet, but every person I’ve talked to about it has classified it as varying degrees of terrible. Furthermore, I think as business get larger and grow away from their startup phase, “putting things in the cloud” is being replaced with running it yourself. AWS is expensive. Sure you get management and hardware upgrades, but at some point the scale tips and you see companies trying to setup local systems on hardware they control. Two companies I worked for in the past made the mistake of using OpenStack, which is a terrible terrible idea. One of those companies is transitioning from OpenStack to DC/OS and container orchestration. They’re migrating what they can off AWS to save on costs (and when you have a lot of stuff in AWS that doesn’t need to be, those costs are significant — end when you factor in the man hours of running a DC/OS cluster).

    Back to AD, it has always been a mess for me. I was with one startup where I administered AD servers, but we pretty much used them as LDAP authentication for all our Linux boxes (the majority of our servers actually). If I were to run that shop again, I would have used LDAP exclusively (especially since you can run mssql in a Linux Docker container now). AD permissions are very difficult to audit, especially since you can add AD users to local groups. At Defcon 2016, a security company open sourced an incredibly valuable tool for auditing windows environments for permissions and security issues. It’s incredible and I highly recommend checking it out:

    https://github.com/BloodHoundAD/BloodHound

    One more horror story, I worked at one shop where we were moving a data centre from one city to another and had a bunch of AD DNS entries that were A records instead of CNAMES. No one realized this until the day of the cut-over. This resulting in the Linux Sysadmin (me) having to churn out some (terrible) powershell scripting to rewrite DNS entries:

    http://penguindreams.org/blog/reassigning-dns-entires-in-windowsactive-directory-using-powershell/

    If we had been using BIND internally (we were using BIND externally), this entire script would have been a simple search and replace. So as far as modularization goes, DNS should be its own module … and installed/used never.

  6. I think lots of companies would wish most of the IT staff just go away… They want a non-it manager to control user and resources via a web portal like googledocs or office365.

    In the future: There will likely be a ‘security expert’ auditing users and resources. With a few lower-end techs trouble shooting and installing devices. High-end techs will setup and run cow-servers hosting services such as a directory service. Lower-end tech will setup and control web base resources designed and sub-organized for there company’s size. I think (like most of the time) Mr. Jones is right about AD and GPO…. Only techs like to setup and run servers, and techs are not in-charge of most business.

    For all the non .net and linux guru (like me) here’s a few powershell hints for DNSServers.

    get-command *dns*
    remove-dnsserverresourcerecord -zonename -name -rrtype
    set-dnsserverresourcerecord -zone -name -rrtype

    get-dnsserverresourcerecord | get-member
    get-dnsserverresourcerecord -zonename nameofzone | where {$_.recordtype -eq “a” -and $_.hostname -e “www”}

    think you could also… export-dnsserverzone
    modify file and import-dnsserverzone

Comments are closed.

%d bloggers like this: