There's a common theme running through many of the security articles on this site. Prevent lateral movement of hackers around the domain searching for escalation points to elevate to Domain Admins. Preventing escalation via cached or actively logged on privileged accounts can be accomplished with segregated tiers between Workstations, Servers and Domain Controllers.
Implementing tiers does not prevent exploitation of system vulnerabilities and escalating via an RCE for example.
Tier 0 - Domain Admins, CA's, plus any management service running agents on the DC's.
Tier 1 - Member Servers.
Tier 2 - Workstations.
Segregation is achieved with the use of User Rights Assignments (URA) via Group Policy, additional admin accounts and AD groups.
The initial concept is easy, don't allow any account access across the boundaries between Workstation, Server or DC. Workstation admin accounts are prevented from logging on to servers and DC's. Server admins or server service accounts are unable to login to a Workstation or DC. Domain Admins never log on to anything but DC's.
The theory sounds easy until management agents are installed on DC's. There's the potential for the SCOM or SCCM\MECM admin to fall victim to an attack. The attacker is granted System on the DC's via the agent, despite the admin not being a Domain Admin. I recommend not installing management agents on DC's or CA's. One solution, as this is the real world, install the management applications with an installer account and delegate privileges to the relevant groups and triers, making sure not to cross the streams. Or create an additional tier for management servers with agents deployed to DC's.
The downside of tiers is extra accounts. If you're the DA then 3, possibly 4 admin accounts per domain are required. There's no perfect solution or one size fits all, aim to separate the tiers but allow for flex in the solution. The only hard and fast rule is 'never allow any server admin or DA to login to workstations.'
Before starting Domain Administrator privileges are required.
First create the AD Groups for denying Domain Controller, Server and Workstation logon.
Open 'AD Users and Computers' and create the following AD Groups:
RA_Domain Controller_DenyLogon
RA_Server_DenyLogon
RA_Workstation_DenyLogon
Create the following accounts:
tenaka_wnp (workstation administrator)
tenaka_snp (server administrator)
tenaka_dnp (domain admin)
Going to assume you're happy creating Restrictive Groups in Group Policy and assigning them to OU's. Create the following AD Groups, assigning them to the relevant OU.
PR_Workstation_Admins
PR_Server_Admins
Add tenaka_wnp to PR_Workstation_Admins
Add tenaka_snp to PR_Server_Admin
Add tenaka_dnp directly to Domain Admins, don't nest groups within Domain Admins.
RA_ designates User Rights Assignment.
PR_ designates PRivileged account.
This is part of a naming convention used within this Domain.
Open RA_Workstation_DenyLogon group.
Add Domain Admins, all server service accounts and PR_Server_Admin.
Create a new GPO for the Workstations OU.
Update the following User Rights Assignments with RA_Workstations_DenyLogon.
Deny log on as a batch
Deny log on as a service
Deny log on locally
Deny log on through Remote Desktop Services
Open the RA_Server_DenyLogon group
Add Domain Admins, PR_Workstation_Admin and service accounts not deployed to a server.
Svc_scom_mon_ADMP performs synthetic transactions testing the performance of internal websites and DNS lookups.
Create a new GPO for the Servers OU
Update the following User Rights Assignments with RA_Server_DenyLogon
Deny log on as a batch
Deny log on as a service
Deny log on locally
Deny log on through Remote Desktop Services
Open the RA_Domain Controller_DenyLogon group.
Add PR_Workstation_Admin, PR_Server_Admin and service accounts not used on DC's.
Create a new GPO for the Domain Controller container.
Update the following User Rights Assignments with RA_Domain Controller_DenyLogon
Deny log on as a batch
Deny log on as a service
Deny log on locally
Deny log on through Remote Desktop Services
Run gpupdate /force on a workstation, server and domain controller to apply the changes, a restart may be necessary.
All that remains is testing.
Attempt to login to a workstation with tenaka_wnp, tenaka_snp, tenaka_dnp, the only account that will successfully login is tenaka_wnp.
Attempt to logon to the server with tenaka_wnp, tenaka_snp, tenaka_dnp, the only account that will successfully logon is tenaka_snp
Attempt to logon to a Domain Controller with tenaka_wnp, tenaka_snp, tenaka_dnp, the only account that will successfully logon is tenaka_dnp