Develop Reference

Programmatically grant local user rights to start a service with .Net

I want to implement an update service in my application (so users don't need admin rights to update my app once the service is installed, much like Google or Mozilla do their updates), and I think I found a good way to do this with WCF.
I have a WCFServiceLibrary-Project which contains the ServiceContract and the core functionality (download/install updates) and a Windows Service-Project which implements the WCFServiceLibrary as a Windows Service.
Additionally, there is a Visual Studio Installer-Project which installs the service and my application, which should be able to start/stop/communicate with the service using NamedPipes.
The service is configured to start manually with the LocalSystem-Account.
Now when the service is installed, I can start/stop it using services.msc (probably elevated), but not when I try it with net start Servicename (Error 5: Access denied) or with my application, which tells me that the local users probably don't have the permission to start/stop the service.
I need the service to run with higher permissions in order to perform the installation of updates, so I would like to give local users permission to start my service either during the first installation of the service or when the service starts for the first time (since I can trigger that also during installation).
However, how would I accomplish this with VB.NET (or C#)? I found some examples using API-Calls of advapi32.dll, but it didn't looks like the permission can be changed with this.
So, long story short, heres a summary of what I'm looking for:
Grant Group "Local Users" permission to Start my Service, best approach either during installation (Maybe with Custom Actions in Visual Studio Installer Project? Or in the ServiceInstaller-Class in the Windows Service-Project?) or the first time the service starts (OnStart-Event in Windows Service Project)
The service must not run with local user rights, since it would miss elevated privileges then which would be necessary to install updates.
I can't assign permissions through GPO/Local Policy since the users are not within our company, but all around the world. For the same reason I cannot assume that they can get an admin to elevate them everytime an update comes out.
I would like to avoid commandline calls if possible (as in assign permissions through command line, since those are most likely os-dependent)
Another solution would be to configure the Service as Automatic and Start it after install, but I don't like the idea that my service runs all the time since its only needed when my main application starts up.
Its most likely not a file permission issue. EVERYONE, SYSTEM and SERVICE got FULL ACCESS to the services folder and files in it.
There are already different similar questions here, but none did give a clear answer to this problem. One user probably did it using the WiX-Installer, but I would like to keep the Visual Studio Installer Project since it's pretty straight forward and easy to use.

After a bit more of googling and trying to find a "clean" solution, I've given up and using now Process.Start to execute sc.exe and set new Permissions after Installation.
Here's my ServiceInstaller-Class, for anyone curious:
[VB.NET]
Imports System.ComponentModel
Imports System.Configuration.Install
Imports System.ServiceProcess
<RunInstaller(True)>
Public Class SvcInstaller
Inherits Installer
Dim svcprocinst As ServiceProcessInstaller
Dim svcinst As ServiceInstaller
Public Sub New()
svcprocinst = New ServiceProcessInstaller
svcprocinst.Account = ServiceAccount.LocalSystem
svcinst = New ServiceInstaller
svcinst.ServiceName = "KrahMickeySvc"
svcinst.DisplayName = "Mickey-Service"
svcinst.Description = "This Service is used by KRAH Mickey for application updates and maintenance"
Installers.Add(svcprocinst)
Installers.Add(svcinst)
End Sub
Private Sub SvcInstaller_AfterInstall(sender As Object, e As InstallEventArgs) Handles Me.AfterInstall
'Set new permissions acc. to Security Descriptor Definition Language (SDDL)
'Source: https://blogs.msmvps.com/erikr/2007/09/26/set-permissions-on-a-specific-service-windows/
'Keeping the source DACL and just adding RP,WP and DT (Start/Stop/PauseContinue) to IU (Interactive User)
Dim DACLString As String = "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRCRPWPDT;;;IU)(A;;CCLCSWLOCRRC;;;SU)"
process.Start("sc.exe", $"sdset {svcinst.ServiceName} ""{DACLString}""")
End Sub
End Class

Custom Actions Installer for Windows Service

I have a windows service which I silent install using msiexec.exe and I am passing the username and password for the "Set Service Login"
The Service is successfully installing but upon Starting the service I am receiving "error 1069: The service did not start due to logon problems"my logon account is administrator and I have tested that when I manually install using the same msi file and start the service it is starting successfully, I am stuck and need some ideas and guidance of what I am missing.
here is my overriden method from Installer Class.
public override void Install(IDictionary stateSaver)
{
base.Install(stateSaver);
var userName = Context.Parameters["USERNAME"];
var password = Context.Parameters["PASSWORD"];
if (!string.IsNullOrWhiteSpace(userName) && userName.ToLower() != "admin")
{
CustomInstallerParameters customParameters = new CustomInstallerParameters(Context);
SaveCustomParametersInStateSaverDictionary(stateSaver, customParameters);
}
else
{
Context.Parameters.Remove("USERNAME");
Context.Parameters.Remove("PASSWORD");
}
}
TIA.

It appears that you are using a Visual Studio setup project, and most likely also using one of the TextBoxes dialogs to collect the input.
You can't silently pass these parameters on the command line because Visual Studio generates custom actions to clear them (and I don't know why). In a silent install Windows runs just the InstallExecuteSequence, and if you look in there with (for example) Orca you'll see custom actions such as "CustomTextA_SetProperty_EDIT1" that clear the values. To state the obvious, the values you currently get will be blank, and you could verify this by logging the values somewhere.
So a starting point to getting this to work is to use Orca to delete those custom action calls in the InstallExecuteSequence table.
After that, there is a potential problem that the values won't make it to your custom action because they are not secured, so in the Property table you'd need to add those property names to the SecureCustomProperties list, semi-colon delimited (EDIT1;EDIT2 and so on).
Visual Studio setup projects aren't good at any of this, and something like WiX would be better because no code is required to install, start or stop services, or configure them with an account.

Most likely, different decade, same problem.... (SeServiceLogonRight)
http://iswix.com/2008/09/22/different-year-same-problem/
FWIW, I wasn't a big WiX user yet back then (I was merely dabbling at that point) but there are some real gems in the comments from my Matthew Rowan. He is correct... all of this gets WAY easier if you are using WiX.
For example you can follow this tutorial:
https://github.com/iswix-llc/iswix-tutorials
This creates a windows service running as SYSTEM. Add a reference to the WiXUtil extension and namespace and author a User element with the LogonAsService right set and your all set.
FWIW, my only concern with all this is that MSI needs property persistence if you don't want a repair to come by and corrupt the username and password. Property persistence is pretty easy to remember ( See: http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/ ) but the problem is providing enough encryption to not expose the account.
It's for the reason I typically suggest just running as NetworkService or SYSTEM and grant the computer object rights in a domain. An alternative is to have the installer create the service account and randomize the password on each repair so you don't have to persist it.

Get current user name when starting with UAC

Our setup has an embedded manifest that triggers the UAC before the application starts. (The applications runs as an admin user). However, if the setup needs to install the .NET Framework, we have to continue the setup after a reboot. For this reason, we have to create a registry key in the current user's RunOnce.
Unfortunatly, HKEY_CURRENT_USER points to the Administrator's registry. We need to find out the user that is currently logged in and started the installation. (Th normal USER clicked the setup.exe, an ADMIN entered his details in the UAC prompt. We need to find out who the USER was)
I've tried all the usual methods (Environment.UserName, WindowsIdentity.GetCurrent())
Thanks!

You can use the LsaEnumerateLogonSessions function to retreive what you need. However, it is a winapi C function call. If you need a managed version of it, I belive you can look at the source code for Cassia, which uses this function in its terminal services API. The call should be the same. You can also look here.
Also you can use the NetWkstaUserEnum WINAPI function. You can find a managed wrapper for it here
With Cassia library this code works fine:
ITerminalServicesManager manager = new TerminalServicesManager();
ITerminalServicesSession session = manager.CurrentSession;
string userInfo = session.DomainName + "\\" + session.UserName;
NTAccount account = session.UserAccount;

Run your initial setup.exe as a small executable that puts up a splash screen while invoking your real setup program as a child process. The small EXE is not run as admin and can pass the logged in user name to the child process. The child process invokes UAC and runs in the admin context but already has the logged in username as a command line parameter.

It is not possible to retrieve the original user if your application is ran as Administrator:
If a user launches Setup by right-clicking its EXE file and selecting
"Run as administrator", then this flag, unfortunately, will have no
effect, because Setup has no opportunity to run any code with the
original user credentials. The same is true if Setup is launched from
an already-elevated process. Note, however, that this is not an Inno
Setup-specific limitation; Windows Installer-based installers cannot
return to the original user credentials either in such cases.
Source : InnoSetup Help
As said by Matthew in comments, you should not run your application as Administrator but only trigger UAC when needed in your code.

This returns the name of the logged in Windows User by stripping out the domain:
using System.Security.Principal; // here is the security namespace you need
...
string userName = WindowsIdentity.GetCurrent().Name.Replace("\\", "|");
string[] split = userName.Split(new Char[] { '|' });
lblDebug.Text = (split.Count() > 1) ? split[1] : userName;

c# interactiveProcessRunner

Can someone tell me what the InteractiveProcessRunner is for? Is it identical to Process.Start?
Here is the class.
And here an example :
InteractiveProcessRunner runner =
new InteractiveProcessRunner(notepad.exe,hSessionToken);
THX

Whit this class you can run a process with the complete environment of the user active: if you call this code from a service, you should find the user mapped resources, the desktop and all the resources that are available when the user is loggen on interactively even if launched from a service ie not logged interactively.

The source code to which your link leads referes to this article: http://asprosys.blogspot.com/2009/03/perils-and-pitfalls-of-launching.html which explains the motivation behind it.
Summary: You can't really use Process.Start() when you want to start a new process as certain user from a windows service. The InteractiveProcessRunner lets you do this (supposedly, never used it so I can't verify it). So it's not the same as Process.Start() - it uses a different Windows API.

