I am working on my year 3 Project at Uni.
An integral part of the feature is that only an admin can mess with the program this includes:
Install
Uninstall
Settings (Files)
and Finally, the controversial; 'Shutting down the program'.
Here is what I currently have in mind.
Windows Form App, Launches at startup, takes note of all kinds of things, and monitors and prevents others, shuts down with the PC (not sure how to make the program exit nicely on shutdown? )and then should the computer be turned on again the program is there at startup, doing its job.
I am not sure if its better for a windows service, but the program definitely needs a windows form interface so users can login (should an admin require to do so, through a user account).
Could anyone counsel me on whether a windows service would be better, if so, some good documentation on them? I looked and tried out the MSDN tutorial but without much luck or even understanding.
I know it's bad practice to interfere with the user, and prevent them from closing a program, but its all part of a functionality that an admin would knowingly install.
O yea, I forgot to mention the program would be installed.
normally this is done with user permissioning and roles.. you create users and assign them roles. if a given user who is trying to "close" is having "admin" role then we allow him otherwise we dont. you can put these users in registry and create a windows service that your program can talk to or directly query.
Related
I've been wrestling with this issue for a few days and can't find any posts that solve it for me. Maybe what I want isn't possible.
We have developed a WinForms application for internal use at our company.
Most employees do not have admin access in windows.
Our application requires admin access to the machine and needs to automatically start when the user logs on.
Here's what I've tried:
1) Putting a Shortcut in the Startup folder
I can get the app to automatically launch (using a relauncher), but it still requires an admin to be at the computer on every restart (to enter the password).
2) Registry Key
I created a Software\Microsoft\Windows\CurrentVersion\Run registry key to automatically start the application. Whether I run the relauncher or the app itself, UAC demands a password on every restart (or relogin).
3) Scheduled Task
I created a scheduled task to automatically start the app on logon using admin permissions on the machine (under use the following account). I also checked the 'Run with highest privileges' box. UAC still pops up on every restart.
4) Windows Service
I tried to run the app as a windows service, but it has a user interface (which is disabled by windows services).
5) Disable UAC for Specific Program
It looks like you can disable UAC for a specific program but that involves downloading the Application Compatibility Toolkit, creating some kind of database, etc. I'd very much prefer that our IT staff wouldn't have to do that at every machine. At this point, it's probably my only option.
It seems like an admin should be able to install an application so that it runs automatically without a prompt. Am I missing a way to do this?
You should make split your program into a non-admin UI, which runs on user startup, and an admin service, which performs the administrative tasks.
To run admin-requiring code from the UI, use WCF to ask the service to do it.
Beware that hostile parties may impersonate the UI and ask the service to do malicious things; you need to carefully figure out what the service should be able to do in response to IPC calls.
Your problem is not a UAC problem, it is a security problem.
And the answer depends on what your application that "requires admin rights" needs to do.
If your application needs to be able to start, and stop services, then the User needs the ability to start and stop services. In which case you need to give the users that privilege.
If the user's need the ability to alter or delete files, then they need that privilege too. In that case it is easier to grant Full Control permissions to Everyone.
If your application needs the ability to modify registry keys in the HKLM tree then you can, again, grant Full Control to Everyone in the registry.
If you need your users to have the ability to modify items, then they need permissions to modify those locations. Granting them those NTFS permissions is not a bad thing; it is exactly what those permissions exist for - to control access.
But why
But then we ask why? What is it you're doing that users need all the rights of an administrator, and all capabilities of an administrator, all the power of an administrator, but you don't want to make them a member of the Administrator's group?
The answer is almost invariably that your internal use application doesn't need to run as an administrator.
What Would XP Do?
The question becomes:
What would you do on Windows XP?
A standard user on Windows XP didn't even have the UAC convenience feature. If a user wanted to run an application an administrator: they had to logout and login as an administrator. How did, or how would, the application work on a system with UAC disabled?
Presumably very little of your application needs to run as admin - the rest would be better running as the unprivileged user. This is very common (think self-updating browsers, for example).
The proper way to do this is to install a service to do the privileged bit, and have the UI communicate with the service.
Our application requires admin access to the machine ...
Why?
You cannot bypass the UAC prompt, and this is by design.
See FAQ: Why can’t I bypass the UAC prompt? for a good discussion of why. Excerpt:
If it were possible to mark an application to run with silently-elevated privileges, what would become of all those apps out there with LUA bugs? Answer: they'd all be marked to silently elevate. How would future software for Windows be written? Answer: To silently elevate. Nobody would actually fix their apps, and end-user applications will continue to require and run with full administrative permissions unnecessarily.
Im working on application for Windows Server 2008 R2 (.NET 3.5.1) that would work even after cold reboot, without requring someone to log on any account on the server.
Few words about application itself, it is written in c# application for registering employees work time at the company. Users (employees), have thier cards which are beeing scanned by barcode scanner, each scan means either "work started" or "work stopped", everything is serlialized into xml file which is later on modified and put into .csv but that doesn't matter.
Barcode scanner is working as a keyboard, so all codes are beeing "typed" like from a keyborad, to the PC. I made application read the keys despite the fact that console application is not in focus, or not visible at all.
What i need to do is to make that application work even after cold reboot, it has to be fully automatic.
So far i figured out 2 approaches to do it, one is to create a service which would keep another process alive (if its not working, just turn it on), i didin't have much luck with this one, i have already created service that launches another process for me, but the process is working differently, if i would run it myself, there is no communication with the process so i cannot even tell if its the right one.
Another one is to just put my app into registery /microsoft/windows/current version/run, and enable autologon for user with limited prividges. This actually could work but it is not perfect solution, because after all we do not want to have user logged in on server in company 24/7 right?
I know that most of you are way more experienced in programming than i am, so i would appriciate any solutions how to solve my problem
Lichoniespi
Your options depend on physical security of the system (whether passers-by can do much to it apart from scanning a barcode), but let us assume that it is an easily accessible desktop. In that case, you probably do not want a logged in user.
Use the service approach. You do NOT need a separate process for accessing the keyboard. Create a global hook of type WH_KEYBOARD_LL.
Declare your callback function like this and put it into place with SetWindowsHookEx.
I would use the first approach, create a service, and to comunicate with the running application i would be using a network socket or pipe. For the service be sure that you're using an existing user account (not System) and allow it to interact with the Desktop.
I didnt get correct answer and got lots of answers like "we can not do like this" for my previous questions.
Thats why I decided to explain in detail about my problem please help me if you can or please ask your friend who can answer this.
Now my problem:
Step 1:
I created a C# program which edits various windows registries.
For editing windows registries we must have an Admin privilege.
My program is running fine in Administrator mode without any problem.
Step 2:
I want my program to be run into limited user mode also. If few people didnt get what I am saying here is that I want to run my above C# code into Guest mode.
In guest mode there is a restriction that We can not change Windows Registries.
So as I am executing my Application, I am getting one notification which is asking for Admin Password.
After inserting Admin Password my application is working fine.
Step 3:
I want that my application must not ask Admin password every time in Guest/limited account.
I also want that in Guest mode my Application should work.
I also want that in Guest mode my Application should be able to access and change Windows Registries.
Step 4:
Lot of people replied me that we can not do this in Guest mode since Windows is restricting users to edit windows registries for security purpose. So please if you also feel like this then please do not reply to this question.
I am answering to those people that, all good antivirus which run into Guest mode has access to Windows Registries.
Step 5:
Since I know Admin Password so is there any way of saving Admin password in our C# code and bypass popup message of asking Admin password again and again.
Is there any way that we will instruct Windows that our application will be running in Admin mode and do not ask for Admin password again and again
How Antivirus application running in Guest mode do all the operation like deleting virus from system32 folder and resetting registries after Virus attack. These antivirus application never asks for "We found a virus in System32 folder, Since I am running in Guest mode and unable to delete virus, so please enter Admin password so that I can delete virus"
I hope you understood what i mean to ask?
I want to develop a C# application which should run in any mode (Admin/Guest/Limited) and should be able to Create, Edit and Delete Windows Registries.
Note: Please do not answer this with "right click and Run As Administrator".
To the best of my knowledge, antivirus software solves this problem by running two (or more) processes: a user interface program running as the guest user, and a privileged process (usually a Windows service). The user program is not able to actually manipulate privilege-restricted resources (like secure registry hives) -- instead, it communicates with the privileged process (hopefully in some secure way) and the privileged process performs the privileged action on behalf of the user.
This is the same kind of technique by which programs ever access privileged resources, such as hardware. Your user-level process doesn't (usually) have the right to perform various hardware actions, like remapping memory in the MMU, but the OS does, and you can get the OS to do what you want by asking it to. System calls thunk into kernel mode, which is fully privileged. However, the system call interface limits the kinds of privileged actions which you can take.
I cant help but saying, NO, you cant do admin things under a guest account. And no- you cant programmatically bypass UAC.
Maybe the following 2 workarounds are interresting for you?
I believe antivirus software runs under the System account (can only be installed by an administrator). For your application, you can create a server/client architecture (both running no the same machine) where the server is installed by the administrator (as part of the whole package) and runs by default under the System account. Then you can use the client on the quest account to send commands to the server.
One other solution might be not to use the registry directly but use another underlying datastore which is accessible by a guest account and synchronize that on demand with the registry (startup and shutdown?), so you only need the admin to login once or twice during the run of your app.
i wanted to know which process in Windows is user specific, i mean it get created for each user login. i tried explorer.exe but when u switch user and log into new account then it shows old login name in my code. basically i need to just log which user logging when in app.
If all you need to know is which user(s) are using your app, can you just check Environment.UserName when you start your app?
I missed the tag indicating you created a Windows Service. That's a very different type of animal than a regular application, and the advice you receive for one is not necessarily transferable to the other.
Specifically, I notice that you've tagged this question windows-7. If you're trying to run this service under Windows 7, you need to understand a few things about how the model for Windows Services was substantially altered starting with Windows Vista. Specifically, they now run in an isolated session and are prohibited from interacting directly with the user.
Also see my answer here for a better explanation.
The fundamental point is that, from the perspective of a Windows Service, there is no such concept as the currently logged-on user. A Windows Service runs in its own isolated session and is not affiliated with any particular user. That's why the code you found to determine the user associated with a particular process is not working as you expect for a Windows Service. A standard user doesn't own the process running the service. (And replacing your service with an application is also not a viable option, given how I understand your requirements. As I explain here, user-mode applications are started when a particular user logs on and will be closed whenever that user logs off.)
Another problem is that more than one user can be logged in simultaneously to a single workstation. Windows is a thoroughly multi-user operating system, so the best that you can hope for is to enumerate all of the currently logged in users. The NetWkstaUserEnum function will get you that list, but note that it includes all types of logons, including interactive users, services, and batch logons. To call this function from C#, you will need to P/Invoke—you can find information about that over on pinvoke.net.
I have been reading a lot about executing a GUI application from a Windows Service. The "Allow service to interact with desktop" check box worked for me when the Service runs as the SYSTEM user (I am using Windows XP).
Now I need the Service to run as a User defined in a domain (from the network). Everything works fine (even if no user is logged into the machine) but the GUIs are not shown (even if the same network user is logged in!).
I know that the GUIs are running, it's just that they are hidden. Why is that? Is there a way to show them if a user is logged on (like when created by the SYSTEM user and allowed interaction with desktop!) ?
if so, would it work if the user logged in is not the same as the one the service is running on?
Edit:
#casperOne: I see your solution, and it is the same that people (even you) have been posting around. In my case though, I am sure I am running on a secure environment and ONLY one user will be logged into a machine at a time. Isn't there anything one can do to simply unhide the GUIs? Why would this work with the user SYSTEM allowing interaction with desktop and not with another user?
Your approach is completely wrong, and will not work when deployed on Vista.
Services should NEVER assume a login session with a desktop to interact with.
Rather, you should have a second application which is run when the user logs in (or some other point in time) which communicates with the service and then displays UI elements when it receives notifications/responses from the service.
See this other question (and answers) for further information:
How to detect if a Window can be Shown?
Short answer: No, you can't do this
Long answer: Noooooo.
Basically, Microsoft are making changes to further prevent this. As casperOne stated, you'll need to separate your UI components away from the service.
And even on XP it didn't work on non domain joined machines (if you have multiple users using Fast User Switching the popups showed up on either the wrong desktop or no desktop at all).
As to why Microsoft changed this, do a quick search for "Shatter Attack" - by isolating service code from the desktop they completely cut off this entire family of security vulnerabilities.