15

As per "Best Practices" staff in our IT department have two accounts. An unprivileged account and an account that is a member of the global Domain Admins ($DOMAIN\Domain Admins) group. On our file servers the Domain Admins group is added to the local Administrators ($SERVER\Administrators) group. The local Administrator group has Full Control granted on these directories. Pretty standard.

However, if I login to the server with my Domain Admin account in order to descend into that directory I need to approve a UAC prompt that says, "You don't currently have permission to access this folder. Click continue to permanently get access to this folder." Clicking continue gives my Domain Admin account permissions on that folder and anything else underneath despite $SERVER\Administrators (of which I am a member of via the Domain Admins group) already having Fully Control.

Can someone explain this behavior and what the appropriate way to manage NTFS permissions for file shares is regarding Administrative rights with Server 2008 R2 and UAC?

Improve this question
3
  • Either manage the system remotely, or disable the UAC.
    – Zoredache
    Commented Nov 7, 2012 at 0:20
  • 3
    I disagree with anyone recommending to disable UNC. Access the files via UNC - I believe this will work even on the local server.
    – Multiverse IT
    Commented Nov 7, 2012 at 2:14
  • I can't stand this behavior in WS2008+ but have to agree with @MultiverseIT's recommendation to leave UAC alone.
    – Sam Erde
    Commented Nov 7, 2012 at 12:28

4 Answers 4

Reset to default
18

Right, UAC is triggered when a program requests administrator privileges. Such as Explorer, requesting administrator privileges, because that's what the NTFS ACLs on those files and folders require.

You have four options I'm aware of.

  1. Disable UAC on your servers.

    • I do this anyway (in the general case), and would argue that if you need UAC on a server, you're probably doing it wrong, because in general, only administrators should log onto servers, and they should know what they're doing.

  2. Manage the permissions from an elevated interface

    • Elevated cmd window, PS window or Explorer instance all work for avoiding the UAC popup. (Run As Administrator)

  3. Manage the NTFS permissions remotely

    • Connect over UNC from a machine that doesn't have UAC turned on.

  4. Create an additional non-administrative group that has full access in the NTFS ACLs to all the files and folders you want to manipulate, and assign your admins to it.

    • The UAC popup won't (shouldn't) be triggered, because Explorer will no longer require Administrative privileges, as access to the files is granted through another, non-administrative group.
Improve this answer
4
  • 3
    Good list. One note: if you manage the NTFS permissions remotely, it doesn't matter whether or not UAC is enabled for the system that you are managing from. It will not prompt when modifying ACL's on a remote server.
    – Sam Erde
    Commented Nov 7, 2012 at 12:29
  • 1
    Yay! Option 4 works well :)
    – CrazyTim
    Commented Jan 14, 2016 at 1:09
  • Something brought me back to this Q/A and I have to revise my previous comment. The list is good except for your first suggestion. If you need to disable UAC on a server, you're doing it wrong. If you must manage folders locally on a server (again, doing it wrong) :) then what you can do is add an ACE to your folder structure that grants the "INTERACTIVE" security principal the "List contents" permission. This will allow admins to browse the folder structure without UAC prompts.
    – Sam Erde
    Commented Feb 26, 2018 at 13:15
  • Interesting, option 4 didn't work for me (Server 2016). However, granting the INTERACTIVE security principle 'List folder' and 'Read Permissions' did work. But that's not what I'm comfortable using.
    – Brad Bamford
    Commented Oct 4, 2018 at 18:07
3

Set both these policies for members of local Administrator group to be able to change files and connect to admin shares:

enter image description here

A reboot will be required after making these changes.

Improve this answer
3
  • Not sure if this method actually works, but it reduces overall security and is not necessary to solve the problem. Two working solutions have already been provided without reducing security.
    – Sam Erde
    Commented May 23, 2016 at 17:24
  • This method does work. How does this reduce security where those other methods do not? Both of them recommend disabling UAC completely (although the accepted answer provides some other options). This keeps UAC, but allows members of the Admin group to actually use the permissions set on UAC. This seems to be the best method to me.
    – Mordred
    Commented Aug 31, 2016 at 18:14
  • This method will work, but disabling Admin Approval Mode neuters UAC by disabling the split-security-token which allows one to log in as an administrator without doing the Windows equivalent of logging in as root. With AAM disabled, all processes run by an administrator's account will run with full admin rights, instead of only those which require those rights and are approved by the administrator via UAC prompt. It is a core part of UAC, and you shouldn't disable it. See @HopelessN00b's answer for several superior choices.
    – Joshua Hanley
    Commented Feb 7, 2017 at 21:08
1

The best way is to change the registry key at

registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\policies\system; key = EnableLUA

Make sure it is set to Value 0 to disable it. You need to reboot to make it take effect. Interface might show it as disabled while registry is enabled.

Improve this answer
1
  • 1
    Making this registry change will disable UAC and is highly discouraged by Microsoft best practices.
    – Joshua Hanley
    Commented Feb 7, 2017 at 20:44
0

You can also disabled the Admin Approval mode for administrators via GPO or in the Local Security Policy.

Local Security Policy\Security Settings\Local Policies\Security Options\User Account Control: Run all administrators in Admin Approval Mode - Disabled

Improve this answer

You must log in to answer this question.