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
Related
I have a PHP script that runs a Powershell Stop-Process command through shell_exec(). PHP runs as IUSR. When I run the script, I receive an access denied error message. If I run the command in PowerShell using my Administrator account, it works as expected.
How do I grant IUSR the ability to execute Stop-Process in Powershell?
I wasn't able to find a solution to grant IUSR the specific privileges to execute Stop-Process, but I was able to get around this by changing the "Anonymous Authentication" user associated with the kill script from IUSR to Administrator.
In IIS 8.5, go to Sites->My Site->Folder Name. On the main panel, click on Authentication under IIS. Right click on Anonymous Authentication and then click on Edit.
You can set the "Anonymous Authentication" value at any level of your IIS app; from the site level to the sub-directory level. I recommend only changing the value from IUSR to Administrator on the directory that actually hosts your kill script. Changing it for the whole site might create problems for other parts of the application.
I've seen some information that suggests if you add a limited user to the Performance Monitor Users group and grant it debug privileges, it will be able to terminate processes.
You might consider something a bit less risky though, like running another web app as a user with those rights, that can only be accessed from the local machine. Then make your PHP app do a web request to the internal app to do it's killin'.
If you're trying to kill only a specific process this lets you further limit the impact because the internal app could be designed to only kill that one thing.
Other ways to achieve a similar separation is to have for example a scheduled task that looks for a file with specific content in a specific directory, when it sees it, it kills a process and deletes the file. IUSR can be given permission to create files in that directory as a way to trigger this. This method is very easy to implement but isn't synchronous.
I have a script on my domain stored on the Active Directory server. every machine on the domain has a task that when fired, calls this script to run.
Running the task from the AD server works. Running the task from another machine doesn't work. However, running the command that is triggered from cmd manually on the remote computer works?
Could anyone shine some light on this. Basically I call it like this so that the trigger is set up like...
Action: PowerShell.exe
Arguments: -noprofile –ExecutionPolicy Bypass -File "\\<>NameOfADServer<>\C$\Tasks\script.ps1" "Argument 1" "Argument 2"
Running as SYSTEM is probably your issue - it wont have any access outside of the PC its running on.
When you run it manually youll have the access.
There's several problems here.
You're running the task as the local SYSTEM accounts. SYSTEM generally does not have access to any network resources.
You're using the administrative share (\\<servername>\C$) to share the script. Only users that have Administrator access to the server can access the administrative shares. Administrative shares are heavily restricted by design and you cannot modify the access on them.
My guess is that the script works when you run it manually is because it's using the current user's credentials for network access when you do that, but don't quote me on that.
The simplest solution with the least amount of change is to do this:
Create a group in Active Directory. Add the Computer accounts, or, preferably, groups with Computer accounts which you want to be able to run the script to this new group. If you really want any SYSTEM account on any computer in the domain to be able to run the script, you can add the "Domain Computers" group to the group.
Create a folder on the server. Put the script in the folder. Don't put anything in this folder you don't want your users to read. Assign the "Read" NTFS permission to the group created above to the folder.
Share the folder out. Grant the group you just created the "Full Control" share access. If you want, you can make it a hidden share by adding a dollar sign to the end of the name.
Update your scheduled tasks to use \\<servername>\<sharename>\script.ps1.
This is almost certainly not the best method to accomplish what you're actually trying to do, but this is probably the best way to use scheduled tasks running scripts on a network share with the SYSTEM account.
First of all, I realize this is a messy situation, but it's not of my design, and I'm just trying to help, and for that I need your help.
App A is getting installed automatically via SMS installer under the Administrator account, not the PC owner's User account. App A has a registry key defined in HKEY_LOCAL_MACHINE hive.
After App A is installed, we want to edit the above mentioned registry key, to assign the User's C:\Users\USER_ID\Documents\ folder (I'm told we don't don't know who the user is and don't have access to USER_ID during step 1).
I know all about UAC, Application Manifest, and requestedExecutionLevel. However, I'm told we can't expect that all users will be in the Administrators group on their machine.
Solution must be backwards compatible with Windows XP as well.
I'm searching for options to get `C:\Users\USER_ID\Documents\' into the 'HKEY_LOCAL_MACHINE' hive under the above listed conditions.
I found this thread that might be related to a similar situation, but I don't fully understand it yet (so I will give credit to anyone that explain it better):
Find out (read) logged in user in a cmd started as a different user
I also read something that rules out ClickOnce:
Clickonce + HKEY_LOCAL_MACHINE
After App A is installed with admin privileges you are trying to run an additional script as the local user who does not have admin privileges . In order for your secondary script to write to the local machine key it will have to be run with administrative privileges ..period. That said, you have basically two choices:
1) Use the RunAs command to run the script with elevated privileges and have the user type in a admin username and password to run the script with elevated privileges.
2) This is the better way imo - Since SMS is being leveraged as the delivery tool, use its capability to detect and use local client configuration settings to write the key at the time of installation.
So basically the SMS package would have to be setup to run only when the local user logs on one time so that SMS can grab the current user and write it to a file somewhere.. after that is completed SMS can run a separate package as the admin (user will get prompted) to do the software install looking for the file containing the user and then consequently updating the local machine key to the correct user my document path.
Enjoy!
I've got an important resource folder (that can not be embeded in exe file) and I want to limit access of all Windows users except Admin Group ones. My program runs in normal (not Admin) user and I want give resource folder access only to this process. I can ask Admin user's password once, but I don't know is it possible or not?
You can start an elevated rights process from you application, do whatever is needed with admin rights and end it after.
Take a look here: http://victorhurdugaci.com/using-uac-with-c-part-1/
Does anybody know what user privileges are needed for the following code needs to successfully execute as a scheduled task on Windows Server 2003:
System.Diagnostics.Process.GetProcessesByName(Process.GetCurrentProcess().ProcessName)
When NOT running as scheduled task i.e. under a logged in user, as long as the user is a member of "Performance Monitor Users", this code will not throw an exception.
When running as a scheduled task under the same user account, it fails.
The only way I can get it to work is to run it as a member of the Local Administrator group.
Any ideas?
My humblest apologies. The user I was using was NOT a member of "Performance Monitor Users" group.
This is necessary for .NET Framework 1.1 implementation of System.Diagnostics.
I have added the user to this group, and all is well.
What user rights assignments have you given the account that is running as a scheduled task? You'll need to give the account in question 'Log on as a batch job' in your local security settings.
Update: Does your app write to any files and if so does the scheduled task user have enough rights?
I just knocked up a test app that writes the process names from the Process[] array returned by Process.GetProcessesByName(Process.GetCurrentProcess().ProcessName) to a file and it works just fine as a scheduled task...even running under the identity of a user that is only a member of the Users group (not even a member of 'Performance Monitor Users'.
The folder it writes to is assigned modify rights to SYSTEM, Administrators and the scheduled task user.
Any chance of pasting your code or at least a small enough snippet that demonstrates the exe failing as a scheduled task so we can help diagnose the problem?
Cheers
Kev
One issue that I have seen with reading the process name is that access to the performance counters can get disabled.
Crack open your registry and see if this key is there:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance]
"Disable Performance Counters"=dword:00000001
You can either set it to zero or deleted it.
Taken from MSDN:
Permissions LinkDemand - for full
trust for the immediate caller. This
member cannot be used by partially
trusted code.