Let's say we secure all servers in the domain..

  • Domain controllers allow RDP access only from jump servers
  • Domain admins can't connect to non-dc servers
  • And so forth

This is all swell and should be considered a safe configuration to prevent the existence of a domain admin's password in the memory of any member server.

Now let's say an attacker magically manages to apprehend a domain admin password on one of the member servers, then runs Mimikatz (or any other password extracting tool for that matter) through PsExec remotely on the DC - game over.

However, if I enforce the

Deny access to this computer from the network

on DCs and configure it for all Domain Admins, will something break?

There's also a reasoning behind this, where in no case should domain admins authenticate to the DC from another server, except from the jump server.

I have modeled this in my lab and nothing breaks, and running psexec with the domain admin password fails because of this configuration. this is a win. question is, will it work in a real network?

From what I gathered, this restriction is for any auth attempt made over SMB.

Should maybe be moved to Server Fault.

  • 1
    This might work from a purely Windows-specific perspective, but it'll likely be a problem with 3rd party software that requires idiotic permissions during installation.
    – Steve
    Dec 12, 2016 at 17:26
  • I think your point of view is very good... but you know, nothing is unbreakable. It seems you know very well that an attacker can hack an easy DC user and then pivot from his/her pc to the network to try to sniff more credentials (RDP, pass the hash attacks, etc). Is your LAN secured for this? has it port security with good and strong switches? or are standard cheap layer 2 devices? because the standard is that the "not very big companies" has cheap devices... and on that networks you can spoof, sniff, etc... so is a question of time. Anyway, good work! Dec 13, 2016 at 11:11

1 Answer 1


The ESAE (Red) Forest is now the goto recommendation for securing Active Directory. https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access-reference-material

Without knowing the intricacies of your network, its hard to say for sure, but Domain Admins do not require network access to Domain Controllers that I know of, but it could be a risky move without testing. That being said, you would obviously require physical access to those devices.

The better solution is to used a tiered model for privileged access where DCs are Tier 0, member servers or sensitive servers are tier 1, tier two is desktops. There should be no vertical traversal of accounts, so an admin may have a t0 account for DCs, t1 for member servers and t2 for desktop mgmt, and t3 for end user use. None of those can access other tiers. You can take that a step further with protected access workstations (PAW)(see link above).

If your DAs can't access your member servers, then a compromise of a member server in and of itself can't reveal a domain admin. They would have to continue to jump or find other short comings where processes or tools leak data between tiers. That is where the PAW comes in where you have a physical device with IPSec that is the only device allowed to connect to a DC, and no other account can access that device. Then you would have to have physical access in order to compromise DA and since that DA can only be used on that physical device, Mimikatz would never see it in use anywhere else.

Note: This gets more complicated if there are non-windows devices to manage. This also doesn't matter if you aren't 100% up to date on patches and don't follow other basic security practices like not running java/adobe on servers/DCs, restricting internet access to servers/DCs, implement network segmentation, etc.

Feel free to reach out if you want to discuss further.

  • IPMI or other network KVM can be a proxy for physical access, but should obviously be connected to a separate network segment.
    – Jasen
    Dec 18, 2016 at 23:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .