5

As I understand it, if a user creates a folder they become the owner and can control NTFS permissions including removal of inherited permissions granted to Domain Admins.

What is the best approach to prevent Domain Admins from being denied access to network folders? These are some of the approaches I have read about:

  1. You shouldn't be trying to prevent users from changing permissions on the folders they create.
  2. Schedule a script that takes over ownership of any folders that Domain Admins cannot access (sidebar question: if you change owner does that replace [i.e. remove] the ACE that granted full control to the original owner?).
  3. Use a combination of Share permissions change and read) and NTFS permissions (modify) to limit Authenticated Users' ability to change permissions as described by Helge Klein.
zen
  • 211
  • 5
  • 11
  • Is this a real problem that you're currently dealing with or is this based on something you read somewhere? – joeqwerty Jul 04 '11 at 22:10
  • real problem - trying to analyse network folders and I hit over 500 ACLs where access was denied to Domain Admins (who belong to Administrators group). – zen Jul 04 '11 at 22:15

3 Answers3

1

This seems more like a management issue than a technical one. Taking ownership with a script or trying to block the few people that would ever play with permissions is more trouble than I think it would be worth.

In the past, we've made personal folders completely inaccessible to domain admins, but there are inevitably times when people call up and ask "can you check something in my personal directory?"

So we follow a policy that admins have to be able to read everything (with a few exceptions). If we ever come across a folder where someone has blocked admin access, we find out why, explain why we think it's better that we have access, and we change the permissions back to our default. If it happened while we were tracking down a problem, that's why we have the policy: so we could simply take control at the time and sort it out later.

Ward - Trying Codidact
  • 12,899
  • 28
  • 46
  • 59
  • My guess is that the problem exists because the Domain Admins group didn't have permissions at the parent folder rather than a deliberate act on someone's part to lock out the Domain Admins group. – joeqwerty Jul 04 '11 at 22:26
  • @Ward - agree that this is a management issue in that it is up to the corporate entity to decide if they want to block admin access to certain data; however, when you do need admin access it needs a technical solution that is practical and doesn't cause more problems like blocking access to the original owner. – zen Jul 04 '11 at 22:33
  • I'd agree that it's a management problem but I subscribe to the notion that "Administrators / Full Control" should be on every filesystem ACL for shared folders. It's just too handy and, because an "Administrator" can always grant themselves such access anyway there's no reason not to just have the permission there to begin with. Any sense of "security" that having "Administrators / Read" on files / folders is a false sense of security, at best. – Evan Anderson Jul 04 '11 at 22:35
  • @joeqwerty - I suspect the reasons are varied although in my case I don't think it was a management decision to remove Domain Admin access. I think in some cases certain "power users" took it upon themselves to "clean up" the list of ACEs on their folders. Irrespective of the reasons, I still need to find a solution. – zen Jul 04 '11 at 22:38
  • @Evan - after my similar question about file share permissions a couple of days ago, what is your opinion of the third approach I listed? i.e. rather than using Authenticated Users/Full Control on the share, using Change+Read? – zen Jul 04 '11 at 22:41
  • @zen: If it accomplishes the business goal it certainly seems worthwhile. (I tend to be fairly results-oriented.) I don't really have a lot of problems anywhere w/ rampant user modification of ACLs (but, I suppose, now that I mentioned it there'll be a problem with it almost immediately) so I haven't employed any strategy to curb the problem that I can personally comment on. – Evan Anderson Jul 04 '11 at 22:55
  • @Evan - thanks. It seems to be that any time the network admins lose the ability to monitor permissions on a resource they have a legitimate reason to enable at least the ability to read permissions, if not full control. – zen Jul 04 '11 at 23:01
  • 1
    @EvanAnderson: An administrator granting themselves ownership is an auditable action. Writing to a file if they already have privilege very rarely is. For that reason, universal admin access should be read-only. – Ben Voigt Nov 10 '11 at 03:12
1

on option you could deploy is simply hiding the permissions tab through group policy. It won't stop a really creative user, but it will quickly weed out the majority that might tinker around. other that that, there's no need to worry about owenership so long as the admins have full control. As mentioned, you can always take ownership.

Eric C. Singer
  • 2,329
  • 16
  • 17
0

From a security and manageability standpoint, the best solution is to find who is denying rightful access and make them stop.

Users and lower-tier administrators should not be allowed to interfere with your ability to monitor and manage the IT infrastructure.

If you are only allowed to address the technical problem without addressing the larger issue, you will be forced to implement technical measures.

If you are only allowed to restore access (and not worried about identifying the source of the change), you need to do two things:

1. Assign proper NTFS permissions

You can do this via script with the icacls /grant command, or you can do it via the Group Policy editor. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > File System.

If you do it via script, you can also distribute that script as a Logon/Logoff/Startup/Shutdown script via Group Policy.

2. Assign proper SMB permissions

This requires the net command with the share verb. E.g.:

net share SHARENAME /grant:GROUPNAME,PERMISSION

GROUPNAME needs to be quoted if it contains spaces, such as "DOMAIN\Domain Admins", and PERMISSION should be READ, WRITE, or FULL.

Note that Startup and Shutdown scripts run as SYSTEM by default, so they should have no problems setting the desired permissions regardless of what has been configured for the domain admins and local admins.

If your users get clever in the future, they may add a DENY ALL entry that applies to the "Domain Admins" group. The explicit DENY entry takes precedence over your GRANT entry. You can remove this ACL entry via script as well, so it is easily defeated.

If they turn it into an arms race, you can win as long as the machine is joined to the domain, but it wastes time on both sides. This is why it is better to fix the problem via education/enforcement rather than technical countermeasures.

DoubleD
  • 141
  • 4