2

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

hw.
  • 790
  • 4
  • 10
  • Well, the reasoning for this is that my client needs an application where he can give out different usernames and passwords to people to access a Windows workstation without giving the actual username and password. The service running on the workstation will login the user for him remotely and the user will continue working on the workstation through a VNC client. This seemed a little odd to me as it is as good as giving access to the Windows user (almost). However, this is what my client wants. – hw. Jul 07 '09 at 11:33
  • Never keep things simple when you can do it the hard way... :-) Anyway, your client wants to access the local system through a VNC connection? Way too complex. There should be easier methods to restrict the user. – Wim ten Brink Jul 07 '09 at 14:28
  • Maybe you should explain the "weirdness" of this design to your client (sounds a bit like a semi-techie manager with a fixation on some technique they read about). A standard Windows login, with "Change password on next login" set, was designed for this sort of thing. The account can also have an expiry, restricted workstation list, limited file system permissions etc. and then just use RDP/VNC. Easy. – devstuff Jul 07 '09 at 14:30

1 Answers1

2

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.

Christopher Karper
  • 583
  • 4
  • 17