Search

Deny Domain Admins Logon to Workstations

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 logon 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 are 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 logon to workstations.'


Before starting Domain Administrator privileges is 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 your happy creating Restrictive Groups in Group Policy and assigning to OU's. Create the following AD Groups, assigning 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 account not deployed to a servers.


Svc_scom_mon_ADMP performs synthetic transactions testing 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 logon to a workstation with tenaka_wnp, tenaka_snp, tenaka_dnp, the only account that will successfully logon 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