0

I'm running into the same problem again and again for ages so I decided to ask my question here :

I added a service account "ZYX" into the Administrators group of my Windows 2K8 Server.

Whenever I try to run a scheduled task (running as "ZYX") that modifies a file located under a folder where the Administrators group has full control, my PowerShell script always gets "Access to the path xxxxxxx is denied".

When I check the effective permissions of my service account on this folder, it is written that it is granted every single permission.

I found two ways to overcome the situation, but I find this really ugly :

  • Running the scheduled task with highest privileges
  • Add the service account "ZYX" with full control in the folder Security part.

Im starting believing my service account only gets the rights inherited from the Administrators group when the shell runs in elevated mode.

Can someone explain me why Windows manages the rights like this ?

Do you have any better solution for this ?

Thanks

Tjamat
  • 193
  • 1
  • 11
  • Do you have a programming question? – KevinDTimm Jun 11 '15 at 16:14
  • 1
    When User Account Control (UAC) is enabled, the Local Security Authority (LSA, lsass.exe) logs on an administrator using two separate logon sessions and two access tokens, one that's limited and one that's a full administrator. The limited token is stripped of administrator privileges, and the `BUILTIN\Administrators` group is included only for denying access. A `SYSTEM` service, such as the task scheduler, can access the linked adminstrator token (i.e. "highest privileges") without having to go through the normal secure-desktop elevation process. – Eryk Sun Jun 11 '15 at 23:34
  • 1
    The scheduled task only runs with administrator privileges enabled if the option "Run with highest privileges" is enabled - that's what that option is for. Obviously, the concept of "administrator privileges" includes accessing objects that are restricted to members of the Administrators group, since there are many sensitive objects that are protected in exactly that way. – Harry Johnston Jun 12 '15 at 01:45
  • Hi, thanks for your answers. @eryksun : if the builtin administrators group works only to deny access, how can that group be used (not running with "highest privileges") to allow access for its members ? Do have to explicitly type in the name of my service account on this folder / file (in my example) to grant him access ? – Tjamat Jun 12 '15 at 08:03
  • @HarryJohnston : do you mean that if I have a scheduled task registered with a service account that is a member of the builtin administrators group, I'll have to launch it with the "highest privileges" option to give that account the same rights the builtin administrators group has ? – Tjamat Jun 12 '15 at 08:09
  • A secured object can have a [`ACCESS_DENIED`](https://msdn.microsoft.com/en-us/library/aa374879) access control entry (ACE) in its discretionary access control list (DACL) that applies to a particular security identifier (SID). On the other side of the access checking process, a group SID such as `BUILTIN\Administrators` (`S-1-5-32-544`) can be attributed in an access token as [`SE_GROUP_USE_FOR_DENY_ONLY`](https://msdn.microsoft.com/en-us/library/aa379624), i.e. only apply access-denied ACEs that apply to the SID, while ignoring access-granted ACEs. Check `whoami /groups`. – Eryk Sun Jun 12 '15 at 14:29
  • @Aeron: yes, that's part of what "highest privileges" means. (In terms of the design goals of UAC, it's actually the most important part!) If you want to use access rights belonging to the Administrators group, you must be running with "highest privileges". – Harry Johnston Jun 13 '15 at 00:25

0 Answers0