Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's say that I have a folder, file, or share that I would like for almost all of my domain's users to be able to access (the domain being within a private network.) I also have some web servers within the domain that have a public-facing interface for web sites et cetera. Should the web servers be compromised for whatever reason, say a user's identity is compromised that would normally have access to the aforementioned file/folder/share, I would like to make it so that no user can read or execute that file/folder/share as long as their principal context includes one of those web servers.

I can't achieve this by simply denying that computer account the rights. How can I achieve this?

share|improve this question
up vote 4 down vote accepted

The closest feature that comes most literally close to what you're looking for is Dynamic Access Control (DAC) in Windows Server 2012 and 2012 R2, but I don't think you're going to end up standing all the necessary infrastructure just for that. Even if you did stand up DAC you're relying on a lot of "moving parts" and you really should have a "belt ans suspenders" approach with layered defenses.

Setting DAC aside, I think you'd be best off starting by segmenting your network using layer 3-7 access control mechanisms (ACLs, firewall devices, etc) to put those servers that perform public-facing roles into portion of your network that has strict ingress and egress rules to prevent those servers, should they become compromised, from acting as gateways to attack the rest of the network. If this means that you have to split some roles off to new hosts then, so be it. I tend to be one of those people who thinks that you should have physical separation of security zones, inasmuch as is feasible. Separate switches, VM hosts, firewalls, IDS, etc, should be the ideal and you should work away from that only as feasibility dictates.

You're right to be concerned about this. A friend of mine related an external web application pentest that ended up turning into a successful compromise of the Active Directory on the LAN "behind the firewall" where the public web app was located. That kind of thing can and does happen.

share|improve this answer
That looks exactly like what I was looking for. You're right, we aren't going to end up doing that. Thanks for the detailed information and wisdom. – tuespetre Jan 17 '14 at 15:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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