Home » Active Directory » Deploying Active Directory Tier Model of Administration

The importance of securing privilege access, especially when it comes to enterprise active directory is well understood and hence a preamble is not required to set a context. Past incidents of compromised active directory privileged accounts leading to serious business impact has already given the visibility and acceptance at CXO level. Team at Microsoft has provided a well-documented framework and supporting materials to implement the Tier Model of administration along with Privileged Access Workstations (PAW) to secure privilege access and prevent credential theft. Here is the quick reference of the same.

Despite these, I find not many organizations have really gone embracing the model and instead primarily relies upon role-based access control (RBAC) or delegated access control. And few have a privilege access/Identity management (PAM/PIM) solution with a true just enough (JEA) and just in time (JIT) administration. While these controllers are essential part of active directory management, a complementing tier model of administration with PAW is much needed to bring in the additional layer of protection to prevent the credential exposer and thus the credential theft. Based on the priniciple of restricting Privileged Credentials Exposed to Lower Trust Systems, tier model helps in defining the secure zones and required isolation between them.

In this post I will try simplifying the deployment strategy for Tier Model of administration of active directory along with Privileged Access Workstations (PAW) based on learnings from previous engagement around this. First you need ensure all your domain controllers are on windows server 2012 R2 or above and the domain functionality level of minimum windows 2012 R2 domain. In case your domain controller deployment is not permitting you to raise domain functionality level because of unsupported operating systems in use by domain controllers, you need to focus on getting rid of them first as your domain is in a unsecure state and the gaps between current technologies and protections are too large. And in case you are deploying or redeploying any domain controller, please consider server cover over desktop or GUI version of windows server. With PAW system providing required GUI management console, the need to have them on domain controller no longer should be an excuse.

At this point you may like to initiate a parallel track for deployment of LAPS in case you not using it, starting with domain joined windows servers.

If you can, please create a map of administrators for all the three tiers or do that for Tier0 which will be the first phase. Generally, accounts part of domain admins groups, enterprise admin group etc. will be in the scope. https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations#phase-1-immediate-deployment-for-active-directory-administrators . It would be a good idea to relook the list and optimize as much as possible to minimize the number of Tier0 accounts.

After identifying the Tier0 users, next thing is to ensure all the user have their non-privileged account and a privileged or Tier0 account. Non-privileged account is only for their info worker need like sending email, browsing net etc. This account is strictly not having any special rights, can’t even logon to a member server and for sure not to a domain controller. The privileged or Tier0 account is for doing all administrative jobs in active directory like deploying a new domain controller, modifying sites and subnet etc. And this account can only logon to a Tier0 systems, which is Tier0 PAW systems and the domain controller itself. Trying to logon to any other system including the user’s own desktop or laptop should retuned logon denied error. This can be achieved either through a group policy or preferably through Authentication Policy Silos.

Plan for PAW machines

  • Windows server with Required management tool enabled (you can use windows 10 with RSAT if you have appropriate license )
  • Virtualization-based security feature for virtual machines requires that the hypervisor hosting the PAW VMs supports Nested Virtualization
  • Features to be enabled Device Guard, credential guard and remote credential guard
  • Secure boot and hence hypervisor must support UEFI with secure boot
  • Optionally and recommended Virtual TPM (vTPM) for virtual machines to have TPM 2.0 feature
  • Proxy hardcoded to loopback IP and bypassed for intranet
  • LAPS randomizing local administrator password
  • Except for respective tier device administrators group, local admin access is not available to others like domain admins

Infrastructure Plan

  • Dedicated WSUS server or configuration of existing patch management solution to make all critical patches deployed without any delay
  • Network isolation to support Tier layers, at least direct or indirect (proxy) exposer blocked for server segments
  • Virtual infra to host the PAW machines and if required remote connection servers (Jump servers)
  • Tier management supporting configuration of in activity directory using scripts at https://gallery.technet.microsoft.com/Privileged-Access-3d072563

Infrastructure setup

In this reference infrastructure setup, a 3 nodes Hyper-V cluster is used for hosting nested virtualization enabled Gen2 (for UEFI with secure boot) VMs. For the VMs, you can use a basic unattended setup to set administrator account credential. This would help to leverage PowerShell direct to automate reset the VM configuration including device and credential guard enablement. Post configuration, logon to one of the PAW system and use klist to validate that credential guard is not listing any of your domain Kerberos ticket. Deployment of Tier 1 and 2 PAW will follow the same process.

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*