I'm trying to use SetSystemTime (from Kernel32.dll) or alternatively to use TIME from cmd.exe.
Both fail, TIME gives me the error
A required privilege is not held by the client.
I've already used gpedit.msc to add local/Users and also the user itself to security settings/Local Policies/Change the system time.
I tried to enable the privileg with AdjustTokenPrivileges( SeSystemtimePrivilege ...), but I got a GrandPrivilege failed error .
I'm using Win7 x32 Professional.
It's a standard user with admin privileges, but I'm trying to make the time changes without "Run as Administrator", as the program that calls the SetSystemTime function shouldn't be started with "Run as Administrator".
I supposed that the purpose of the Change the system time policy is exactly for this case and it's also described at MSDN
I'm at a loss what to do.
It turns out that although SeSystemTimePrivilege doesn't trigger UAC for a non-administrator, it is still removed from the restricted token that is generated when an administrator logs in. The upshot is that you can use group policy to assign SeSystemTimePrivilege to non-administrative users, but the policy has no effect for an administrative user.
If it is acceptable for the program to require elevation when run by an administrative user, you could use the highestAvailable manifest setting. That way, the program will only ask for elevation if the user is an administrator. Alternatively, you could design the program to ask for elevation only when it actually needs to set the time.
If an elevation prompt is not acceptable, you will have to install a system service to change the system time on your application's behalf.
Related
I have made a power shell script which loads pageant (a windows SSH authentication agent)
with my private keys. In short the script isn't much more than the following two lines:
$tool = "pageant.exe"
&$tool $files.ToArray()
$files is a list of strings which contains all my private keys which must be loaded.
I have no problem with the working of the script because it does its job perfectly when I execute this from my powershell
console.
I want to execute this script whenever I logon to my account and I do this by adding a powershell logon script
group policy with the group policy editor (gpedit.msc), the script also executes and in fact does load the pageant.exe tool.
However the tools utilising the pageant.exe tool (putty and plink) does not work. It doesn't recognizes the pageant authentication
agent.
So my first question is, what is the difference between starting the script from my own powershell console and starting the script
from a group policy (logon script)?
I also have dome some investigation and I see a couple of differences. The first is thing is that the started pageant tool has a UAC Virtualization flag in my task manager when I start the script from my own console. This property isn't flagged when it's started
from the logon script group policy.
The second thing is that when I disable the UAC the script does work from the logon script group policy. So I assume it has something to do with the UAC but I don't know how to solve this. I want the script to work when the UAC is
enabled as well.
The second question what is this UAC virtualization flag and how does it influence the working of a process? The third and last question is how can I get my script working?
It looks the thing is UAC virtualization. This flag means that all write attempts to protected system areas are redirected to VirtualStore in the user's profile: C:\Users\<username>\AppData\Local\VirtualStore. When UAC is disabled, this redirection is turned off.
When UAC is enabled, any attempts to write to Program Files, as an example, will be redirected to the corresponding directory in your VirtualStore. Later when programs read the files, they also see them from the redirected directory.
Yet your logon script runs without Virtualization enabled, and therefore its attempts to modify/read files do not go to the redirected VirtualStore but rather directly to Program Files.
So you have to make all your parties work without virtualized directories. If the executable has a manifest, preferrably declaring compatibility with Windows 7, then virtualization is turned off. But it may fail to work correctly without virtualization if it tries to write to Program Files.
Note: registry writes to HKLM are also virtualized.
There are a number of ways to turn off UAC virtualization; the simplest is to include an external manifest (in your case it would be named pageant.exe.manifest) in the same folder as the exe. This could suppress elevation, but then your writes would probably fail. The very fact that virtualization is affecting you means that pageant.exe must write to protected areas, and without virtualization or elevation, you'll get access denied.
Therefore what I would do is leave Group Policy out of it. Set up a Scheduled Task (click Start and type Task to launch task scheduler, then click Create Task on the right) that runs at logon (the Trigger tab, click new, change the top dropdown) to run your script (Actions tab, click new) and that runs elevated (General tab, check Run with highest privileges). You'll have to consent once to the UAC to set up the elevated task. Then you're done and pageant.exe will write to the protected area where the other apps can read it.
If, after you've got this set up, the other apps continue to read from the virtual store instead of the real one, just delete the files/folders in the virtual store.
For completeness I added the answers to my own questions.
What is the difference between starting the script from my own powershell console and starting the script from a group policy (logon script)?
A: The difference comes from the fact that my user is part of the Administrator group which will run the script with elevated rights. When you logon as a administrator, Windows will generate a standard user access token and a administrators access token. The last token will be used to run programs with elevated rights (this is without UAC virtualization). Now when I start the script from my own powershell console, which is started with the standard access token, the started pageant is run with UAC virtualization. If the tools which use pageant run with a different mode, then my problem occurs.
What is this UAC virtualization flag and how does it influence the working of a process?
A: Check out this link.
How can I get my script to work?
A: You can use the solution provided by Kate Gregory (do not check run with highest privilege option) or add a batch file to your startup folder which runs the powershell script. This will run the script with the standard user access token and with UAC virtualization enabled.
Firstly I want to emphasize that I'm not trying to do anything "nasty" or "hackerish", nor am I trying to hide anything from user here.
During installations (using InstallShield LE) of my application user is prompted by Windows UAC to allow it to run in Administrator mode; If user accepts it - installation continues (standard behavior) and user again can check the option to add this program to autorun list (by adding a registry key to HKLM/../Run). All is fine and normal. But after every Windows restart, when this application starts, UAC kicks in and asks for user permission. Question is, how to avoid it, since it's a bit annoying (yet my app needs Administrator privileges to run)?
I mean user already granted such permissions on installation, so I cannot see a reason why it needs to be prompted on every startup? Moreover, I believe most antivirus software and such, also require elevated permissions to operate, but UAC doesn't prompt for it at Windows Startup.
Thank you for any advises, information, comments or solutions.
Does your application really need to start elevated? Or will it need to elevated access later when the user uses it to perform an action? If you can, drop the later admin task into a separate exe, allowing the main exe to start with no elevation - when you shellexecute the worker process later it will UAC on demand.
At install time, as you have noted, you have elevated the installer. If you want to run elevated code on subsequent runs, automatically, this is the point to install a service - which is what all those other apps you mentioned do.
You can't get around UAC for a process started in an interactive session. You could use a service running as a privileged user but you would be far better off finding a way to do whatever you do without requiring admin rights.
It's not possible for a program to run elevated without prompting. What you want to do is factor those portions of your application that need elevation into a windows service that runs as system. Then your autostarting application can make remoting calls to the service to delgate those activities that the user can't do without elevating.
Not done it but I found this article Selectively disable UAC for your trusted Vista applications that says use 'Application Compatibility Toolkit' from microsoft.
The Compatibility Administrator allows you to create a database of
compatibility fixes that will allow you to run certain applications
without an accompanying UAC.
Run the Compatibility Administrator as admin
select a new database template
Click the Fix button on the toolbar. When you see the Create New Application Fix wizard ... enter details about your app
Select a Compatibility Level
Select RunAsInvoker as the fix
It seems that the last one
Selecting the RunAsInvoker option will allow the application to launch
without requiring the UAC prompt.
Should do what you want provided that the invoker is admin and I think you can do this at start up using the scheduler : Create Administrator Mode Shortcuts Without UAC Prompts in Windows 7 or Vista
As you can see it runs your app in the compatibility mode which may or may not be acceptable for you.
I need to change the behavior of my application depending on user privileges:
When my application can run as Administrator
When my application has limited privileges
Since "requireAdministrator" is embedded within the manifest, the same .exe can't work on (1) and (2) at the same time.
What's the best way to deal with this issue? I am planning to pack two executables (one with "requireAdministrator") and decide which one to run.
Someone have other suggestions?
You can use a manifest that asks for highestAvailable instead of requireAdministrator or asInvoker. This will elevate if a person who can just consent to elevating is running it, but won't if it's someone who would need the OTS prompt and entering an admin id and password. I don't care for it myself, since you can't write your code in confidence knowing whether you have the privileges or not. But this is how to achieve what you're asking for.
I have an app that normal users need to be able to run, but requires administrator privileges to actually function.
I tried to make the shortcut that my users run it with "Run as administrator" but this just causes a UAC prompt whenever they try to run the app.
Is there any way to elevate privileges programatically, without my users needing to go through a UAC prompt and/or knowing an administrator password? From a security standpoint, I understand that most applications shouldn't be allowed to do this, so I'm hoping there is some way to do it if I can provide a valid username/password pair, or something.
The app is written in C#, so a fully managed solution would be preferred, but p/Invoke Black Magic (or even writing an MC++ Wrapper Which We Do Not Speak About) would be more acceptable than disabling UAC entirely.
Generally this problem solved by installing a Windows Service which runs as SYSTEM or an admin account. Then your application can request the privileged action from this service.
Obviously to not pose a security threat ensure that your service can't run arbitrary code or something which might leave the all users vulnerable to privilege escalation attacks.
Winpcap and most of the other sniffing applications use a similar design to give sniffing access to unprivileged users.
Actually, why don't you just create a Task Schedule which runs the app with elevated privileges? As long as you setup the Task under elevation, it will not prompts you for a UAC when it is auto-run during reboot or whatever your trigger is.
Just make sure you set level=requireElevation in your manifest file, and task scheduler will run your app with admin rights without prompting your user for admin rights, as this had already been established when you setup the task with admin privileges.
It's not possible. You cannot decide to suppress UAC prompt.
You have to ask yourself:
What would happen on Windows XP?
The user is a standard user on Windows XP, and the application "needs" to run as an administrator. Are you:
going to refuse to run?
going to crash on startup?
going to show the user access denied error messages?
If the user is simply not allowed to run the application as a standard user on Windows XP, then UAC is your friend: it tells the user that they have to be an administrator.
And it even offers to let them (temporarily) gain administrative privileges.
But you have to ask yourself:
What would happen on Windows Vista?
In order to elevate, the user will need someone from IT to walk from three buildings over, so they can type in their credentials "over the shoulder". Perhaps you can make the user's life easier. Let 99.9% of the application run, and split off that 0.01% to an "administrative" module.
I am starting an application (EXE) through Installer( MSI). While installing the MSI in Vista, it automatically run with Administrator rights (after thorough UAC). Hence the application started also runs under system user. I want this application to run Under Current User instead.
In order to run application in current user I need to explicitly double click the exe. But I want it to be done programmatically.
So far, the only way out is to use Process.start() using username/password. For this I need to prompt user and take password from him, which I dont want.
Can we run an exe under current user programmatically (Vista)?
Regards
Sumeet
If the installer, which spawns the program, is running under a user, for that program, "Current user" is that user, ie. Administrator in your case.
You will have to explicitly escape out to a different user context, and unfortunately this involves getting the user to specify his password (at the very least). Otherwise you could have programs impersonating users all willy-nilly.