Years ago onboarding a new hire meant somebody on IT physically imaging a laptop, installing the fifteen apps by hand, joining it to domain, then shipping it or hand delivering it. Took most of a day per machine if nothing went wrong, which something always did. Now the box just shows up at the person's house, they open it, sign in, and by the time they've cracked open a Dr Pepper the thing is already domain joined and pulling down apps on its own. Thats Autopilot, and its genuinely one of the better tricks Microsoft has pulled off in this space.
What Autopilot actually is
Windows Autopilot is a zero touch deployment system. The device ships straight from the OEM to the end user, no IT hands ever touch it, no custom image gets built. It uses whatever Windows install the manufacturer already put on it. All the actual configuration happens automatically the moment the user turns it on and connects to a network.
From the user's side, this is genuinely almost nothing:
Unbox it, plug it in, turn it on
Pick language, locale, and keyboard if needed
Connect to Wi-Fi or plug in ethernet
Sign in with their work account
Everything after that is automated. The device joins Microsoft Entra ID, enrolls in Intune, and starts pulling down whatever apps and policies you've assigned to it.
How the device even knows what to do
Every device has a hardware hash, basically a fingerprint generated from its hardware. Autopilot registration is just getting that hash into your tenant so Intune recognizes the device the moment it shows up on the network. There are two common ways this happens:
OEM registration, the reseller or manufacturer registers the hash for you at time of purchase. This is the actual zero touch version, you buy it, it ships, its already known before it even arrives.
Manual registration, you run the Get-WindowsAutopilotInfo PowerShell script against the device, which uploads the hash directly, or exports it to a CSV you import into the Intune admin center yourself under Devices > Enrollment > Windows Autopilot > Devices.
Once the hash is in and a deployment profile is assigned to the group that device belongs to, Autopilot has everything it needs.
Setting up a deployment profile
The deployment profile is what actually defines the OOBE experience, this is the part people usually mean when they say "set up Autopilot."
Intune admin center > Devices > Windows > Enrollment > Deployment Profiles
Create Profile > Windows PC
Name it, give it a description
On the Out-of-box experience page, pick your Deployment mode, User-driven for devices tied to a specific person, Self-deploying for devices with no user, like a kiosk, which skips the sign in step entirely
Choose whether the device joins Microsoft Entra ID or Microsoft Entra hybrid join
Configure the OOBE screens, hide or show the EULA, hide or show privacy settings, set the user account type to Standard or Administrator
Assign it to the device group that contains your registered hardware hashes
Choosing deployment mode and OOBE settings for an Autopilot profile. Source: Microsoft Learn.Assigning the profile to a device group. Source: Microsoft Learn.
That name template setting is worth calling out specifically. You can set device names automatically during enrollment using macros, %SERIAL% for the hardware serial number, or %RAND:4% for a random four digit string. Saves you from a fleet of laptops all named DESKTOP-7F3K9X2.
The part that installs the company app and sets up the account: the Enrollment Status Page
This is the piece people are usually actually picturing when they imagine Autopilot, a progress screen that shows apps and settings landing on the machine before the user is let loose on it. Thats the Enrollment Status Page, ESP.
ESP runs in two phases:
Device ESP phase, Windows configures itself and installs anything assigned to the device itself, before any user signs in
User ESP phase, once the person signs in with their own account, whatever's assigned to that user, their specific apps, their specific config, gets applied
To set it up:
Intune admin center > Devices > Windows > Enrollment > Enrollment Status Page
Select Default, or create a new profile
Turn on Show app and profile installation progress
Decide if you want Block device use until all apps and profiles are installed, this is the setting that actually stops the user from bailing out to the desktop before your company app finishes installing
Assign it, same as any other profile
The Enrollment Status Page during OOBE. Source: Microsoft Learn.
So the actual flow a new hire experiences: box arrives, they power it on, connect to Wi-Fi, sign in with their work email. Device phase runs quietly for a minute. Then the user phase kicks in, the ESP shows a progress bar while your company app installs and their account gets fully configured. When it hits 100 percent, they're sitting at a working desktop with everything already there. No helpdesk ticket, no IT visit, no imaging.
Worth knowing before you flip it on
Self-deploying mode requires specific hardware, TPM 2.0 and a few other things, since theres no user around to authenticate
Assignment isnt instant, Intune periodically checks assigned groups and it can genuinely take a while depending on group membership and hash sync timing, dont panic if a brand new device doesnt pick up its profile in the first five minutes
If you're going the manual registration route instead of OEM registration, that PowerShell script needs to run either during OOBE itself via Shift+F10 for a command prompt, or from an already set up device
Putting it together
Autopilot is really three pieces working together. The hardware hash tells Intune this device exists and belongs to you. The deployment profile tells it what the OOBE screens should look like and whether a user is involved at all. And the Enrollment Status Page is what actually holds the user back long enough for your company app and their account to finish setting up before they get free rein on the machine. Get those three pieces right and shipping a laptop straight to someone's house stops being a leap of faith.
What can we learn as a person
What gets me about Autopilot is that the device doesnt need anyone standing over it to become useful. It just needs to be registered ahead of time, know where its supposed to end up, and be given a little patience while the pieces land in the right order. Nobody's hovering, nobody's babysitting each step, it just quietly becomes what its supposed to be if you set the groundwork up front.
I think a lot of us wait for someone to hand deliver us fully configured too, wait for a mentor, a plan, someone to walk us through every screen personally, before we believe we can actually become anything. But most of the time the groundwork was already there. We were already registered, so to speak. We just needed to turn on and give the process room to run instead of white knuckling every single step ourselves.
So whats the deployment profile you've already got sitting there, ready to go, that you just havent powered on for yet?
You built the tiers. Domain admins cant log into workstations anymore, the deny-logon GPOs are humming, and you feel pretty good. Then a red team drops a report showing they lifted a Tier 0 credential and replayed it from a jump box you forgot about. The tier model told the account where it couldnt log in. It never told Kerberos where the credential was allowed to come from. That gap is exactly what the Protected Users group and Authentication Policy Silos close.
This is the follow-up to the tiered AD model. Tiering draws the boundary. These two features weld it shut.
Two features, two different jobs
People lump these together, but they solve different halves of the same problem.
Protected Users hardens the credential itself. No caching, Kerberos only, short lifetime. It makes the credential hard to steal in the first place.
Authentication Policy Silos pin the credential to specific machines. Even a stolen credential wont authenticate from the wrong host, because Kerberos refuses it.
One makes the key hard to copy. The other makes the copied key useless anywhere but the right lock. Run them together and a leaked Tier 0 account stops being a company-ending event.
Protected Users: hardening the credential
Protected Users is a built-in global security group. Drop an account in it and Active Directory applies a set of protections you cant configure or turn off. Thats the point. Nobody, including a helpful admin under pressure, can weaken them.
When a member signs in, they get this treatment:
No NTLM, no Digest, no CredSSP credential delegation. Kerberos only.
No DES or RC4. The account uses AES, which means it actually needs AES keys.
No cached credentials and no cached verifier, so offline sign-in stops working for that account.
No Kerberos delegation, constrained or unconstrained.
A Kerberos TGT lifetime locked to four hours, non-renewable. After four hours, authenticate again.
Add a user through Active Directory Users and Computers, the Active Directory Administrative Center, or PowerShell with Add-ADGroupMember "Protected Users" -Members t0-jsmith. Your domain functional level needs to be 2012 R2 or higher.
The three ways people lock themselves out
This group bites back if you rush it. Watch these:
Never add computer or service accounts. Incoming authentication fails outright, and the password already lives on the host anyway, so it buys you nothing.
Reset the password after an account migration. An account without AES keys cant authenticate once its protected. Reset forces the AES hash.
Dont bulk-add Domain Admins on a Friday. Test first. A privileged account that relies on NTLM somewhere will break, and you'll be the one explaining why.
One more thing worth knowing. The built-in Administrator account, RID 500, is always exempt from authentication policies. Keep one as break-glass, outside all of this, in a safe.
Authentication Policy Silos: pinning the credential to hosts
Protected Users shortens the fuse. Authentication Policy Silos decide where the account is even allowed to light it. A silo is a container you drop accounts into, and the policy attached to it sets two things: the Kerberos TGT lifetime, and access-control conditions for which devices the account can authenticate from.
Here's the use case that matters for a tiered environment. Create a Tier 0 silo. Assign your t0- admin accounts to it. Set a policy saying those accounts can only authenticate from domain controllers and Tier 0 privileged access workstations. Now a stolen Tier 0 credential typed on a random laptop gets rejected by the domain controller before it does anything. The credential is welded to its tier.
Creating an Authentication Policy Silo in Active Directory Administrative Center. Source: Microsoft Learn.
Building one, step by step
Open Active Directory Administrative Center and select Authentication.
Right-click Authentication Policy Silos, choose New, then Authentication Policy Silo.
Give it a display name, then under Permitted Accounts add your Tier 0 admin accounts.
Create the matching Authentication Policy, and set the access-control condition restricting which devices the AS exchange can come from.
Leave it in audit mode first. Do not enforce yet.
Restricting where initial authentication can come from. Source: Microsoft Learn.
Prefer PowerShell? The same thing in three commands:
Silos ship in audit mode on purpose. Nothing gets blocked, but the domain controller logs what it would have blocked. That is your dress rehearsal. Watch the Authentication logs under Applications and Services Logs, Microsoft, Windows, Authentication for a week or two.
Once the audit log is quiet and nothing legitimate is getting flagged, flip enforcement on with Set-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -Enforce:$true. Enforce before you audit, and you will lock a real admin out of a real domain controller. Ask me how I know.
Putting it together
Protected Users makes the credential hard to steal, Kerberos-only and short-lived with nothing cached. Authentication Policy Silos make a stolen credential worthless anywhere but its home tier. Stack both on top of the tier model's deny-logon GPOs and you have three independent layers, each catching what the others miss. Add your Tier 0 admins to Protected Users, drop them in an enforced Tier 0 silo, keep a break-glass account out of both, and audit before you enforce. That's the whole lockdown.
What can we learn as a person
The part that got in my head is the no-caching rule. A Protected User never leaves a copy of their credential sitting on a machine after they walk away. Nothing cached, nothing lingering, nothing for someone to scrape out of memory later. When the session ends, its actually gone.
I leave versions of myself cached everywhere. A hard conversation from three years ago still runs in the background of how I talk to people now. An old rejection sits in memory and quietly authorizes a hundred smaller fears. I never set a TGT lifetime on any of it, so it just renews forever, and stuff that should have expired keeps getting used against me.
The silo idea lands the same way. My realest self doesnt need to authenticate from every room I walk into. Some of it belongs only in a couple of trusted places. So what are you leaving cached that should have expired hours ago? And where have you been letting your most valuable self sign in from hosts that never earned it?
Had someone ask me, half joking half not, "can my company see what I'm doing on my phone since IT installed that app on it." And I get why they asked like that, half joking. Because the honest answer is "kind of, but way less than you think, and also maybe way more than you think, depends what else they've bought." Not a great one liner, so lets actually break it down.
What Intune actually sees
Intune by itself is a device management tool, not a surveillance tool, and Microsoft is actually pretty explicit about this in their own privacy documentation. What it collects as standard, required data:
Device details, name, model, manufacturer, OS version
Compliance and enrollment status
App inventory, meaning the name and version of apps installed, not what you did inside them
Admin audit logs, meaning what your IT admin did in the console, not what you did on your device
Theres also optional stuff an admin can turn on if they want, and it has to be turned on, its not default:
Enhanced device inventory, non sensitive hardware details like CPU, disk, and memory info
Device query, for corporate owned Windows devices only, lets an admin query specific file names and file paths on demand
Location, and this one only applies to corporate owned devices, never personal ones, and even then its not constant tracking, its an on demand "locate this device" action, usually used for lost or stolen device scenarios
What Intune flat out never sees
This part is directly from Microsoft's own data collection documentation, not marketing spin. Regardless of what an admin turns on, Intune does not collect or allow an admin to see:
Calling or web browsing history
Personal email
Text messages
Contacts
Passwords to personal accounts
Calendar events
Photos, including your camera roll
On a personal device enrolled with just app protection policies, its even narrower than that, Intune is really only aware of the managed apps and their data, the personal side of the phone stays out of view entirely. Thats the whole point of app protection policies over full device enrollment for BYOD, it draws a line around the work container instead of the whole device.
Where it changes: when Purview or Defender is in the picture
Heres the part people miss. Intune manages the device. It doesnt inspect the content flowing through it. Thats a completely different product, Microsoft Purview, and it only sees anything once a device is separately onboarded into it.
Onboarding happens through Microsoft Purview's device management center, deployed via a script, Group Policy, Configuration Manager, or yes, through Intune as the deployment mechanism. But being Intune managed doesnt automatically mean Purview onboarded, they're separate steps. If a device is already onboarded to Microsoft Defender for Endpoint, it shows up in Purview's managed device list automatically, you just have to turn on device monitoring to activate it for Endpoint DLP.
Onboarding a device into Microsoft Purview is a separate step from Intune enrollment. Source: Microsoft Learn.
Once a device is onboarded and device monitoring is turned on, this is where the visibility actually jumps. Endpoint data loss prevention can see and act on things like:
Copying sensitive content to USB drives
Printing sensitive documents
Uploading sensitive files to cloud apps through the browser
Pasting sensitive content into third party AI sites like ChatGPT through Edge for Business
And critically, once a device is onboarded, information about these audited activities starts flowing into Activity explorer even before an admin configures a single DLP policy. So enrollment into that layer alone increases visibility, before any rule is even written.
Activity explorer showing endpoint DLP events once a device is onboarded. Source: Microsoft Learn.
Stack Insider Risk Management on top of that and it goes further still, correlating signals across a 90 to 120 day window to flag anomalous behavior, like a departing employee suddenly copying a bunch of files somewhere they normally dont touch. Microsoft does pseudonymize users by default in that system and gates it behind role based access and audit logs, so its not a free for all, but its a genuinely different level of visibility than plain Intune.
Turning on device management is what brings telemetry into Purview solutions like Endpoint DLP and Insider Risk Management. Source: Microsoft Learn.
Putting it together
If someone asks "does Intune monitor my activity," the honest answer is Intune alone is closer to a management tool watching device health and app inventory, not a content watcher, and there's a documented list of things it flat out never touches regardless of settings. The real answer changes the moment you ask "what else has my org bought and turned on." Purview's Endpoint DLP and Insider Risk Management are the tools that actually look at content and behavior, and they require their own separate onboarding step, they dont just switch on because a device is Intune enrolled. If you want to know what's actually being watched at your org, the real question isnt "is this device managed," its "what security stack sits on top of Intune, and has anyone turned device monitoring on."
What can we learn as a person
I think the uncertainty is actually the honest part of this. I cant tell someone with total confidence "nobody is watching you" or "everybody is watching you," because it genuinely depends on layers I cant see from where I'm standing, what their org bought, what got turned on, what policy got written last month. And I think thats true of a lot of things in life too, not just IT. We want a clean yes or no answer about whether we're safe, whether we're being judged, whether something's being tracked or held against us, and a lot of the time the honest answer is "it depends on layers you cant fully see either." That uncertainty is uncomfortable, but pretending we have full visibility when we dont is worse, it just delays the discomfort instead of sitting with it.
So where in your life are you assuming a clean answer, safe or not safe, watched or not watched, when the honest truth is you genuinely dont have full visibility into it? What would it look like to just sit in that uncertainty instead of forcing a verdict?
Someone messaged me last week asking "what license do I actually need for this kiosk in the lobby" and I gave a confident answer that was wrong. Not because I dont know Intune, but because the licensing side of it is scattered across like four different Microsoft pages and none of them agree on vocabulary. So I went and actually sorted it out properly, and figured I'd write it down before I forget it again.
This is the "what license do I need" post. Not pricing, pricing changes constantly and I'm not going to lie to you about numbers that'll be wrong in six months. Just what each license actually covers and when you'd reach for it.
The three Intune plans
Underneath everything, Intune capability is split into three plans. Doesnt matter what bundle you bought, the docs and the admin center both talk in these terms:
Intune Plan 1, the base service. Device enrollment, compliance policies, app protection, config profiles. This covers most of what people think of as "Intune."
Intune Plan 2, additive on top of Plan 1. Adds things like Remote Help and Advanced Analytics.
Intune Suite, additive on top of Plan 1 as well, and it includes everything in Plan 2. This is the one with Cloud PKI, Endpoint Privilege Management, Enterprise Application Management, that kind of thing.
Most people never buy these three directly though. They come bundled.
How you actually get it
Realistically almost nobody buys "Intune Plan 1" as a standalone SKU on purpose. You get it through one of these:
Microsoft 365 E3, E5, or E7, commercial plans, Intune comes bundled at increasing plan levels
Enterprise Mobility + Security (EMS) E3 or E5, this was the original way to get Intune plus Entra ID P1 or P2 without buying full Microsoft 365
Microsoft 365 Business Premium, for the small and mid sized business crowd
Microsoft 365 Education A3 or A5, includes Intune for Education, more on that in a second
Microsoft 365 F1/F3, the frontline worker tiers, if your org has task workers who dont sit at a desk
If you're not sure which bundle your org has, Microsoft 365 admin center > Billing > Your products will tell you, and so will Intune admin center > Tenant administration > Tenant status > Tenant details, which shows total licensed users and total Intune licenses.
Commercial, education, and government arent the same product
Commercial is what almost everyone reading this is on. Standard Intune admin center, standard everything.
Intune for Education is a separate, simplified admin portal built for schools, at intuneeducation.portal.azure.com instead of the regular admin center. It's included with Microsoft 365 Education A3 or A5, and it trims down the enterprise-grade complexity into something a school IT person can actually manage without a full time job doing it. You can still use full Intune alongside it if you need the deeper features.
Government is its own thing entirely. GCC is actually the same commercial instance everyone else uses, just for state and local government tenants that need extra accreditation. GCC High and DoD are different, they run on a physically separate Azure Government Cloud datacenter (referred to as IL4 and IL5). You cant migrate a device between commercial and government clouds either, it has to unenroll and re-enroll clean.
Government cloud is a physically separate instance from commercial. Source: Microsoft Learn.
Assigning the license, step by step
Microsoft 365 admin center > Users > Active users
Pick the unlicensed user
Licenses and apps
Check the box for Intune, or for the EMS bundle if thats what you're assigning, then Save changes
Schools using School Data Sync can assign Intune for Education licenses right in the SDS profile setup instead of doing it user by user.
Assigning an Intune license to a user. Source: Microsoft Learn.
One thing worth knowing, admins dont always need their own Intune license just to manage the service. Tenants created after July 2021 support unlicensed admin access by default, up to 1000 unlicensed admins per security group. Older tenants can turn this on manually under Tenant administration > Roles > Administrator Licensing.
The one everyone forgets: device-only licenses
This is the one that actually started this whole post. If a device isnt tied to a specific person, kiosks, dedicated devices, phone room devices, digital signage, IoT type stuff, you dont necessarily need a full per-user license for it. Intune has a device-only subscription built exactly for this.
Device licenses apply when the device enrolls through one of these paths:
Windows Autopilot self-deploying mode
Apple Automated Device Enrollment without user affinity
Apple School Manager without user affinity
Apple Configurator without user affinity
Android Enterprise dedicated devices
Using a device enrollment manager account
Notice that last one. Device enrollment manager accounts and device-only licenses show up together a lot, because they're both built for the same problem, devices nobody personally owns.
The tradeoff is real though. A device enrolled on a device-only license doesnt get app protection policies, doesnt get Conditional Access, and loses user-based features like email and calendar. Thats fine for a lobby kiosk showing a product catalog. Its not fine if you were hoping to quietly save money by licensing a real employee's laptop this way, that device needs a proper user license because a person is actually using it day to day.
Putting it together
If someone asks you "which Intune license do I need," the real answer is: figure out what bundle your org already has first, because you probably already own Plan 1 through Microsoft 365 or EMS without realizing it. Then check if you're education (Intune for Education, A3/A5) or government (GCC High/DoD is a separate cloud, not just a setting). Then, separately, figure out which of your devices dont belong to a person at all, because those are candidates for a device-only license instead of burning a full user license on a wall-mounted kiosk.
What can we learn as a person
I keep coming back to the device-only license thing. Its basically Microsoft admitting that not everything needs the full package. A kiosk doesnt need email, doesnt need Conditional Access, doesnt need the whole suite, it just needs the bare minimum to do its one job safely. And I think a lot of us hand out the full package to things in our life that only needed the bare minimum. Full emotional investment in a situation that only needed logistics. Full attention on a problem that just needed fifteen minutes. We license everything at Plan 2 when most of it is a device-only situation.
So where in your week are you over licensing something. What's actually just a kiosk, needing the bare minimum from you, that you keep assigning your full user license to?
Last week I watched a junior admin reset a domain admin password from his regular workstation. The same machine he uses to check email, click sketchy DocuSign links, and play Solitaire on lunch. I didnt yell. I just stared at the screen, took a breath, and decided to build a tiered AD model before someone hands the whole domain to a phishing email.
If your AD is flat, this one's for you. If your domain admins log into print servers, also you. And if you've got one giant Admins group that does everything, oh boy, especially you. Here's the whole thing, tier by tier, and it stops the bleeding.
What a tiered AD model actually is
Microsoft's tier model splits your admin identities into three trust levels based on what they control. The whole point is containment. An attacker who owns a workstation should never be able to climb from there up to your domain controllers.
Tier 0 is the identity control plane. Domain controllers, AD CS, AD FS, Entra Connect, and the accounts that run them.
Tier 1 is every other server. File servers, SQL, Exchange, your line-of-business apps.
Tier 2 is workstations and the people who support them. Help desk, desktop support, end-user devices.
The three tiers and what each one controls. Source: Microsoft Learn.
The rule that makes it work is simple. Credentials never move down. A Tier 0 account never signs into a Tier 1 or Tier 2 box. A Tier 1 account never touches a workstation. Break that rule once and the whole model falls over.
The OU structure
Start with three top-level OUs, one per tier. Under each, split admin accounts, groups, and the machines that belong to that tier.
Tier 0 holds your domain controllers, Tier 0 admin accounts, and Tier 0 groups.
Tier 1 holds member servers, server admin accounts, and server admin groups.
Tier 2 holds workstations, help desk accounts, and workstation admin groups.
Your regular user accounts and department OUs sit off to the side in their own structure. Those are just people doing their jobs, not admins of anything.
The security groups
Every tier gets its own security group. Prefix them so nobody has to guess what they do. I use sg- for security group, then the tier, then the role.
sg-Tier0-Admins, full control over AD and domain controllers
sg-Tier1-ServerAdmins, local admin on member servers
sg-Tier2-WorkstationAdmins, local admin on workstations
sg-Tier2-HelpDesk, workstation support plus delegated password reset
Those groups get pushed to the local Administrators group on the right machines through Group Policy or Restricted Groups. A member server trusts sg-Tier1-ServerAdmins and nothing else. A workstation trusts sg-Tier2-WorkstationAdmins. Domain controllers trust only Tier 0.
Roles and how many accounts each person carries
This is where people groan, because it means carrying more than one login. Good. That groan is the sound of security working. Here's how the accounts break down by role.
The System Administrator: four accounts
Your full-stack sysadmin touches everything, so they need a foot in every tier plus a normal life.
A normal account for email, Teams, and daily work
t0-jsmith in sg-Tier0-Admins for domain controller work
t1-jsmith in sg-Tier1-ServerAdmins for servers
t2-jsmith in sg-Tier2-WorkstationAdmins for workstations
Four accounts, four scopes. The domain admin credential never rides along on the same machine where they read email.
The Server Admin: three accounts
Your server team doesnt need the keys to Active Directory. They manage servers and the workstations they sometimes sit at.
A normal account for daily work
t1-account in sg-Tier1-ServerAdmins for servers
t2-account in sg-Tier2-WorkstationAdmins for workstations
Notice the missing Tier 0 account. That's on purpose. A server admin who gets phished cant hand an attacker the domain, because that person was never holding it.
The Help Desk: two accounts and a delegation
Help desk lives in Tier 2. They fix laptops and reset passwords, nothing deeper.
A normal account for daily work
t2-account in sg-Tier2-HelpDesk for workstation support
The password reset piece isnt a tier privilege. It's a delegation. In Active Directory Users and Computers, right-click each department's user OU, choose Delegate Control, add sg-Tier2-HelpDesk, and grant "Reset user passwords and force password change at next logon." Scope it to the department OUs they actually support, not the whole domain. Help desk can unlock the sales team without ever seeing a server.
The part that makes it real: cross-tier logon deny GPOs
Groups without GPOs are just labels on a whiteboard. The enforcement comes from Group Policy denying higher-tier accounts the right to log into lower-tier machines. Without this step, nothing actually stops a Tier 0 account from signing into a workstation.
You build three deny policies, each linked to the OU one tier down. Every policy sets these User Rights Assignments under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies:
Deny log on locally
Deny log on through Remote Desktop Services
Deny log on as a batch job
Deny log on as a service
Deny access to this computer from the network
Link the first policy to your Tier 1 and Tier 2 OUs, denying the Tier 0 groups. Link the second to Tier 2, denying Tier 1 groups. The result is a one-way street. Credentials flow up when you deliberately elevate, never down by accident.
One warning. Test these against a pilot OU before you link them broadly. A deny right applied to the wrong group can lock real admins out of real machines, and that's a bad afternoon.
Why this setup is worth the extra logins
Attackers rarely land on a domain controller first. They land on a workstation, through a phished user or a bad download. From there they hunt for credentials sitting in memory, then hop machine to machine until they find a domain admin token. Security folks call this lateral movement, and it's how most ransomware actually spreads.
The kill chain the tier model is built to break. Source: Microsoft Learn.
Build a tiered AD model and you cut that chain. If a Tier 0 credential never touches a workstation, then owning the workstation gets an attacker nothing but the workstation. The domain admin token they were hunting for simply isnt there to steal. You shrink the blast radius of every single compromise.
The other half of this is the clean keyboard. Microsoft calls them privileged access workstations, PAWs. The idea is that Tier 0 work happens from a hardened machine that never browses the web or reads email. Trust starts at the physical keyboard you sign in from, not the server you're reaching for.
Supported paths from a clean PAW up to a Tier 0 server. Source: Microsoft Learn.
Putting it together
Three tiers, three OUs, four sg- groups, and three deny-logon GPOs. Give your system admin four accounts, your server admins three, and your help desk two plus a scoped password reset delegation. Test the deny rights on a pilot before you go wide. That's the whole model, and it turns a single compromised laptop from a company-ending event into a Tuesday.
What can we learn as a person
The thing that stuck with me building this is that the whole model runs on one boundary. Credentials dont move down. That's it. Everything else is just enforcement of that one line.
I think about how much of my own stress used to come from having no tiers at all. Work stress logged straight into my home life. A bad day with one friend leaked into how I treated my kids. One compromised area, and the attacker moved laterally through everything I had, because I never denied the logon. I was one giant Admins group that did everything, and every problem had domain rights over my whole self.
Tiering my life didnt mean caring less. It meant the hard server day stays on the server, and doesnt get to sign into the parts of me that were supposed to be off-limits. So what in your life is running flat right now? And where do you need a deny-logon rule so one bad thing stops taking down all the others?
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
