PAWs, zones and tiering.
What do any of those terms have to do with Active Directory.
If you haven't seen the Microsoft enterprise access model yet, then these are set to blow your mind.
As it turns out, a team out of Monash University has put together a model that expands on the Microsoft access model to give rise to granular controls that make life hell for any would be hacker.
The system is broken down into three tiers or planes:
- Control plane - Contains Domain Controllers & Domain Admins, PKI, DC Hypervisors, Tier 0 privileged accounts
- Management plane - Contains services such as SCCM, File & Print Management, Backups, SQL, Workload Hypervisors, and Tier 1 privileged accounts
- Workload plane - Contains Workstations, servers and general user accounts
With three distinct rules from Microsoft's blog on how to maintain security.
- Rule #1: Credentials from a higher-privileged tier must not be exposed to lower-tier systems.
- Rule #2: Lower-tier credentials can use services provided by higher-tiers, but not the other way around.
- Rule #3: Any system or user account that can manage a higher tier is also a member of that tier, whether originally intended or not.
Now let's dive into the technology that makes all this possible.
PAWs
A privileged access workstation (PAW) is a dedicated device that is used for administrative duties. They are trusted devices which are specifically designed to be used solely for administrative tasks. No emails or web browsing.
With a PAW there comes the need for dedicated accounts.
These are accounts that cannot access your standard corporate laptop or regular webserver.
They will generally have a convention such as appending ".admin" to the end of a standard user account, for example if my user account was kmurray, then my administrator account would be kmurray.admin.
I would be able to use my standard account for my regular work activities on my corporate laptop and will only have access to privileged devices using that dedicated account.
Zones
Zones were created to further segment the individual tiers themselves.
They divide the control, management and workload planes into smaller groups that separate the level of control a compromised account will have at any given time.
A further look at an example of zones in practice is:
Tier 0
- Zone 0A - Domain Management
- Zone 0B - Domain Hypervisor Management
Tier 1
- Zone 1A - Workstation Management
- Zone 1B - Server Management
- Zone 1C - Storage Management
- Zone 1D - Hypervisor Management
Tier 2
- Zone 2A - Workstations
- Zone 2B - Servers
Which will create the effect where if the Workstation Management zone is compromised, the server zones will be unaffected.
Now that is a lot but the question is how is any of that implemented.
Authentication Policy Silos
Authentication policy silos are a way to further segment the authentication process.
They are used to create a separation of authentication between the different zones.
For example, if the Workstation Management zone is compromised, the authentication policy silo will prevent the user from authenticating to the server zones but will allow them to authenticate to the workload plane.
In the model above, they have been implemented in two ways.
PAW Silos: Per-tier "computer" silos that contain PAW machines.
- Only PAW Users in a specific tier can authenticate.
Zone Silos: Per-zone "user" silos that contain user and service accounts.
- Users in a zone can only authenticate to:
- PAW devices
- Computers within their own zones
- DA Silos only: Domain Controllers
Now if that seems daunting to deploy, there are fully deployable scripts to create a mock environment to get a feel for what it should look like.
And write ups that cover silos and everything needed to roll them out into a production environment.
Going further
Now that your Active Directory is built like Fort Knox, we might as well mention even more hardening related to just-in-time (JIT) administration.
Microsoft have written a blog about it and a couple of engineers have written a series of PowerShell scripts to help.
JIT administration temporarily elevates user privileges only when needed, which massively reduces the risk of misuse.
It works by granting privileged access for a limited time, ensuring that users can elevate only on a limited number of devices at the same time and are automatically removed from privileged groups after a defined period.
In practice when an administrator wants to elevate, they logon to the JIT management sever and request admin access to a specific server they require elevation on.
