I'm trying to set up a Windows service with the following requirements:
Runs as a domain account - this account has access to other shares that the process will touch
Has full administrative rights on the machine, past UAC - specifically needs to be able to take ownership of folders
The problem is that the process needs to take ownership of folders at some points, which is done by calling takeown /A /F <file>. This works on the command line, but only when it's explicitly Run as Administrator - being a local admin on the machine does not give full admin rights, and the account still has to go through the UAC prompt, so when running as a service we just get ERROR: The current logged on user does not have administrative privileges.. It seems like the standard way to get around UAC for a service account is to use the Local System account, but that isn't an option because then we can't access the other servers.
Is there any way to set up the service and say "Run as this account, in the context of a full administrator on the machine"? As another potential solution, is there a way to exclude a domain account from UAC on a machine? Any other solution could work as long as it runs as a service, can set folder ownership, and using a domain account. Ideally this is done without opening up big security holes, like fully disabling UAC on the machine.
I am not able to reproduce your problem. Here is how I tested.
Part 1: Create sample directory with non-administrator owner
Create directory C:\TestDir
Disable permission inheritance and copy inherited permissions into explicit permissions
Grant NT SERVICE\TrustedInstaller full control access
Set owner of directory to NT SERVICE\TrustedInstaller
Set Administrators and SYSTEM accounts to have read access
Remove access for all other accounts
After complete, verify that, logged on as elevated administrator, I am not able to create a file in that directory.
Part 2: Create a service that takes ownership of the directory
I did this using nssm (https://nssm.cc):
Create a short batch file, C:\scripts\TestService.cmd, containing the takeown command:
takeown /F C:\TestDir /A
Run nssm install and specify:
Application path: C:\Windows\System32\cmd.exe
Arguments: /C C:\scripts\TestService.cmd
Restart action: Stop service (oneshot mode)
Log on: Specify username and password of an account that's a member of the local Administrators group
stdout redirection: C:\scripts\TestService-stdout.log
stderr redirection: C:\scripts\TestService-stderr.log
I started the service, which executed the C:\scripts\TestService.cmd batch file. (The service stopped immediately after starting, which is expected in this case.) The standard output file C:\scripts\TestService-stdout.log contained the following lines:
C:\Windows\System32>takeown /F C:\TestDir /A
SUCCESS: The file (or folder): "C:\TestDir" now owned by the administrators group.
This experiment demonstrates that a service running using an account that's a member of the local Administrators group runs elevated (i.e., with full administrative privileges).
Related
I am trying to get some automatic deployments up and running using TFS 15 (on-premise). I have a powershell script on the deployment target to call.
The deployments starts fine by downloading the artifact. But when the agent runs the script it wants to create a folder C:\Windows\DtlDownloads (thats not part of my script but part of preparing things for TFS I guess). That fails:
##[debug]System.AggregateException: Failed to install 'VisualStudioRemoteDeployer20597940-38b2-4ba8-9a4d-fcc894308730' from service executable path VisualStudioRemoteDeployer.exe . Consult the logs below:
Access to the path 'DtlDownloads' is denied.
CategoryInfo :PermissionDenied: (C:\Windows\DtlDownloads:String) [New-Item], UnauthorizedAccessException
FullyQualifiedErrorId :CreateDirectoryUnauthorizedAccessError,Microsoft.PowerShell.Commands.NewItemCommand
The user used to logon is a server-local user named deploy who is also a local administrator on that machine. I also checked the effective access for that user on the windows folder and it should be able to create directories.
Something similar happens with the copy step. Robocopy signals two errors:
2017/03/16 08:57:21 ERROR 5 (0x00000005) Getting File System Type of Destination \\server.domain.com\c$\abc\def\
Access is denied.
and
2017/03/16 08:57:21 ERROR 5 (0x00000005) Creating Destination Directory \\server.domain.com\c$\abc\def\
Access is denied.
The second is a bit unexpected as the folder def already exists but I guess it is a follow up because getting the type failed beforehand.
The user itself must have been recognized because I get different errors when using invalid credentials. I have enabled WinRM using Enable-PSRemoting and ConfigureWinRM.ps1 from WinRM-Http-Https-Without-Makecert.
What could still restrict the permissions?
Update: Using a domain user instead of a local one of that server solves the issue. But I do not understand why. Can someone explain or even provide information how to make it work with a local user?
The username of either a domain or a local administrative account on
the target host(s).
Formats such as username, domain\username, machine-name\username, and .\username are supported.
UPN formats such as username#domain.com and built-in system accounts such as NT Authority\System are not supported.
Source Link
Both the domain account and local admin should be work. Please double check your format and give a try with another format.
One problem could be if that you have the agent as a service, that service has not the proper privileges, like being on Network Account. Try to change that to the user account which has administrative privileges.
Running "winrm quickconfig" fixed this problem for me
winrm quickconfig
https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management
I'm not sure if this is proper place for such question (maybe should be placed on SuperUser?), but I'll try.
I have one C# console application and one Windows service. Both does the same, but console app was created before and is kept for backward compatibility. Each of these is running WCF service, whose methods operates on files in C:\ProgramData\MyApp. Console app is run as limited user (non-admin), Windows service runs as NT AUTHORITY\NETWORK SERVICE. When app creates some dirs/files, service cannot delete it and vice versa.
I would like to have it secured. My question is: should I grant full permissions on C:\ProgramData\MyApp to NETWORK SERVICE and current user? Or should I create dedicated user for running service/app?
Assuming your application does not set explicit security permission on newly created files, granting Network Service account Delete permissions on the folder would solve your immediate problem.
This command will do the work:
icacls c:\ProgramData\MyApp /t /grant "NETWORK SERVICE":(OI)(CI)(IO)D
Repeat the same for your other user service account.
Is anyone successfully using MsDeploy for deploying windows services with a preSync runCommand? I've got it working using an Administrator account, but can't for the life of me get it working on a standard user account. Unfortunately I can't use integrated authentication (we're deploying to an external box), and the thought of our Administrator password sitting in plaintext in logs on our build server doesn't exactly make me feel too comfortable. For that matter, neither does any user credentials - but I can't see a way around that.
The command I'm using is this:
"tools/deploy/msdeploy.exe" -verb:sync
-preSync:runCommand="tools\Deploy\PreSyncCommand.cmd",waitInterval=30000
-source:dirPath="C:\BuiltSourcePath"
-dest:computerName=https://server:8172/msdeploy.axd?site=dummysitename,userName=service-deploy,password=service-deploy-pass,authType=basic,dirPath="C:\DeployPath\"
-allowUntrusted
with rules set up in IIS for the dummy site to allow the authentication for the service-deploy windows account, with contentPath and runCommand permissions (for the moment set to C:\ as it's not entirely clear whether this needs to be set to the temporary path that MsDeploy streams to, or the deployment path?). The service-deploy account also has full control of the target directory. I get the following back:
Performing '-preSync'...
Info: Using ID '7a7d34a1-b5d8-49f1-960a-31c9cf825868' for connections to the remote server.
Info: Using ID '4d0b910c-aca4-4640-84bd-3597d22d99d1' for connections to the remote server.
Info: Updating runCommand (C:\TeamCity\buildAgent\work\aec989676b349656\tools\De
ploy\PreSyncCommand.cmd).
Warning: Access is denied.
Warning: The process 'C:\Windows\system32\cmd.exe' (command line '/c "C:\Windows
\ServiceProfiles\LocalService\AppData\Local\Temp\giz2t0kb.0ay.cmd"') exited with
code '0x1'.
This happens even if the contents of PreSyncCommand.cmd is blank. The same command runs fine if I pass in Administrator credentials. I've tried using ProcessMonitor to check if anything's being denied access but can't see any - so I'm guessing it's still a MsDeploy authentication rule. There's nothing in WmSvc.log (debugging is enabled), nor in the event log.
Any ideas? Thanks!
Since you're using Web Deploy via WmSvc, you need to setup appropriate delegation rules on the destination server:
Within IIS Manager, open the "Management Service Delegation" feature. Add a new rule which at least specifies the runCommand provider. In the Run As section, choose Specific User and provide credentials for a local administrator account on that machine. This is the identity under which your runCommand scripts will be executed. Finally, the user which you're specifying for the destination dirPath provider needs to be added to the delegation rule.
That allows you to invoke a deployment using a non-privileged account, and yet have it executed on the target machine under administrative credentials.
More information on IIS feature delegation: http://learn.iis.net/page.aspx/516/configure-the-web-deployment-handler/
I'd like to write a service (that starts up and runs whenever the machine is on) that queries Active directory since the user IIS uses does not have permission to query AD. How do I determine if A) my workstation where I have local admin rights, and B) a shared team workstation will allow me to do this?
Anything you can do as an interactive user can be done by a service with appropriate permissions and configuration, so it isn't so much an issue of determining if you can, but rather configuring the service so that it can.
Your installation package should request an appropriate set of credentials (and of course must be run by a user with privileges to install such a service). The service itself should simply catch and log any permission exceptions.
As an example - look at the SQL Server installation process. Early on it requests that you specify accounts with the required privileges.
I have an application that runs as a service, and dynamically creates and publishes windows performance (perfmon) counters.
When I run the application under my own account (as a service) which has administrative privileges, I get the following error:
714: The specified registry key is referenced by a predefined handle.
When I run the application from the command line, no error is produced.
I believe that this is a result of UAC, but I don't particularly want to disable UAC altogether.
Any ideas?
It is not enough just to be logged in as an administrator. The service needs to have an embedded manifest that sets the requestedExecutionLevel to requireAdministrator.