I have a service application that supports both start as service and interactive mode. The service I register is executed as the NetworkService user; the interactive mode is running as a computer administrator (normal users have no access to the program).
Now, some resources (e.g. files) are only available to the user NetworkService. Can I somehow tell the program to run the code as NetworkService, even if started by an administrator?
Now, some resources (e.g. files) are only available to the user NetworkService. Can I somehow tell the program to run the code as NetworkService, even if started by an administrator?
NetworkService is a low privilege account. Administrator is a high privilege one. Having a situation where files are available to NS but not do admin is somewhat unusual. While is true that an admin has the right to impersonate most accounts (WindowsIdentity.Impersonate(), see Hans link for NS impersonate issues), I would revisit the situation and make sure this is actually necessary. It is much more likely that the files in question can, and should, be ACL-ed differently so that both NS and Local Administrators have access to the file.
Also consider splitting the application into a service component, always running as service, and a UI component that the administrator can invoke. Have the UI communicate with the service over some protocol, eg. via LRPC or shared memory of even HTTP.
In general you can change permission for file if you have Administrator rights.
Or start code as NetworkService account with help PsExec.exe like described here
Related
Currently i'm busy creating an application for an Siemens IPC. No problems with the application itself, but some difficulties with elevating the application to "Administator"
We need to have administrator rights to set PC date time, and we use a manifest to elevate the application to administrator.
No problems so far :)
But my problem lies in the fact the "normal" use is an operator which has limited access on the UAC, so i need to provide my administrator credentials to succesfully elevate the application.
I need this to happen automatically at startup, but the windows system does not allow me to use a startup schedular task of windows to run the program with the correct credentials.
Is there any other way to achive to run the application with administrator rights, without having to fill in the UAC credentials?
Thanks in advance!
So the problem here is that I'm using ClickOnce to create an internal application that co-workers can install once and I can push updates by publishing. The problem is that ClickOnce doesn't jive with my need for administrator privileges; it won't publish if I have that requirement declared in the app.manifest. The reason that I have that in there is that I need to be able to edit the host file which is in system32/drivers/etc. Most other threads I've read say that the most I can do is run asInvoker so that the app can inherit all of the permissions that I have as a principal user on the domain, but I found this to be a bit inaccurate. You see, my user has permissions to edit the host file, but my principal does not possess the administrator role. So my question is this...
How can my ClickOnce app request/gain permission to edit the host file? As an aside -- the applicaiton will also be doing some minor registry editing. Alternative approaches are welcome.
As jvanrhyn alludes, the official policy is that ClickOnce applications cannot request administrative elevation if User Account Control (UAC) is enabled (as it is by default on Vista and later). Like you've discovered, if the manifest file sets the requestedExecutionLevel attribute to requireAdministrator, the application will fail to install and run.
This is a security precaution. The whole purpose of UAC is to minimize the risk of applications making unauthorized changes to system settings, which could compromise system integrity. The whole point of ClickOnce is to make deployment of applications fast and easy. Clearly these are two contradictory goals.
Again, the official stance is that if your applications requires administrative privileges, you should be deploying it using Windows Installer or some similar utility.
However, since as far as I understand your question you only need to have administrative privileges on first install, there might be a workaround where you can continue to use ClickOnce for deployment. You would keep the application's requestedExecutionLevel at asInvoker so that it would run under normal circumstances with standard (unelevated) privileges and would work with ClickOnce. But you would also have a secondary application that did require elevation. Your primary application would then launch this secondary application on demand (e.g., on first run), causing the secondary application's privilege demands to kick in, and thus prompt the user for elevation. That second application would run elevated, make the changes that it needed to make, and then quit. The primary application would continue to run un-elevated, and could be launched thereafter without requiring administrative privileges.
This is keeping with the spirit of the security precautions, since it minimizes the need for applications to run with administrative privileges. You can include the secondary "helper" application as a delivered resource in the ClickOnce application, and it can then be launched from the ClickOnce private storage area.
I have an app of mine that I need to distribute to 5000 computers on my business domain via SCCM and i'm having problems with the windows security. The point is that my app requires administrative rights to access to registry keys and launch some "specific" featues on the local system and all the users on the domain (except for the IT support team of course) doesn't have such privileges.
I was wondering that I could make windows call a launcher on startup next, this launcher would get admin username and password on the app's server and then run the app with those credentials. But i'm having difficulties performing this task once i'm new on C# (i'm a java programer) and i haven't found any way of using the runas command with both username and password information.
Other point, it would be perfect if i could make use the admin privileges without the anoying windows UAC prompts.
Can anybody help me?
I'm not sure about what I'm going to say, but just did a bit of research that may help you.
You can try to schedule a task to run your program, and config this schedule to run it with admin rights, at startup.
Scheduling a task
Then the only thing left you need to look for is how to program easily this task for all your computers.
Hope this helps you
If your application must be run as an administrator in order to operate correctly: then tell Windows that:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
So that if i'm a standard user (i.e. not an Administrator), and i try to use your program: i will be prompted to get an administrator to come to my desk and enter their credentials so i can run your program.
The downside of your program only functioning with admin privileges is that a standard user cannot run your program.
And you could try turning off UAC; but that doesn't fix anything. UAC is a quality-of-life feature.
if i turn off UAC
i'm still a standard user
except now i have to logout and login as an administrator
The correct solution is to let your program work as a standard user.
I've been asked to write a C# application to run on a Windows 7 machine to display the time of day, weather, etc.. That I can do. What I'm looking for is guidance to run the application on a Windows7 machine without logging as a user. In essence the machine would simply be a CPU with a screen. No keyboard or mouse. I've seen deployments done on MS-PixelSense (use to be MS-Surface) using a service ID.
If I need to signin, user policies kick in, screen savers enable, etc.. I'm assuming if I use an automatic Service ID, I can let the application override most of the settings keeping the screen on and needed privileges assigned / locked down to the service ID.
Any information / suggestions are appreciated....
First, some background informations:
Accessing a network share
If a process running on your client wants to access a (CIFS) share, it has to be run under a user account (or "Service ID") which has access rights to this share. There is a way (if the client is a member of Active Directory) that the machine name appended with $ (which is in fact the machine account’s name in AD) has to be entered in the ACL (Share / NTFS), but this is not a very "usual" way.
See also https://serverfault.com/questions/41130/network-service-account-accessing-a-folder-share
Windows Service running under a user account (aka technical account or Service ID)
A service running under a user account cannot access the GUI. There are some tricks, and some years ago I wrote a tool which allows a service to start another GUI program, where the GUI is displayed above the Ctrl-Alt-Del dialog. But this does not work under Windows 7 anymore.
But even a service which runs under local system cannot display a GUI on the logon screen.
You would have to write a Credential Provider.
See
Windows service showing a GUI when no user is logged in
https://stackoverflow.com/a/3074040/4547223
Another very deep technically article. It says it is possible to display a GUI on the secure desktop / logon screen. I have not yet tested this myself:
http://calebdelnay.com/blog/2012/01/displaying-a-program-on-the-windows-secure-desktop
Autologon
The most well known way is still the "classic" autologin.
See https://security.stackexchange.com/questions/10170/how-secure-is-windows-auto-logon for some explanations and links.
The medium secure way is to store the password as LSA secret (can be done in C# with P/Invoke or with some tools).
If I need to signin, user policies kick in, screen savers enable, etc.
Yes, but this can be handled, you probably have to create an own AD OU with an own policy for that.
I'm assuming if I use an automatic Service ID, I can let the application override most of the settings keeping the screen on and needed privileges assigned / locked down to the service ID.
A service ID /technical account is basically the same as a normal personal user account.
In some Active Directory enterprise environments a technical account has restrictions that it cannot log on interactively and other restrictions. But it still IS a "user account"
Logonexpert (http://www.logonexpert.com/)
I tested this (trial version). It is a nice, small tool which does it’s job. It is more safe than "normal autologon", however in the end, it is not much different from normal classic autologon. One benefit: it stores the password more recurely, but in theory, some hacker may still decompile the program and find out a way to decrypt it. And more important for you: Beside the more safe password store, it does not gain you much. You still have a user login same as normal autologon.
A few suggestions
Probably you can use a local user account on the client system and use normal autologon mechanism. And then you should consider that the client system does not poll for new data on a network share, but instead another server program (implemented as a service, running under a technical domain account) pushes data on a network share on the client.
Doing it this way, the client code does not need to access network shares, with the benefit, that a malicious attacker also has no access to network shares.
If you really need to access a network share from the local user context, you can probably logon to the server, as explained in my answer here:
https://stackoverflow.com/a/28749093/4547223
You have to to change the registry code part with the access to the CIFS share.
But doing it this way, you again have a password, which you have to encrypt and store. I do not recommend this.
In the end...
Windows does not make it easy what you want to do. If you are not strictly bound to Windows, you can consider using a Raspberry Pi with Raspbian (a Debian derived Linux). You can install Chromium browser, which displays a web page on the server and updates automatically. We use this with great success for some time.
At my company we have a product which pretty much interacts with everything you can imagine... registry, databases, devices, etc... it is composed of many parts but the entire application is launched by a single executable (start.exe) which is responsbile for launching everything else - this is all legacy code and run under a USER account.
Currently this is launched as a STARTUP item (or by double-clicking on the desktop icon) in Windows, meaning when the user logins into the USER account the application (start.exe) automatically kicks off, under this account it has all the permissions it needs to run and everything has been fine for years...
Now comes the change - I have written a service (Serv.exe) that is running as LocalSystem - this service is responsible for updating the various software components of our product and works as follows:
- when the product detects an update it signals the LocalSystem service (Serv.exe) and then terminates itself
- Serv.exe will then perform all the updating
Now, after everything is done, the product (via start.exe) needs to be launched again automatically ... and this is where I need some advice ... what is the best way to restart the product (start.exe)?
Right now I use the LocalSystem Service (Serv.exe) and impersonate the USER account as follows:
- CreateEnvironmentBlock for the USER
- CreateProcessAsUser(start.exe) as the USER with the corresponding EnvBlock
- DestroyEnvironmentBlock
But is this really 100% equivalent to double-clicking on the icon in the USER account context? I need to ensure that everything is identical when it is either launched on STARTUP of USER or by Impersonation from Serv.exe (LocalSystem) - is there a risk involved? Will I still have the same rights/abilities with all databases? registry? device interaction? etc..
By loading the EnvBlock I seem to get everything I need but ... is this not a good way to do it...?
Kind of hoping for some guidance and advice from the pro's out there ...
Any help or hints would be much appreciated.
Thanks,
Update: Here is a post named: Launching an interactive process from Windows Service in Windows Vista and later. Which is exactly what you are looking for. It starts with:
The first thing you should do about it is that; don't do it. There are many limitations and bad implications and restrictions involved.
So first test if your current solution works. That depend on what the process is doing. If it is not involving user interaction. Or manipulating the current user session. Then you don't need this complex solution. If you need it, than good luck!
Before update: Its not 100% equivalent. Except authorization there are, in windows, sessions and, in each session, there are desktops. The process that is lunched from the service will run on the service session and desktop ( if the service has it). Depending on what the start.exe does, it may be important or not.
Look at the SetTokenInformation function.
Instead of launching the application directly as a "startup item" you could start a "launcher.exe" that then would launch your application. The service could then signal "launcher.exe" that another instance of the application should start after an update. Using this method you can't use the service to update "launcher.exe", but this executable should be very simple and hopefully not require any updates. Using this method would avoid all the pitfalls of trying to start an interactive application from a service.