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.
Related
We have an application that needs get from an Administrator account to another limited account and the other way around. Currently we are setting the auto logon in the registry, then reboot the machine. This takes up to 3 reboots as the machines are EWF enabled. Our customer support just cannot sit around and wait for the remote machines to reboot while there's an angry customer on the phone.
We have a windows service and a ui running on the machines (written in C#). Most of them are windows 7, but some are windows xp and windows 8.
I was wondering if anybody here knows a way to maybe trick windows into thinking it was just rebooted and auto log into an account. Anybody know of anything? I do know there are tricky ways to log into an account automatically from the login screen, but as far as I understand that's going to require writing a module to replace GINA in windows XP, and in windows vista and up, since GINA was replaced with a "Content Provider", writing a Content Provider or something, both of which seem overkill, but a possible future solution. Any ideas?
NOTE: We are not switching between accounts so that the application can run a process under that account, we are switching between accounts so real people have either administrative access or limited access to the computer. Hope that makes it a little more clear
If you have an application that needs to run between other users and an administrator, you should be creating a launcher application. The launcher application should be using Process.Start() to start your application. You can supply ProcessStartInfo arguments to Process.Start() so that you can run the application using different credentials.
Here'some help. For Xp, there's a simple registry key that does it (search google for AutoLogon), for Win7, it's a bit more complex. See this topic:
http://answers.microsoft.com/en-us/windows/forum/windows_7-security/how-to-turn-on-automatic-logon-in-windows-7/99d4fe75-3f22-499b-85fc-c7a2c4f728af
I think we had something like this running somewhere, but it wasn't my task and the collegue is on vacation this week. Maybe the above link helps, i'll ask him otherwise.
I'am managing a Lab with around 15 Computers. I wrote a little program to start all of the from one computer and to shut all of them down from a remote computer... So far so good. But it would be really nice to get all computers to do a login (credentials given from the app). There are on all 15 Computers the same user accounts (exp1/exp2). Sometimes all computers are needed logged in by exp1 and sometimes as exp2. Are there any Ideas how I can do this? Any hints on what to search? I'm googling now for a long time.
Please help.
Cheers
Eydrian
As the commenter said you can set the autolongin and reboot the machines or you can get some kind of remote control software like netop. There is no way built into windows to login remotely to the gui primary windows station as it would be a massive security risk.
You don't mention the version of Windows. If it's XP you might be able to do it with a GINA replacement. Some information can be found here:
http://msdn.microsoft.com/en-us/magazine/cc163803.aspx
In Vista GINAs was replaced with Credential Providers but I think they are more limited.
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.
Environment:
win2003 running IIS6 serving asp pages that call delphi code.
Delphi code contacts a c# webservice for which it needs to login (login.asmx). Webservice logs show login is successful. Debug results show that Context.User.Identity.IsAuthenticated returns true.
After login, delphi code doublechecks if it is still authenticated. Webservice returns false -> Context.User.Identity.IsAuthenticated returns false.
Our guess: authentication cookie received by delphi code running under IIS6 credentials (network service?) does not get saved to disk, so login is lost.
Filemon shows 'C:\WINDOWS\Temp\Temporary Internet Files' access denied. Giving IIS6 user admin rights on that folder fixes the problem, but is not acceptable since cookies should work by default.
Running IIS6 in IIS5 compatibility mode fixes the problem, but is also not preferred
Wanted solution: exact cause of problem and smallest modification possible in configuration (giving admin rights to IUSR is not an option)
Cookies do work by default, but you have to have somewhere to store them. If you don't want to give access to the normal place where they are stored, then you will need to set up another directory that you can give rights to and set it up as the internet cache for the IIS6 user.
A couple quick resources that may help, given that for this type of problem you have a fairly large number of potential issues, see this.
One important difference between IIS5 and IIS6 is that Windows 2003 underwent a significant security lockdown with the SP1 update. There are a very large number of things that worked for Windows 2000 that just will not in 2003 (and should not have - they opened the door to all sorts of shenanigans). Trying to track down all the places where IIS6 locked stuff down might be challenging, instead I would use the above resource to track down the common issues people are running into with IIS6.
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.