I'm currently working on a screensaver application for Windows that needs to check if a user is idle so it knows when to turn on. Sometimes a user may have a certain app (like a video player) running that requires no user input and idles the system even though the system isn't truly idle.
The powercfg -requests command displays if any application has requested the display to stay active, but requires administrator privileges to run. I looked at the official powercfg documentation and played with a few commands in Power Shell and cound'lt find anything that worked. Is there a way to get this same information somehow without the application requiring administrator privileges?
Related
Not sure if this is more suited to SO or Server Fault.
During unittesting ran across what appears to be a limitation of "Fast User Switching" on windows 10. Had the following two line batch file.
C:\Windows\System32\timeout.exe 30
C:\Windows\System32\shutdown.exe /L
Open a CMD.exe and run the bat file. 'Fast Switch' (ie logon) to another account. The timeout completes as scheduled, but the logoff statement has no effect...user is still logged on. When you return, you can see the shutdown.exe is on the screen, but the session is still active.
If you run the script and stay logged in to the account, after 30-seconds, the logoff command works as expected.
Also discovered the same limitation if instead of fast-switching, you invoke the screensaver (ie: Lock the account). After 30-seconds, the first command finishes but the session is still active.
I've scoured MSDN and Google, but there is scant documentation on Fast-user switching and the Lock functionality and how they might limit what a user can do while switched or locked.
You can definitely end a session while it is locked, but you can't do it with the normal ExitWindows API call that shutdown.exe is using. See the notes in MSDN:
EWX_LOGOFFShuts down all processes running in the logon session of the process that called the ExitWindowsEx function. Then it logs the user off.
This flag can be used only by processes running in an interactive user's logon session.
For a solution using only batch files, logoff and related terminal server tools allow you to end the locked session. Example using PowerShell which works when tested on Windows 10 1903:
sleep 30
logoff ([System.Diagnostics.Process]::GetCurrentProcess().SessionId)
As for documentation, multi-session support of windows is documented most strongly for Remote Desktop Services. All of the advice and API's used for RDS apply for Fast User Switching. See About Remote Desktop Services.
Is there a way to find out what privileges my application needs in order to run in a Windows 7 environment?
I have a Delphi application that is using BDE and ODBC for database connectivity. This application works on most computers with Windows 7 running on a normal user account. However on some computers it only works on accounts with administrative privileges and is not working correctly on normal user accounts. I suspect it's a permission problem. The computers also are running in Active Directory.
I tried to find some informations using Process Monitor from SysInternals, however the output for me is too advanced. The process monitor log for two runs of my app (1. successful with administrative rights, 2. unsuccessfull on normal rights) had over 22k lines and i could not find the answer (needle) in the process monitor log (haystack).
What could i do to determine the privileges that my app needs in windows 7?
Use the Standard User Analyzer from the Microsoft Application Compatibility Toolkit.
The Standard User Analyzer (SUA) tool and the Standard User Analyzer
Wizard (SUA Wizard) both enable you to test your applications and to
monitor API calls in order to detect potential compatibility issues
due to the User Account Control (UAC) feature in the Windows® 7
operating system.
UAC, formerly known as Limited User Account (LUA), requires that all
users (including members of the Administrator group) run as Standard
Users, until the application is deliberately elevated, by using the
security prompt dialog box. However, not all applications can run
properly with the Standard User role, due to the application requiring
access and privileges for locations that are unavailable to a Standard
User.
Aaron Margosis has a tool called LUA Buglight that is designed to help track down issues related to privileges.
You can download the latest version from this blog post:
LUA Buglight 2.1.1 with support for Win7/2008R2 SP1
It is similar in concept to the MS Application Verifier. However, in practice I found LUA Buglight much easier to use and understand. Same with ProcessMonitor. It will monitor your process in a similar way but only report actions that failed as a normal user but succeeded as a admin user.
There is no documentation but it is simple to use. From the main GUI window select your Exe and let the BugLight program launch it. You need to be running in an Admin account with UAC enabled. Run your program though the steps that fail when you are not an admin. When you are done click on the Stop Logging button to see a report that lists what calls would have failed without admin rights.
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.
We have an application that programmatically maps network drives. On Vista with UAC on, we get some strange issues.
Our application maps the drive non-elevated, so if the user browses explorer and double clicks to run an exe, it prompts for UAC. So when they approve it, it prompts for a username/password for the share... Strange since the credentials are saved.
It turns out, an elevated process cannot access a mapped drive that was mapped from a non-elevated process.
To see this issue in action, do the following steps:
Run cmd.exe with no UAC
Run "net use w: \yourHostname\yourShare /user:yourUser yourPassword /persistent:yes"
Run cmd.exe as Administrator
Type "w:", and see the error message
At this point you can run plain "net use" and see the connection on the elevated cmd is Unavailable but the other non-elevated cmd sees it as OK.
Does anyone know a workaround to fix this issue? or maybe a way to map a network drive to "All Users"?
This is by design.
Even though the user account is the same, with the elevated version having a token with membership in the administrator group and addition privileges, the tokens are created independently and thus have different LUID's and appear to the kernel to be from different user logons. Since they are from different logons, mapped drives are not shared between them.
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx discusses this in additional detail.
Check out this link: Regedit Link
They describe a registry key that allows elevated users to access mapped drives and vice versa. This solves all my issues and was exactly what I was looking for.
EDIT:
The original link is dead, but here's the text as copied from the Jan 24, 2009 snapshot at www.archive.org:
If you are finding that you don't have access to mapped drives from your admin token try the following. When running as a protected admin you have two tokens and this key will maintain the connection for both tokes (that is my understanding anyway). It can also help to clear up issues with Login scripts.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1
Also of use is the "'Group Policy Scripts can fail due to User Account Control" section of this doc.
http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true
I will be posting more information on this soon.
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.