I am trying to remove the windows logon screen (winlogon) from an executable launched from a service. The service would start automatically with windows and wait for commands from another computer. When it receives a command, it will launch an exe which will start cmd.exe under a particular username.
The service is already present. I have the job of writing this executable. Currently, I have written the executable (CmdLogin) which starts cmd.exe under a different user through calls to LogonUserW, ImpersonateUser and CreateProcessWithLogonW. I specify lpDesktop as "WinSta0\Default". The only catch is that the service must run under an administrator account (but that is a different problem).
This works perfectly fine when called from a command prompt (even on Windows 7). This also works when called from the service when a user has logged on and viewing his desktop (like I do when debugging on the same machine). However, like I said above, my real requirement is for this to work even when the windows logon screen is displayed. Currently, the exe gives a proper exit code but the window does not appear. However, when the user logs in, he sees the cmd window on the desktop.
One solution I found was to use "WinSta0\WinLogon" for lpDesktop instead of Default. I am yet to try this. However, this looks like it will show the cmd window right over the login screen. What I really need is to actually emulate the user login to winlogon and show his actual desktop (and the cmd window).
I looked around and found GINA and Winlogon Notification Packages. They seem like an overkill and I am not sure if that will even solve the purpose here. Moreover, these are deprecated in Windows Vista which makes me think there is a better and neater method to solve this.
Any suggestions on what should I use to achieve this? For the record, the executable is in C# with API calls using P/Invoke. I am open to using a C dll that I can call from this C# application too.
Thank you,
Husain
Best Answer
GINA has been superceded in Vista/2008 by Credential Providers (not available in managed code).
I don't know how to do what you need, but perhaps this is a clue to go further down the trail.
And for the record, this seems like the wrong way to address the problem. I just don't see how you would need to run a command prompt under an auto login... Why not write a service to do your tasks, and have it run under a set of service specific credentials?
I don't have the background on your problem, but this description makes me shudder. :-)
[Update] Well, in response to your comment. I would say that writing a GINA replacement for <= Windows 2003, or a custom credential provider for Vista/2008+ would look to be your best option.
You can provide custom authentication against his credential store, then allow or deny the login as you see fit.