As the identity attack surface continues to evolve with new methods of compromising organizations, the need to secure an organization’s Active Directory (AD) becomes increasingly important. While Active Directory tiering is a fundamental practice to segregate and protect high-privilege accounts, yet many organizations overlook its importance, leaving them vulnerable to malicious actors.
Implementing stringent security controls for access groups is essential to prevent unauthorized access and lateral movement within the network. In this blog, we will explore the essentials of AD tiering, and common protection challenges, and discuss how Silverfort protection capabilities help organizations overcome these challenges, making the protection of AD tiering simpler and more efficient.
Common Challenges to Extend Access Controls Beyond Tier 0
Once an Active Directory Tiering project has reached the implementation phase, typically native controls (Active Directory group policies with logon restrictions) and/or Authentication Policy Silos are used to lock down access to Tier 0 (Domain Controllers, PKI online signing CA, Entra Connect / AD FS), which will then be managed exclusively from dedicated admin consoles, the Privilege Access Workstations.
However, for various reasons, organizations often struggle to extend this approach to Tier 1 – where usually 98% of all admin accounts and privileged service accounts reside. As a result, we often get asked by prospective customers how we can help them implement effective access controls beyond Tier 0.
The following are the main challenges that most organizations experience when they try to extend secure authentication and access controls to Tier 1 and Tier 2:
GPOs (Group Policy Objects) Do Not Scale
The large number of distinct access control permutations required for each combination of role (app owner, database admin, backup, etc.), resource (application name) and environment (dev/test/staging/prod), necessitate such a large number of GPOs that its implementation and operation would become too complex to manage successfully to implement least privilege inside Tier 1.
Centrally Defined Logon Restrictions, but Locally Applied
Logon restrictions – being the most common method to implement access controls, are centrally defined and stored in the SYSVOL file share, downloaded to each computer with a group policy mapper and applied locally. This approach has several drawbacks:
- Users or processes with administrator privileges on a system can change/disable/modify user logon restrictions for other accounts.
- Issues parsing group policies can lead to non-application of logon restrictions.
To detect issues when applying the policies or attempts to bypass them (e.g. using ntrights.exe or Carbon), monitoring for local configuration changes on each system is required as well as centralized reporting of any notifications of non-compliance.
Separate Access Controls for Non-windows Active Directory Assets
A sizable footprint of non-Windows infrastructure that is somehow integrated with Active Directory; whether *NIX systems joined using some form of AD-bridging, applications and appliances that rely on LDAP, Kerberos or NTLM authentications with AD – often using a service account rather than a machine identity and don’t process any or only few group policies. These devices, applications and appliances need their own access controls, typically locally defined and tied to AD group membership.
These resources each require a dedicated configuration for access controls and monitoring for compliance.
Microsoft Authentication Policy Silos – No Panacea
To overcome the issues associated with access controls locally applied on each piece of the infrastructure, Microsoft proposes Authentication Policy Silos. These can be effective to centrally manage and enforce authentication borders to accounts and assets and are evaluated by the domain controller for each authentication. While a great method to lock down Tier 0, their lack of flexibility tends to prevent rollout on Tier 1 which results in assets (resources and accounts) only being part of a single authentication policy silo at a time. Oftentimes, different groups of privileged users need access to different sets of systems, which can be part overlapping which does not fit with Authentication Policy Silos.
To use Authentication Policy Silos, Kerberos Armoring (FAST) needs to be enabled. Not all existing tools, notably some Privileged Access Management / Bastion-type solutions are compatible with Kerberos Armoring.
After the implementation of effective access controls in Tier 0, rollout to other tiers often stalls due to one or more of the above challenges encountered by IT staff, which up until now were very hard to work around. Let’s discuss some of the things Silverfort can do to extend the implementation of access controls and MFA beyond Tier 0.
How Silverfort Helps with AD Tiering
Silverfort can enhance Active Directory (AD) tiering by offering extensive visibility and control over user access across the organization. It continuously monitors authentication and access activities, assigning risk indicators and scores to users and machines based on their behavior patterns, and checks if the authentication context matches any Silverfort authentication policies. If there’s a match, the policy defines whether to allow the authentication, pause the authentication to enforce MFA, or blocks the authentication, much like a traffic light for your Active Directory authentications. This process helps identify and manage access to high-risk or high-value assets, which is crucial for AD tiering. Additionally, Silverfort’s integration with Azure AD provides further insights into user behavior and risk, supporting the implementation of an effective AD tiering strategy.
Let’s see exactly how this is done in Silverfort’s console:
Protection
Silverfort policies extend the concept of conditional access controls to Active Directory, allowing control over who can authenticate where as well as the authentication assurance level (whether MFA is required, as well as the accepted authentication type during the secondary authentication step), based on the user context enriched with its own risk engine as well as any risk perceived by third party risk engines such as part of EDR, XDR and cloud identity silos, and are centrally enforced at the domain controller.
Here are some example Silverfort authentication policies that can help with the implementation of an AD Tiering model:
Block interactive logon across Tiers
After awareness training with IT admins who crossed Tier barriers with their Tier 0 or Tier 1 accounts (for example discovered using the NOTIFY policies proposed in the AD Tiering blog article on visibility), it can be a good time to switch those policies from NOTIFY to DENY action, to block inappropriate account usage across tiers, and get real-time alerts as well as daily reports on any attempts thereof.
Protect Privileged User Accounts With Appropriate MFA
Access with privileged accounts in any Tier can be protected with appropriate MFA methods. For example, remote administration of « Application X in PROD » by Tier 1 application administrators for this perimeter can be protected with FIDO2 and/or Silverfort mobile Push MFA if there are no dedicated third-party MFA available for the Tier 1 accounts.
Secure Console Access on Domain Controllers
If access to domain controllers on the console is possible (e.g. through the hypervisor) and not adequately protected, the Silverfort for Windows Logon policy can help protect the console access.
Enforce Usage of Tier-Specific Admin Solutions
To force administration from a dedicated admin jump server or PAM solution in T1, RDP and Remote PowerShell authentication can be denied from any other origin using a DENY policy.
Stop Lateral Movement by User Accounts Within a Tier
To limit lateral movement / implement least privileges within Tier 1, remote administration of a group of servers « Application X in PROD » can be limited to the group(s) of administrators for the application servers using a DENY policy.
Stop Lateral Movement by Service Accounts Within a Tier
To limit lateral movement / implement least privileges within Tier 1, service accounts can be « ring fenced » to only provide access to the perimeter where they should operate.
Silverfort Protection Policies Help Extend AD Tiering Beyond Tier 0
The combination of Silverfort Authentication Firewall, MFA policies and ring-fencing policies service account provide an elegant and effective approach to accelerate deployment of Active Directory Tiering beyond Tier 0
Silverfort can help protect accounts of any Active Directory tier with an MFA method most appropriate for the task. The Silverfort authentication firewall allows detection and prevention of any cross-tier access by privileged accounts to prevent privilege escalation attacks, as well as limiting horizontal access within a tier to prevent lateral movement, using central enforcement while avoiding the typical complexities associated with existing methods.
Both human and service accounts can be secured, blocking unauthorized access to stop lateral movement and prevent privilege escalation by an adversary. Using the security controls provided by Silverfort can accelerate implementation of an Active Directory tiering project, or can help getting the project back on track if it’s stalled at the end of covering Tier 0. Looking to strengthen your AD Tiering management and gain complete visibility across your environment? Reach out to one of our experts here.