Is there a way, using a firewall, Group Policy setting, or other control, to prevent someone logged into a domain member from being able to remotely execute code on a domain controller (that they otherwise do not have network access to), given that they could have stolen someone's Domain Admin credentials? Or is the network access needed for routine AD membership forever and inseparably the same as the network access needed for remote execution with say PsExec or PowerShell?
To outline an example:
- Windows server "member1" is an domain member for a simple AD domain
- Windows servers "dc1" and "dc2" are the domain controllers for this simple domain
- there is a hardware firewall between member1 and the DCs, and only those TCP and UDP ports that are required for domain membership are allowed between member1 and the DCs.
- User "Jack" is a User on "member1" and besides the access described in the previous bullet, does not have network access to the DCs.
- Jack is cunning and can obtain the credentials of Domain Administrator "Jill" through a Social Engineering attack or other method.
- Jack obtains these credentials, logs into member1 and can remotely execute code on dc1 or dc2, using perhaps PsExec or PowerShell even just roll his own utility with .NET, because the network access necessary for domain membership includes the network access needed to perform remote calls such as these.
I want to stop this attack by ensuring that member1 can only perform routine AD functions (authentication, updating Group Policy, time sync, etc) on the domain, and prevent other actions such as remote execution of processes on the DCs.
Best Answer
This is not possible. If you join a domain, the domain is allowed to sign users into existence on your computer and apply GPOs to it. GPOs can cause software to be installed from the network and modify arbitrary registry entries.
Using an RODC in the enclave will protect the domain from your enclave, but it will not protect the enclave from your domain. You can use this the other way around to increase security, though, and have all your managed computers communicate only with RODCs, and allow only other DCs to access the writeable DCs.
If you have sensitive computers you want to protect from a compromise on your domain, consider creating a separate domain (in a separate forest) for those hosts and managing them separately; this is very common when secure enclaves are required. You can also consider not joining them to a domain at all, especially if there are very few of them.
Looking at your comments, I'm really not sure what your threat model is.
What exactly you do will depend very much on your threat model. However, normally domain members and arbitrary users do not have code execution on domain controllers. If it's exploits you are concerned about, patching is a good policy, and in either case using an RODC can help limit impact since RODCs can't change anything in the domain.
If you are worried about users running commands remotely or logging into the domain controller (which would not give them any rights to do things like deploy software on the domain without them also using some kind of privilege escalation exploit or similar), you can prevent them from logging into the DCs by group policy.
The settings for this are in the GPO that applies to the DCs, under
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment... if that's what you're trying to do.Users (and other security principals) are bound to the domain or to the machine, but not to both. You can't really do things like deny domain admin rights based on what computer they are connecting from in AD. But, what you can do is restrict network access to DCs that are not RODCs, and this should likely be enough (depending on your threat model) to prevent administrative actions from random user workstations. If you want to prevent users from using RODCs as pivot points (is that what you want to do?), I suppose you could deny all login rights to them, but that would make administration rather difficult - instead, I'd recommend allowing only the DS replication ports on a firewall between the RODC and other DCs.
The ports you must open are the ones identified in the documentation for RODC deployment; see the section "Required Communication Ports" at https://technet.microsoft.com/library/dd728028%28v=ws.10%29.aspx. But, alas, RPC must be allowed, and that is how psexec works. This will only let you prohibit login by things like RDP.
To round it out and prevent psexec use with stolen credentials, you could always ban domain admins from batch job login through the aforementioned GPO on the writeable domain controllers. That will slightly reduce manageability, but it's a decision you can make. There is a really good document about this and other tips for domain admin account security at https://technet.microsoft.com/en-us/library/dn487454.aspx. Using delegated access, where administrative accounts are granted specific administrative rights through delegation instead of blanket domain admin, might also be an option for you.