I am trying to run my c# exe as an system account. How can I do that. I've tried <requestedExecutionlevel level="requireAdministrator"> and <requestedExecutionlevel level="requireSystem"> The administrator is working but the second one is not working.
Please help me how can I do this.
To the best of my knowledge you can not force your app to run as SYSTEM. Either your app must be a service and the service is setup to run as System or you must use a tool like PsExec to launch your executable as system.
psexec.exe -i -s YourProgram.exe
When using requestedExecutionlevel the only 3 valid options are
requireAdministrator - prompt for UAC always (even if the user is not an administrator).
asInvoker - never prompt for UAC.
highestAvailable - prompt for UAC if the user is a member of the Administrators group but do not prompt and run as a normal user if the user is not a member of the group.
It's not directly possible. There are hacky ways if you are an administrator (like getting the security token from an already running service or something), but I far from recommend using those.
The point of the SYSTEM account is precisely that: that it's only run directly by the system.
If you want an easy-hacky-way without third-party tools (like psexec), you could set up a ONEEVENT scheduled task (with schtasks, which is part of the OS), which can indeed run with the system account. This would still need two processes (although it could be the same exe with different command line parameters for the task and for setting it up), but it'd work.
Related
I have written a small program in c# that helps with switching between licenses for my company. It's a tray icon with a menu with the different choices.
It changes an environment variable and needs to have elevated rights in its manifest.
This means that the UAC warning shows up every time the program starts, which is not ideal because it would be really nice to have the program on autostart when Windows starts, without the warning showing up all the time.
Are there a good way to do this?
Is it possible to:
Run the program without elevated privileges and only get the UAC
warning when I call the function to change the variables.
Change the
environment variables without admin rights.
Add the program to a "white list" programmatically (although more realistic, add it manually)
I know the UAC is there to protect from malicious software, but it would be really nice to solve this in a way that enables me to start the program at Windows start.
I haven't been able to fine any silver bullet on this problem.
Any advise?
The normal way around this is you have a windows service that runs with system privileges that will set the environment variables for you.
You will need to have your installer install the service and set it to auto start. Then your tray application will need to communicate with the service with some kind of Inter-Process Communication (like WCF), the tray program can then send the requests to change the variable and the service can execute those changes.
Another way to handle this is start your program un-elevated then when you need to do something that requires UAC privileges you launch a new copy of your program as an administrator and pass in command line arguments that tell it to do the work you need done then exit. You also could have your program check to see if it is an admin, and if it already is elevated it could skip the step of starting the new copy.
What you need to do is move the license information to a location that all users can write to:
user's own environment variable
%CSIDL_COMMON_APPDATA% (e.g. C:\ProgramData, which all users can write to)
HKEY_CURRENT_USER
The ideal solution involves writing to a common machine-wide location:
%CSIDL_COMMON_APPDATA% (e.g. C:\ProgramData)
HKEY_LOCAL_MACHINE/Software/Contoso/License
C:\Program Files\Contoso\License\license.txt
Legacy software can't be changed
But assuming there are many existing unchangeable applications that cannot be altered to look anywhere else but an environment variable for license information you can (after you smack that guy who designed that):
write the license information to the user's own environment variable
Your switching tool will call:
SetEnvironmentVariable("ContosoLicenseInfo", "V2h5IGFyZSB5b3UgZGVjb2RpbmcgdGhpbmdzIHRoYXQgZG9uJ3QgYmVsb25nIHRvIHlvdT8=");
What would you have done under Windows XP
All this hand-wringing about UAC. You have to ask yourself:
What would I have done under Windows XP?
Without UAC, and the user running as a standard user, what will your license switching tool have done?
would have it crashed horribly on startup?
would it have crashed as soon as the user tried to use it?
would it have failed in a polite way?
would it show a message on startup saying: "Sorry, no."?
What would you have done under Windows 7?
Even better, you have to ask what you would have done for a user running under Windows 7? A standard user logs in, and you have a program in their startup group that claims to require administrative privileges.
The user needs to go get an administrator during login to run your tool? That's not going to fly.
If you're dead set against using a per-user location.
If you're dead set against using a common location that all users can write to
Then change your tool to run without needing user privileges.
Only when the user goes to do something do you need admin privileges.
Check if the user is an admin:
Boolean IsUserAnAdmin()
{
PSID administratorsGroup;
administratorsGroup = AllocateAndInitializeSid(SECURITY_NT_AUTHORITY, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0);
Boolean result = CheckTokenMembership(0, administratorsGroup);
FreeSid(administratorsGroup);
}
If they are an admin, you can perform the action as in.
If the user is not an admin, then you put the UAC shield on the Apply button.
You then re-launch your tool as an admin:
ShellExecute("runas", "C:\Program Files\Contoso\LicenseSwitcher.exe", ...); //the "runas" verb triggers elevation
But what would you do under Windows 7
None of the UAC stuff works if UAC is disabled. In that case: you are a standard user, and that's it.
In that case, it really is best to convert to:
machine wide location for the default license
per-user location if you want to choose your own
UAC is there to protect the Windows User by alerting them (and requiring an explicit action) that a particular application is requesting elevated permissions. If it was possible to bypass it from with the application itself them it would leave it a little pointless :)
I would assume that you are looking to change environment variables globally because I believe that you can change them for the current process without being elevated.
I have a console application that was developed to be called by a erp software.
They call my app inside the erp and when they do it, i always get errors related to the insufficient permission to do it.
I have checked the "run this program as an administrator" checkbox in the properties of the exe for all users but the result is the same.
I have read something about adding a manifest that will make the app prompt for the uac dialog, but thats not what i want because the app will be called from erp on the server and clients will not see the dialog on server.
Can someone explain me how to make this console app always run as administrator?
Add into your project Application Manifest File (Add -> New Item -> General -> Application Manifest File) and add the below node into the app.manifest:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
http://msdn.microsoft.com/en-us/library/windows/desktop/bb756929.aspx
First, understand that there WILL BE a UAC dialog at some point in this process. There is no way to avoid it. There are a few approaches you can take:
Have the people run the ERP software elevated. I am including this only for completeness. It is awful to have to consent to the UAC prompt every time you run the app when you usually don't need the powers. It would be a handy quick test, though, for you to confirm that if your app is elevated, things will work. Everything launched from an elevated process is elevated, so if your app still gets the error message, this isn't something you'll fix by elevating.
Change the code in the ERP app to launch your app elevated. You mention C#. Launching with the runas verb is an approach here. This puts the burden on the ERP developer and they may not be able to do it.
Add a manifest to your app. You can embed one, or if your app is called foo.exe just hand-create a foo.exe.manifest file with the appropriate requestedExecutionLevel. To embed one, use the Properties page of your C# project to choose the right kind of manifest. Make sure you're launched with UseShellExecute set to true, or the manifest will be ignored.
If you choose the first option, the UAC prompt will be every time the ERP app launches. Not good. If you choose the second or third, the UAC prompt will be every time your console app is launched from the ERP app. Probably acceptable.
One other thing you might consider is looking far more seriously into why the console app needs admin privs. Are you writing to the root of C or to Program Files? Are you updating a registry key in HKLM? Whatever you're doing, why are you doing it that way? Unless your app installs or configures something (in which case getting a UAC prompt is good and proper) you should try to adapt it so that it writes to pre-user storage and doesn't need elevation. Then you will no longer be worrying about how to launch it elevated, in any case.
create a batch file containing something like:
runas /env /user:%USERDOMAIN%\%USERNAME% cmd.exe /K YourProgramName.exe
Where %USERDOMAIN% and %USERNAME% are replaced by your admin account details.
And run that instead?
I want run my program under a limited user account but with administrator privileges on windows XP.
I can't find an answer. I think I can use two ways:
Run my program by another way like a program or a service
Run my function with some method like PrincipalPermission space or something like this
But I can't solve this problem.
Have you looked at the "runas" command? For example:
C:\> runas /noprofile /netonly /user:MYCOMPUTER\testuser "C:\Program Files\My Special Program\Program.exe"
I want run my program under a
limited user account but with
administrator privileges.
This can't be done. A limited user doesn't have admin privileges. You need to run it as an admin user with, e.g. runas.
One way to solve this is to fragment your program into two parts. One part as a windows service and the one as a user app. You can set the service to run as a Network Service, Local Service or Local System depending the level of access you need. Anything that needs administrator privileges will be performed by the Windows service. The user app can be responsible for showing the user interface and other similar things. You need to have some kind of IPC (Inter process communication) between your applications to facilitate this as well.
I need one of my .exe to always run as administrator without UAC prompt. My program will be installed with setup, which will have for one time admin rights, and I need to perform such step in this setup that my exe will be always executed as admin without UAC prompt.
I've found 2 solutions so far:
1.
Use custom service, which will elevate the program for me.
2.
Use Task Scheduler.
Is there any other solution? Some manifest probably?
Thanks.
If it were possible to do this, then UAC would be completely ineffective. The inability of applications to elevate themselves without user consent is the fundamental principle behind UAC.
Aside from already having an elevated process that launches it (i.e. service or task scheduler), the answer is no, it can't be done.
Of course what you are supposed to do if you want to just drive UI is to use the UI access flag in your manifest (see http://msdn.microsoft.com/en-us/library/ms742884.aspx). If you install your application in a trusted location (e.g. system32) and it is signed (bleh!) then when you run your application it will be elevated to high (for an admin account).
The signing requirement makes it slightly annoying but at least it reduces slightly the attack surface as your code gets run with high integrity but not with an administrator token.
Background: I am by no means a windows security / user permissions expert. I have an application (written in C#), that has to be able to write / delete files & folders in its root directory, write / delete files elsewhere on the disk, write/modify values in System Registry (Local Machine) and start & stop other applications and services. I figure that I need administrator privileges for at least some of those actions.
I tried running this and on computers with UAC turned off it works great without any additional settings. However on computers with UAC turned on (any level above 'never notify' in Windows 7) it will crash. I need it to work on all computers.
Up to now I would just manually check the "run this program as administrator" checkbox and everything would be fine. However now we have decided that we will allow customers to install this software on their own, and it needs to run "out of the box".
I have a deployment project in Visual Studio 2008 that installs everything and writes the necessary start up data in registry. What I need to do now is to set the "Run this program as Administrator" flag. I am guessing this isn't quite as simple as I'd like it to be.
So What is the proper way of doing this? This program is started on startup, and it would be irritating for our customers if UAC would pop up (and possibly dim the screen) every time they restart their computer.
Thank you for your help.
EDIT: Thank you for your replies. I realise that working around UAC would be frowned upon, and I can see that Microsoft does not support "white lists" so it would ask for permission only once. That's fine I can respect that, however I do have some follow up questions:
Can you provide me with a link that will show me how to properly elevate the program to correct elevated state? Is there any literature on what are the options, etc... Basicly I'd love a UAC 101 guide.
Is there a way to elevate the security status when I need the extra privileges (and only then prompt with UAC). Basicly this applications runs in the background, doing mostly nothing for most of the time. Every now and again it will check some files (at this point I will require to be able to write to disk and read the registry (read only is fine at this point), however since it's a temporary folder it wouldn't matter where I'd put it. If there is a location where the application can write without any privileges that would be perfect.)
However at some point I will need to preform all the rest of the tasks (user needs to confirm this action anyway) so if UAC would prompt at this point that would be no problem. Is there a way to elevate it just at this point, and then return it to default permissions?
Will such a solution work with older versions of Windows, including Vista and Xp (and perhaps older?) What would it take to make it work?
The proper way is to elevate when the program starts, with the UAC prompt (which you can set via the program's manifest) - attempting to be clever and bypass it is frowned upon.
Think about it - if you could install something which would elevate automatically without the UAC prompt ... what would be the point of UAC?
To add a UAC manifest to a program you simply add the manifest in a project and edit it. A sample manifest for UAC is here. If you want to elevate at the last possible moment then you need a spawn separate process - you cannot elevate an existing process. So separate that bit out and then start it using
Process.StartInfo.UseShellExecute = true;
Process.StartInfo.Verb = "runas";
You need to rethink how your application works. You're quite correct that it would be annoying to display an elevation prompt on login. So don't do it. On the other hand, you may well have tasks which you need to perform using administrative access.
So you have two choices:
Change your tasks so that they no longer require administrative elevation (e.g., write your files elsewhere).
Break your application into a Windows service component and a user interface component. The service component can run under an elevated account (hopefully the least-elevated account necessary to perform the tasks you need to do). The user interface component can talk to the service (via named pipes or similar) when necessary.
You can split your program into two components:
a user application running without elevation
a Windows service that is responsible for the tasks that require elevation
Since you're using .NET, communication between the components is probably easiest done using WCF.
And as a side note: Programmatically modifying files under C:\Program Files is not considered good practice and might lead to a number of other problems. Windows has dedicated places for storing configuration settings and other program data.