Re: myAutoLogon

From: Kirk Ferdmann (
Date: 02/11/04

Date: Tue, 10 Feb 2004 22:16:11 -0800

"Tim Jowers" <> wrote in message
> Has anyone seen or made an autologon program for Windows that can be
> run from the scheduler or another program?
> I've three several approaches and wonder if anyone can assert or deny
> any. I am running these from a Service.
> 1. Send the username and password to the "SAS Window" - the name of
> the logon window from EnumWindows. Sending ctrl-alt-del to get the
> window works and sending to the one to lock the workstation work fine
> but trying keybd_event, SendInput, and PostMessage do nothing with SAS
> Window AFAICT. This seems to be the approach used by VNC so I wonder
> what I am missing.

The key point: messages are local to a desktop. You can't send a message to
a window on a different desktop. You probably can attach (see
SetThreadDesktop) to the winlogon desktop from the service that runs under
local system account (I never tried to so). You need to so before you send
the message. This looks like a hack to me though. I'd say there is no
guarantee that it will work in the future.

> 2. Tried used LogonUser, OpenWindowStation, SetProcessWindowStation,
> etc. and CreateProcessAsUser on explorer.exe but this does not log the
> user in. Works fine if a user is alreadylogged in though.

It does log the user on, but winlogon/GINA do more then just that: they
modify the default desktop DACL, start userinit, switch to the default
desktop, etc.

> 3. Read up on Gina DLL and downloaded an OS one from xpasystems but
> did not see that their Geni replacement DLL would provide what I
> needed. Do I really have to redo the Windows security to get this to
> work? Do I need to make a stub or do I have to make a complete Gina
> DLL?

GINA would be a recommended way to extend the existing security
infrastructure. I guess you can get away with GINA stub in this case:
1. cache the WLX table
2. communicate from your service to the DLL using some IPC (DCOM, RPC, MMF,
3. issue your own type of SAS from the stub
4. handle your own SAS without forwarding it to the original GINA
5. for all other calls just forward the call to the original GINA