Stopping privileged accounts from signing in to lower tiers with user rights assignment
The tiered administration model rests on a simple rule: an account from a higher tier never authenticates on a machine from a lower tier. As long as that rule is only guidance, it will eventually be bypassed one night on call. User rights assignment lets you enforce it technically.
Why enforce tiering technically
Every interactive or Remote Desktop sign-in leaves authentication material on the machine, usable by an attacker who controls it. If a domain administrator signs in to a compromised workstation to help a user, the attacker potentially obtains the keys to the domain. Blocking that sign-in removes the opportunity instead of relying on everyone's vigilance.
The five deny rights
| User right | What it blocks |
|---|---|
| Deny log on locally | Console sign-in, including through some remote control tools. |
| Deny log on through Remote Desktop Services | RDP connections. |
| Deny access to this computer from the network | Access to shares, remote administration over SMB or RPC. |
| Deny log on as a batch job | Running scheduled tasks under the account. |
| Deny log on as a service | Using the account to run a service. |
A deny right always overrides the matching allow right. That is what makes them effective, and also what makes them dangerous when mis-targeted.
A per-tier design
The approach is to create one Group Policy object per target tier, linked to the corresponding OUs:
- Workstation GPO (Tier 2): deny all five rights to Tier 0 and Tier 1 administrative groups.
- Server GPO (Tier 1): deny all five rights to Tier 0 groups; deny local and RDP sign-in to Tier 2 accounts if they have no business there.
- Domain controller and Tier 0 server GPO: rely instead on a restricted allow list ("Allow log on locally" and "Allow log on through Remote Desktop Services" limited to Tier 0 administrators).
Use dedicated per-tier groups rather than listing accounts, and include the built-in privileged groups: Domain Admins, Enterprise Admins, Schema Admins, as well as Account, Backup and Server Operators if they are used.
Local accounts too. Windows provides the "Local account" and "Local account and member of Administrators group" identities. Adding them to the network and RDP deny rights on workstations greatly limits lateral movement with a shared local administrator account.
Pitfalls to avoid
Do not lock yourself out. Accidentally applying a Tier 2 GPO to the domain controllers OU can block all administration. Check links, filtering and inheritance, and test on a pilot OU.
Service accounts. Some service accounts are wrongly members of privileged groups. They will stop working on machines where the batch and service rights are denied to them. It is a chance to fix their privileges, but you need to identify them first.
Network access. A standard network logon generally does not leave reusable credentials on the target, unlike interactive sessions. Denying it is still useful to limit lateral movement, but it needs more careful testing because many administration tools depend on it.
The on-call process. If the only account available at night is a Tier 0 account, the restrictions will be bypassed. Give teams accounts suited to each tier and document the emergency procedure.
Going further
User rights are enforced by the target machine: an attacker with admin rights on that machine can change them locally. They therefore combine with authentication silos, which move the control to the domain controller, and with the Protected Users group. For remote troubleshooting, Restricted Admin mode or Remote Credential Guard avoids sending reusable credentials to the remote machine.
What an audit checks
- whether per-tier restriction GPOs exist and are linked to the right OUs;
- whether built-in privileged groups are included in the deny rights;
- actual sign-ins by privileged accounts on lower-tier workstations and servers;
- restriction of local accounts for network and RDP access;
- the list of accounts allowed to sign in on domain controllers.