Execute PowerShell as an administrator from C#

I have the following C# code
using (RunspaceInvoke invoker = new RunspaceInvoke())
{
invoker.Invoke("Set-ExecutionPolicy Unrestricted");
// ...
}
which gives me the exception
Access to the registry key
'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell'
is denied.
According to this, the solution is to start PowerShell as an administrator.
Ordinarily, this can be accomplished by right-clicking PowerShell and selecting "Run as Administrator". Is there a way to do this programmatically?

I know this is an old post, but we ran into this same problem recently.
We had to scope the execution policy on the machine running the C# code by running the following from PowerShell...
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted
When we had done this previously, without scoping, we were setting the execution policy for Administrator. Visual Studio \ C# was running as the current user, causing it to fail with insufficient permissions.

Check this out
You need to impersonate as an administrator to do it (you will of course need administrator credentials)
Check that article, that also comes with code ready to use (I've used it and it works great)
Basically, you need to do this:
using ( new Impersonator( "myUsername", "myDomainname", "myPassword" ) )
{
using (RunspaceInvoke invoker = new RunspaceInvoke())
{
invoker.Invoke("Set-ExecutionPolicy Unrestricted");
}
}

Administrative privileges are at the application level. The app that needs admin access in this case is yours. Creating runspaces in C# in a custom app does not invoke powershell the application - it just loads some assemblies into your application.
That said, you can elevate as the other poster said although embedding admin usernames and passwords into source code make me feel ill.
-Oisin

I think an alternative model would be to wrap the powershell executor into a simple asp.net webapi webservice.
The webservice could then be configured to run with the required permissions needed to do it's job. It can provide it's own security to determine which clients can call it.
To execute a script, you would just call webservice methods. You could make the method quite general - script name and params.
It's a bit more work, but a lot more secure (see x0n's thoughts).

Strictly for DEV environment
This is relatively very old post.
But I have found a new way to do this.
I am hosting the C# web api on IIS 8 having some powershell code that I want to run with administrator privileges.
So I provided the admin credentials in the Application pool identity setting.
Just set administrator account in app pool identity.
Hope this helps to anyone. :)