I have an application that does a loop which starts some processes programmatically one by one. My app itself runs under a standard user, but I need to run only those processes as admin so I can install them.
To achieve this, I use the 4th response from this thread
My two questions are:
is that code which is pointed in the above response, supposed to ensure that the process automatically runs as admin, or that the user is shown a dialog where he chooses whether to run as admin or not? I am confused by what this code is supposed to do.
Also, in case a dialog is supposed to be given to the user - how can the app be coded, so that the first user option is remembered in my loop for the next processes started with the verb "runas" ? So basically to store somewhere the user option (run as admin or not) for the other processes.
Thank you in advance
First question: It is how to start an elevated process from a non-elevated one.
Second question: there isn't -- or at least shouldn't! -- be any way for a non-elevated process to elevate anything without a user prompt. The best solution for your program is either to start it off with admin rights, or to use the first elevation request as an opportunity to restart with them (using the technique you linked to).
Related
So I have made a program that requires administrator permissions every time you run it. Is there a way to give it permanent administrator permissions after you give the permissions once. So basically the first time you run the application, it asks for administrator permissions and if you run in a second time, it wouldn't ask for them again. Is this even possible at all and if so, can I do this programmatically?
Thanks
No, you cannot.
The only thing you could do is implement parts of your program in a NT service. Set the service configuration to "start manually" and change the ACL to allow any user to start the service.
Your program would then use the service to perform the tasks that require elevation.
If you choose this route, you have to be careful so that you don't introduce security holes in the system. Only allow predetermined actions, not arbitrary commands nor write operations...
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 C# app that needs to allow the user to change the Computer Name. This is a pretty privileged operation. I can only get it to work if the user runs the app as Administrator (Windows 7, right-click on executable, "Run as Administrator"). Fine, but the user IS an administrator, so why would they need to Run AS an Administrator? I've tried this several times. It always fails if the user--an administrator--tries to do it running the application normally. It always works if they run it as "Run as Administrator".
If the answer is, "It just works that way, you have to run as admin even if you are an admin," my question is how can I detect if they are running with super-duper admin privileges? I found this, but it just checks to see if the user is part of the Administrator user group which, I already pointed out, isn't sufficient (and throws a null pointer exception).
Am I missing something here? Do I need to approach it from another angle?
It's because of User Account Control (UAC). Introduced in Vista, this changes the way administrator user accounts operate.
When an user from the administrator group logs on, the user is allocated two tokens: a token with all privileges, and a token with reduced privileges. When that user creates a new process, the process is by default handed the reduced privilege token. So, although the user has administrator rights, she does not exercise them by default. This is a "Good Thing"™.
To exercise those rights the user must start the process with elevated rights. For example, by using the "Run as administrator" verb. When she does this, the full token is handed to the new process and the full range of rights can be exercised.
You almost certainly don't want to be detecting whether or not your process is running elevated. Best practise is to mark those parts of your program that require elevation and force the system to show UAC elevation dialogs when those parts of the program execute.
The bind is that elevation can only happen at process start. So if you need to split your app into parts that require elevation, and parts that don't, there need to be multiple processes. Whilst you could mark your entire app as requiring elevation, you should not do so if the only thing that needs elevation is the very rare scenario where the computer name is to be changed.
Your next step is to bone up on the details over at MSDN. For example:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb756996.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511445.aspx
I was hoping I could get some input on the best way to handle authentication for my application. I have a C# form that has three buttons. One button is for querying tasks on a specific server, one button can start a task, and the last button can end a task.
My question involves the best way to do this for multiple users. I know I can add these users to the administrator group on each server but I really don't want to do this because these are all non-admin users. Also, I am running this against 3 different domains and multiple servers with no trusts.
Is there a way to either create a user that I can give admin rights on all of the servers and then run the C# app as this user (could be domain or local) or is there a better way to handle permissions for schtasks without giving admin rights?
I have researched impersonation but I don't think that does what I need unless I missed something.
Thank you,
Matt
You can use the runas command - this lets you set a user name and password to execute the application under.
You will still need to set the link up for each user/computer.
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.