Active Directory is 25 Years Old. Do You Still Manage It Like It's 1999?
Hi, I’m Liz Tesch, a Cloud Solutions Architect on the Microsoft Incident Response Critical Action Team (MIRCAT). My colleagues and I specialize in helping customers with incident response and compromise recovery. In our work with customers who’ve been the victim of a cyberattack, we often see Active Directories that are 20+ years old and clients who still administer them like it's 1999. Overview Previewed in 1999 and officially released in the Spring of 2000, Active Directory is 25 years old. For those of us who remember the early years of AD, much of what we learned back in the days of the MCSE certification still stands and gives us a solid foundation for identity administration and security. However, in 1999/2000, the threat landscape looked entirely different than it does now. Ransomware was not a thing, and as AD admins our concerns were mainly managing accounts and giving our users the access they needed to work. So, if you're still managing Active Directory like you were taught to in the early years - or if you were trained to manage AD by someone else who learned it early on - you may be unintentionally putting your organization at risk of cyberattacks. Let's take a closer look at what that means, why it's a problem, and what we can do about it. Issues Location-Based AD Structure As a sysadmin in the early days of AD, chances are you were taught to organize your Directory using location-based organizational units (OUs) like the picture on the left shows. Back then it made sense because we didn't have high-speed connections between most locations, and we had to take replication times into consideration a lot more often than we do today. The problem with organizing AD this way is that it makes it challenging to effectively manage AD with Group Policy. For example, say you want to apply a Group Policy to all Tier 1 Servers in your organization, but you have 50 location-based OUs that have servers in them. Now you have to apply that GPO to 50 different OUs. (You may also need to employ WMI filtering to restrict policy use to certain servers in those 50 OUs.) Some clients find it challenging even to locate where in AD all their Tier 1 servers are, they're so spread out in different location-based OUs. Every organization is different, but if you can, consider alternative designs such as organizing assets based on function, business unit, or importance to the business instead of using location alone. Over-Privileged Service Accounts Threat actors love service accounts with Domain Admin privileges. We often see them use service accounts to hide in client environments undetected for months and as a means of getting back into the environment when they do get detected. When I was a sysadmin in the early days, Domain Admin was sometimes used as a catch-all for service accounts where we were in a hurry and we thought "Well, we don't entirely know what this account needs so let's just give it Domain Admin and we know it’ll work.” In other cases, a vendor specified that a service account needed Domain Admin, so we gave it that and never looked back. If you haven't done it in a while, review your privileged service accounts in AD and check your vendor documentation to see if Domain Admin really is still necessary. If it is, contact your vendor and push back. These days many vendors are trying to find alternative solutions to help secure their clients more effectively. For example, members of my team commonly advise customers on how you can modify your SCCM deployment to run without Domain Admin. Flat Support Structures Microsoft has a modern method of tiering infrastructure and identities that's very effective at limiting lateral movement and privilege escalation. However, we often see clients with very flat support structures that are a great help to threat actors. In one case we found that the 60+ members of a helpdesk all had Domain Admin and could reset any password in the organization. It's also common to see desktop technician accounts with Local Admin rights to every endpoint in the organization, even when their responsibilities are restricted to a given business unit or geo. Is there a way we could minimize the blast radius here? For example, maybe we could organize the helpdesk team into tiers so that only a small number of analysts have delegated access to change passwords. And how about using Group Policy or Intune scope tags to restrict desktop teams to Local Admin just within their own division or office? Deprovisioning I see two common problems with deprovisioning accounts that directly put organizations at risk for attack. For the first, I’ll come back to service accounts. We usually see clients with effective and well-maintained systems for provisioning and de-provisioning human users as part of the onboarding and off-boarding processes. However, the same is not true of service accounts. It's very normal during IR investigation and cleanup to see stale privileged service accounts in AD that belonged to applications that were retired years ago. Why are they still here and available to threat actors? Many companies also lack systems and processes to deprovision rights where something has changed, but human users have not left the company. For example, we commonly find user accounts which were given additional entitlements as part of a project that never happened, but the rights have remained for months or even years. In one case, we had a client who had documented processes and workflows for adding users to the Remote Desktop Users group when they needed remote access for a project; however, there was no process for ever removing users from that group. Eventually there were almost 200 employees with permanent remote access to most of the endpoints in the organization. Conclusion Twenty-five years after its introduction, Active Directory remains a core component of many organizations’ IT function, as well as a key factor in their cybersecurity and cyber resiliency capabilities. However, to effectively secure our organizations against sophisticated modern threat actors, it’s crucial that we recognize and change our outdated ideas about how we design and administer AD. To get started: Evaluate your Active Directory structure to make sure it’s aligned to Microsoft’s Enterprise Access Model and, if it’s not, let your Microsoft team know how we can help Review privileged service accounts in AD and check your vendor documentation to see if Domain Admin really is still necessary – push back on vendors if it is Look for opportunities to limit the number of accounts with the highest privileges, as well as the number of assets those accounts control Verify your organization has effective processes and controls for deprovisioning entitlements and accounts – both human and non-human
