Alright, so question.
I'm working on an application that was previously hosted on a Windows 2000 machine, and now I have to move it to Windows XP. The application needs the ability to switch its user account from Administrators, to a restricted account, and vice-versa (with reboots in between).
Using a netapi32.dll wrapper this works fine in Windows 2000. When I try it Windows XP, I get Access Denied errors when I try to remove the account from the restricted account and add it to the Administrator account. It works the other way around.
Does anyone know where the permissions need to be modified in order to be able to allow the restricted account to add/remove groups from user accounts? It seems to be handled differently between Windows 2000 and Windows XP.
Thanks.
I can't speak to the differences there, but I think you need to look at other solutions, like impersonation. This will allow you to execute code and Windows actions under the contexts of various users without performing modifications to the account itself.
If you must perform modifications to an account for other purposes, then your service needs to run under the context of an administrative account and perform the modifications on a different account.
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.
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'm running on a Windows 2000 Pro SP4 box (off domain) and trying to impersonate a local user on a Windows XP box (on domain). I'm using code very similar to the WindowsImpersonationContextFacade in the question posted here: How can I temporarily impersonate a user to open a file?. I am using impersonation to remotely start and stop windows services as well as access network shares (for some automated integration tests).
To get this working, i had to use LOGON32_PROVIDER_DEFAULT and LOGON32_LOGON_NEW_CREDENTIALS when calling LogonUser. Everything worked beautifully ( Windows XP on domain to Windows XP on domain, Windows XP on domain to Windows Server 2003 off domain, and even Windows XP on domain to Windows 2000 off domain). The one issue was running on Windows 2000 Pro SP4 off the domain and trying to impersonate a local user on a Windows XP box running on the domain.
To get the Windows 2000 piece working, i had to use LOGON32_PROVIDER_WINNT50 and LOGON32_LOGON_NEW_CREDENTIALS when calling LogonUser. This seemed to get me 95% of the way there, i could now impersonate the local user on the XP box and start/stop services as well as access a network share using the impersonated credentials. I'm running in to one problem though, calling Undo impersonation and closing the token handle seems to leave the connection to the remote box open. After about 10 or so impersonation calls, further impersonation attempts will fail with an error saying something about too many connections are currently open. If i look at the Computer Management -> System Tools -> Shared Folders -> Sessions on my remote Windows XP box, i can see about 10 sessions open to the Windows 2000 box. I can manually close these (i think they may eventually close themselves, but not very quickly) and then impersonation begins working again few more times. This open session issue doesn't seem to be a problem in any of my other test scenarios, just when running locally on a Windows 2000 box.
Any ideas?
Edit 1:
After some more testing and trying out many different things, this seems to be an issue with open sessions not being reused. On Windows 2000 only, every call to LogonUser to get a token and then using that token to impersonate seems to result in a new session being created. I'm guessing Windows XP & Windows Server 2003 are reusing open sessions since i don't seem to be having any issues with them. If I call LogonUser once, then cache the token, I seem to be able to make as many calls to impersonate as I need using the cached token without running in to the "too many connections" issue. This seems like an ugly work around though since i can't call CloseHandle() on my token every time i perform impersonation. Anybody have any thoughts or ideas, or am i stuck with this ugly hack? Thanks
In case anyone is ever interested, i never did find a good solution to this problem. The work-around that i went with was to cache the token returned from LogonUser, and then reuse that token with every impersonation call. This made things work great, but its not something i'd ever want to do in production code.
"start/stop services as well as access a network share". Depending on your code, this can lead to such issues.
Calling Undo only releases impersonation involved resources, but not all resources your application uses.
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.