If you’re interested in Active Directory security, you’ve undoubtedly heard of the Zero Trust model. Briefly, Zero Trust is a great security model for modern IT environments because it assumes that breaches are inevitable and malicious actors are already inside your IT ecosystem. Therefore, no user, service or other entity should be trusted implicitly, and you should be always be actively looking for anomalous activity that could indicate a security threat.
That’s all I’m going to say here about what Zero Trust is. For a more in-depth introduction to the Zero Trust model, I highly recommend reading the blog post, “Zero Trust: What it is, why you need it, and how to get started.”
Instead, I’m going to focus on how you can implement a Zero Trust model in your on-premises or hybrid Active Directory environment. Specifically, I’ll offer three best practices that can be a valuable part of a Zero Trust strategy because they dramatically strengthen Active Directory security.
Don’t trust admin accounts: Provide elevated privilege only for finite periods of time.
Standing accounts with a great deal of power are an intrinsically dangerous thing. Administrators who misuse their elevated rights, either deliberately or accidentally, can cause enormous damage — and an attacker who compromises a privileged account is a critical threat.
Accordingly, a Zero Trust model involves granting admins elevated privileges only when they need them, and only for as long as they need them. There are several ways to accomplish this “just-in-time” privilege escalation in Active Directory, including the following:
- ESAE (Red Forest) model — For several years, Microsoft championed the Enhanced Security Admin Environment (ESAE) model, in which accounts that have privileged access are held in a special, highly secure administrative forest, commonly called a Red Forest. Part of this model was that these users would become members of “msDS-ShadowPrincipal” objects for a period of time. These objects mapped to powerful groups in managed domains— which essentially means that an admin could get domain admin privileges for a period of time without ever actually being a member of the Domain Admins group. However, the ESAE architecture is complex and usually effective only for the most powerful accounts in Active Directory. Therefore, Microsoft is no longer recommending ESAE for most customers. (The exceptions are situations where the need for strong security outweighs the increased complexity and operational costs of ESAE, such as offline research labs and industrial control systems.)
- Temporary group membership — Active Directory accounts are usually not assigned permissions directly; instead, they get their privileges through membership in particular groups. It has always been possible to implement software that provides group membership for a limited period of time, but doing this usually left the account with permissions on issued Kerberos tickets that could persist well after the user was no longer a member of the group that gave them those permissions. Windows 2016 changed this: Group memberships can now be assigned a “time to live” value, with a synchronized ticket expiration. This means that Active Directory itself will expire a user from a privileged group, and the user’s Kerberos ticket will expire soon after.
- Temporary admin accounts — What is better than having an admin account with no privileges? Having the account be disabled until it needs to be used. Privileged identity management systems use a check-in/check-out system so that privileged accounts that aren’t being used can pose no threat.
Whatever method you choose for just-in-time privilege escalation as part of your Zero Trust model, make sure that you can specify “who can do what, when.” Also consider using software like Change Auditor for Active Directory to closely audit the activity of both privileged and regular user accounts and even prevent accidental or deliberate changes to critical Active Directory security objects.
Don’t trust the password: Consider moving away from passwords.
Security researchers and big IT are starting to realize what users have known for a long time: Passwords are awful! In particular, the age-old practice of forcing users to pick very complex passwords and change them once a quarter was a bane to both users and the help desk — and it ultimately didn’t increase Active Directory security that much.
A Zero Trust model involves trusting a single password far less. Here are some options:
Reduce your AD attack surface.
- If you have a hybrid Active Directory environment and use Microsoft 365 services, then your users already have both an Azure AD account and an Active Directory account. Consider transitioning your users to leveraging Azure AD as their primary authentication source, since Azure AD can now issue Ticket Granting Tickets for on-premises Active Directory domains. This lets your users use endpoints that are non-domain joined (not even hybrid!) and access network resources that require Kerberos authentication. Using Azure AD for authentication not only frees users from needing to periodically use a VPN to authenticate, but enables all the great security features in Azure Active Directory, from Windows Hello and other password-less options to as options like geo-filtering and impossible travel.
- If you don’t have a hybrid Active Directory environment or making Azure AD your primary authentication source isn’t a possibility, invest in a multi-factor authentication system that integrates with Active Directory. That way, even if a user account does need a password, that password will not need to be changed frequently — and it will pose far less threat if it is compromised.
Don’t trust AD admin accounts in the cloud: All accounts with privileged roles in Azure AD or Microsoft 365 should be cloud-only.
Microsoft invested a large amount of engineering resources into making Active Directory and Azure Active Directory work tightly together. In a hybrid Active Directory environment, it’s easy to leverage the infrastructure and credentials you already have deployed on-premises to access data, applications and infrastructure in the Microsoft cloud.
In fact, it can be too easy. Many organizations moving to a hybrid Active Directory deployment wanted to leverage their existing on-premises policies and processes for administration in the cloud, so they simply made their on-premises administrative accounts and service accounts hybrid. This architecture has led to some very serious attacks on cloud infrastructure, in which attackers use the complexity and legacy nature of Active Directory to attack systems and information in the cloud.
To put it simply: Any account that has a privileged role in Azure AD or Microsoft 365 should never be hybrid — it should be cloud-only!
Final thoughts
These three best practices provide a solid foundation for implementing a Zero Trust model. However, please note that they do not constitute a checklist for “accomplishing” Zero Trust. Indeed, implementing any security model is not a matter of adopting a few best practices or deploying one software solution; rather, it requires building a layered security framework that involves a wide range of technologies, processes and policies — and constantly assessing and improving it as your IT environment, your business requirements and the threat landscape all evolve. Remember, a Zero Trust model, like Active Directory security, is a journey, not a destination.
