I have created a user admin and putted this user in the Administrators Groups (local, there is no AD). But This admin user has not the same rights as the Administrator user itself.

Example 1: a file is owned by SYSTEM and the Administrators Group has full control. If I try to add permissions for a user to this file, it doesn't work for the admin user. With the Administrator is works without any problem.

Example 2: IE Enhanced Security Configuration is set OFF for Administrators, ON for Users. For the Administrator this is OK, for the admin user it is still on.

Is this a configuration problem? If so, what do I need to do to make it right?

  • 1
    This shouldn't behave this way. Please make certain that this local account truly is in the local Administrators group. While logged in with that user you can run WHOAMI /GROUPS /FO LIST to verify that they truly are a part of the right groups.
    – TheCleaner
    Nov 24 '14 at 16:24
  • 5
    Have you logged out and logged back in with the new user after making him a member of the Administrator groups? His access token will not change for the lifetime of the current session on that machine Nov 24 '14 at 16:29
  • @TheCleaner: these are the groups he is member of: Everyone, NT AUTHORITY\Local account and member of Administrators group, BULTIN\Administrators, BUILTIN\Users, NT AUTHORITY\REMOTE INTERACTIVE LOGON, NT AUTHORITY\INTERACTIVE, NT AUTHORITY\Authenticated Users, NT AUTHORITY\This Organization, NT AUTHORITY\Local account, LOCAL, NT AUTHORITY\NTLM Authentication, Mandatory Label\Medium Mandatory Level
    – Maarten
    Nov 25 '14 at 15:52
  • With it not being on a domain, I wonder if it's a UAC issue. If you disable UAC (User Account Control) on the server does it work then? social.technet.microsoft.com/wiki/contents/articles/…
    – TheCleaner
    Nov 25 '14 at 16:07
  • The rights problem (example 1) seems to be OK after disabling the UAC. The IE ESC is still a problem.
    – Maarten
    Nov 25 '14 at 16:33

This could be caused by User Account Control, a feature (hated by many) which makes so that, even if you have administrative rights, you don't actually have them unless you explicitly request them. There are two distinct policies governing UAC behaviour (both found in Computer settings\Windows settings\Security settings\Local policies\Security options), one for the built-in Administrator account, and another one for all other administrative users:

  • User Account Control: Admin Approval Mode for the built-in Administrator account (disabled by default)
  • User Account Control: Run all administrators in Admin Approval Mode (enabled by default)

What this means is: by default, the built-in Administrator account is not affected by UAC, while all other administrative users are; thus, it's possible for an administrative user (different from the built-it Administrator) to not actually have administrative rights, even if it's a member of the Administrators group.

More info here.

  • Disabling the 2nd setting fixed the problem for me on Windows 10. Can you explain why this setting exists? What's the point in having an Administrator group if members of that group don't have access to any of the permissions of said group by default?
    – Mordred
    Aug 31 '16 at 17:43
  • 1
    The point is (supposedly) that UAC stops users with administrative rights from accidentally shooting themselves in their feet, because they have to explicitly request the system to grant them the privileges they should have (using "run as administrator" when launching a program).
    – Massimo
    Aug 31 '16 at 22:02
  • 1
    However, the implementation is so flaky (f.e. you can't use "run as administrator" on Windows Explorer because it's always running and you can't launch another instance of it with elevated rights) that most power users just end up disabling UAC altogether, in order to be able to actually use their computer.
    – Massimo
    Aug 31 '16 at 22:03
  • 2
    UAC has been around since Windows Vista, but it's even worse in Windows 8 and later (including 10), because disabling UAC effectively stops Metro/Modern apps from running at all: for some unknowable reason, they seem to actually need UAC to run, and they don't even start if UAC is disabled.
    – Massimo
    Aug 31 '16 at 22:06

I had a similar situation and fixed it following the steps of http://clintboessen.blogspot.com/2013/05/you-dont-currently-have-permission-to.html (which are for a different situation). This is what I had and what I did:

  1. Two computers, no Active Directory Domain, one with Win 8.1 (name W81 for example), other with Server 2012 (name w12 for example)
  2. Two local users on w12: [UserA] with PasswordA and [UserB] with PasswordB. Both belong to the [Administrators] local group.
  3. Two local users on w81: [UserA] and [UserB] with se same PasswordA and PasswordB as the corresponding users of w12. Both belong to the [Administrators] local group.
  4. I share a folder on w12: a. Share name: Temp1$ b. Share permissions: [Everyone], Full Control c. NTFS permissions: [Administrators], Full Control. No other Group has NTFS permissions here
  5. Logged in on the W12 as [UserA], I try accessing the share using UNC \w12\Temp1$ . I get an error saying I have no access. The share is found. Just no access.
  6. Logged in on the W81 as [UserB], I try accessing the share using UNC \w12\Temp1$ . I get the same error. RESTARING w12 DOESN'T HELP.
  7. If I add [UserA] and [UserB] explicitly to the NTFS permissions, they now have access to the share using steps 5 and 6.
  8. I Ran GPEdit.msc on w12, went to:

Computer Configuration --> Windows Settings --> Security Settings --> Local Policies --> Security Options

and used the settings for #1 and #3 recommendations:

#1, User Account Control: Admin Approval Mode for the Built-in Administrator account : Disabled. #3, User Account Control: Run all administrators in Admin Approval Mode : Disabled.

And left #2 untouched: #2, User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode : Prompt for consent for non-Windows binaries

  1. Restarted the machine and the situation didn't happen again.
  • 1
    Permission to access the share(Share permission) is not the same as permission to access a file(NTFS permission). They are and should be separate.
    – artifex
    Jul 18 '15 at 23:17

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.