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.

  • 1
    If they have valid Domain Admin credentials and they are intent on doing harm... I'm at a loss for how you would mitigate that. What's to stop Jack from logging on to any other server besides member1, including a DC? If "Jill" is susceptible to social engineering or other methods maybe she should not have domain admin credentials. – Todd Wilcox Jun 16 '15 at 18:18
  • > What's to stop Jack from logging on to any other server besides member1, including a DC? A firewall. There is a firewall between member1 and the DCs. For the purposes of this example, imagine that there's a member2, also inaccessible because of the firewall. > If "Jill" is susceptible to social engineering SE is just an example. There are other ways for an internal user to obtain credentials...it's easier than some might think. – user1266898 Jun 16 '15 at 18:34
  • What about disabling the psexec service on the DCs? You can't disable RPC as far as I can tell, so that's a problem. You'd probably want to disable remote registry also. – Todd Wilcox Jun 16 '15 at 19:22
  • Yeah we might just have to settle for an approach like that (locking down things on DCs and member1). – user1266898 Jun 16 '15 at 19:35
  • 1
    Alternatively, you could use one of the tools that manage credentials for local accounts on the server through a time-based request. Users who need to gain access to the DC submit a request and then need to use a 2-factor auth to obtain a password that expires in 2 hours or so. – Kate Jun 17 '15 at 1:45

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.

  • Thanks for your answer. "If you join a domain, the domain is allowed to sign users into existence on your computer and apply GPOs to it" -- I'm not trying to protect the member from the domain (which can apply GPOs), I'm trying to protect the rest of the domain from the member (which apparently, by being a member, must have the network access needed to remotely execute code on a DC). "Using an RODC in the enclave will protect the domain from your enclave" Will it though? Our attacker will simply have to open a second remote shell (one on the RODC, one from the RODC to the DC). – user1266898 Jul 1 '15 at 1:35
  • "consider creating a separate domain (in a separate forest) for those hosts and managing them separately...also consider not joining them to a domain at all" -- this is where I'm at right now. – user1266898 Jul 1 '15 at 1:38
  • 1
    I'm not sure what you're getting at - a central design feature is that arbitrary users can't get domain admin rights, so you probably just get the security property you want for free. Anyway, I've updated my answer with a few other pointers. – Falcon Momot Jul 2 '15 at 8:59
  • 1
    Thanks for your update. To help you understand what I'm getting at, think of a *NIX server with an LDAP server and an SSH server. The capabilities of one service (authenticating users, browsing the directory) can easily be kept separate from those of the other (gaining a remote shell) because they listen on different ports. If a machine only has access to LDAP, they can't get a remote shell no matter what credentials they have. -- I was hoping some kind of equivalent setup could be done in Windows/AD but increasingly that seems not to be the case. – user1266898 Jul 3 '15 at 0:35
  • @FalconMomot I think we are all sufficiently confused at this point ... – Joseph Kern Jul 3 '15 at 14:06

What do you need to access from the domain controller? Since you have a firewall between member1 and the domain controller, you could block all access to dc1 and dc2, then put something like a read-only domain controller or a web front end on the outside of the firewall that member1 can access.

  • I thought of this, but the attacker in my scenario could just open up a second remote shell / psexec / whatever, right? i.e. psexec to dc-readonly, psexec from dc-readonly to dc1 and dc2. – user1266898 Jun 22 '15 at 22:03

You could attack this problem from another direction, by simply blocking all executables (exe, bat, ps1, etc.) from running on your DCs using either SRP or AppLocker, except those you approve beforehand. That way even if they do get access, they would be seriously hindered.

But assuming someone does have Admin privileges, they can do anything they want to your domain from most computers - the DC is there mostly for authentication...

And, as Todd said, if you can't trust Jill, you better remove here rights...


You can disable Powershell and you can stop psexec, now the issue that I see is that even if you do such things it complicates management for you and does not stop a user if they get "Domain Admin" credentials from doing anything. You could stop RDP function so it can only be accessed from certain PCs on your network but still it isn't fool proof, just harder for someone to gain access.


Simply put, a Domain Admin can do whatever he wants to do (hence domain admin!). There is no way to block someone who has stolen domain admin credential. He can override whatever security measure you put in place.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.