XP multiuser default login

[4wd]

Hi all, I have a friend with XP Pro who wants to set up another user on his system so there's a choice when the Welcome screen pops up but also have it log in as one of the users after a suitable delay.

eg. You get to the Welcome screen with a choice of UserA or UserB but if there's no input after 30 seconds then it'll default to UserA.

Is that possible under Windows?

I know you can set a automated login but there's no way to delay it AFAIK.

Or is it possible to set a login using a specific user account via the boot.ini menu?

That way you get your delay but skip the Welcome screen.  Just had a quick look but couldn't see any relevant parameters.

[Stoic Joker]

Is that possible under Windows?

My guess would be no. It will (most likely) run into the same roadblocks the WiFi detector project ran into.

I know you can set a automated login but there's no way to delay it AFAIK.

Nothing native I'm aware of either.

Or is it possible to set a login using a specific user account via the boot.ini menu?

Outside of a 2nd OS that was set to auto-login, no.

[Carol Haynes]

For normal autologin add this to your registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DefaultUserName"="User Name"
"DefaultPassword"="password"
"AutoAdminLogon"="1"

replacing user name and password with the actual auto login details.

See http://support.microsoft.com/kb/315231 for full details.

Don't know of any way of delaying it though.

I suppose you could write a script that you add to scheduled tasks that runs on system startup waits for so long and then logs in if no one has logged in.

[f0dder]

Well, it would be possible to do, even if there's no current supported method - who's up for writing a custom GINA?

[Stoic Joker]

Well, it would be possible to do, even if there's no current supported method - who's up for writing a custom GINA?

I ran across something (article on TechNet) a while back (wish I could remember where) that said that MS had depricated the GINA in favor of something new in Vista & 7. This change also affected XP some time after SP2.

I do recall it being tied into the (for security) services/session 0 isolation changes.

[4wd]

Thanks for the answers folks.

<Technogeek warning> 
@SJ: Well actually, the problem with the WiFi Detector is it wouldn't run on subsequent logons, (initial was OK), and I don't believe that will be a problem here because I'm pretty sure it's only for the initial machine power on logon that it's required.  I'll have to ask him.

Thanks for reminding me SJ, if I can get it to just send mouse movements, LMB click, put a password in the keyboard buffer and then exit then it should work.  Test for mouse movement during timeout will signify someone's driving the machine and cause it to exit.

Hard part will be working out the location of the logon icons, a fair bit of trial and error, but maybe work it out for one resolution and then possibly use a ratio for other resolutions.

Fun, fun, fun - back to the AutoIt blackboard.

[f0dder]

Hm, I do wonder if that kind of approach would work for the logon screen, 4wd - it's designed to run with some different constraints than regular applications.

[4wd]

Yes, it'll be interesting to see - however that was one of the strange things I found when I was trying to get the WiFi Detector working.

For some reason I was able to interact with the initial Welcome screen, (ie. putting a tooltip on it), but not with any subsequent Welcome screen after the user logged off even though the program was started at logoff, (or after logoff using the AT command).

I would of expected not to be able to interact with the Welcome screen at all.  Even AutoIt isn't designed with this kind of thing in mind but it still did it, (on the initial Welcome screen anyway).

So my thinking is if I can get a tooltip on the Welcome screen, which I shouldn't be able to, then getting the mouse to move should be easy....FLW.

Anyway, if I come up with something I'll let you know.

UPDATE: Well it works, I can get it to logon after a delay using AutoIt to click on an area - now I just got to work out my ratios so it'll work with different resolutions.  Probably have to use a look up table of some kind depending on number of users vs offsets.

[Stoic Joker]

Hm... While we got f0dder here ... ...What about testing for the logon window name, sending the u/p directly to the appropriate fields, and then posting the LBM message directly to the windows message queue? Would that be easier/more reliable (no different resolutions move targets issues), or just harder to pull off?

[f0dder]

SJ: that shouldn't be possible - at least not directly. Winlogon runs on a separate desktop (the NT object type, not "background where your wallpapers go").

If you elevate your application to LOCALSYSTEM privileges, everything is possible, but that's nasty hackery.

[4wd]

What about testing for the logon window name, sending the u/p directly to the appropriate fields, and then posting the LBM message directly to the windows message queue?

That's only going to work for Classic logon though isn't it, (where you type in a user name)?

Pretty sure my friend's only interested in using the Welcome screen.

Forgot to mention, I haven't tried to send a password into the prompt yet because I completely forgot 
I was just testing with two non-password accounts but I just tried it with a password and it worked.

If you elevate your application to LOCALSYSTEM privileges, everything is possible...

I'm running it from gpedit->Windows Startup script so it already has SYSTEM privileges, (I believe), or is LOCALSYSTEM a little/lot different?

[Stoic Joker]

SJ: that shouldn't be possible - at least not directly. Winlogon runs on a separate desktop (the NT object type, not "background where your wallpapers go").

If you elevate your application to LOCALSYSTEM privileges, everything is possible, but that's nasty hackery.

<I could be off base, but I think we're talking about a service, not an application>

True, but once you go down the interact with the login desktop road, you have to be on it to interact with it. So why not just cut to the chase and access the login window directly?

If you got to be there to get there why not act like you belong there? Ya know?

[Stoic Joker]

What about testing for the logon window name, sending the u/p directly to the appropriate fields, and then posting the LBM message directly to the windows message queue?

That's only going to work for Classic logon though isn't it, (where you type in a user name)?

Pretty sure my friend's only interested in using the Welcome screen.

Welcome screen should also be a window (of sorts), and considering it is rather mandatory on the newer OS's it's probably worth considering (...Then again I should probably consider being quiet )

Forgot to mention, I haven't tried to send a password into the prompt yet because I completely forgot 
I was just testing with two non-password accounts but I just tried it with a password and it worked.

That would seem to imply you are in the right place.

Damnit I wish I had time to play with this (office has me pinned to the wall).

[4wd]

Forgot to mention, I haven't tried to send a password into the prompt yet because I completely forgot  
I was just testing with two non-password accounts but I just tried it with a password and it worked.

That would seem to imply you are in the right place.

Damnit I wish I had time to play with this (office has me pinned to the wall).

Using GetDesktopWindow() I seem to get a consistant handle of 0x00010004, (IIRC), for the Welcome screen, now if I could only work out how to get the icon objects on it....

Of course, using the Classic logon would probably be a lot easier, just needing to send a load of key codes...but, naturally, my friend would rather use the Welcome screen  

UPDATE: OK, bearing in mind I'm just playing in a VM and are stuck with 4:3 modes, the Welcome screen user icons are remarkably consistent in their positioning, (only tested up to 3 users so far).
The centre of the icons are located 60 pixels right of the screen centre and have a horizontal spacing of ~80 pixels, this is from resolution 800x600 -> 1280x960.
So given the location of the first icon, (using a simple lookup table), the position of those below can be calculated fairly easily.

Given the target is a two user system, this is pretty much solved only needing to be tested with wide screen modes to see if the spacing is significantly different.

In all cases the handle for the screen is 0x00010004, if I knew which process was responsible for placing of the icons it might be possible to make it a bit more intelligent.  I thought it was logonui.exe but I can't seem to get the GUI resources it might be using.