The ForceAutoLogon setting doesn’t do what most people think

The folks on the logon team wish me to remind you that the ForceAutoLogon setting does more than just log on an account automatically. They've had to deal with large numbers of people who set the key without really understanding what it does, and then getting into trouble because what they get is not what they expected.

In addition to logging on an account automatically, the ForceAutoLogon setting also logs you back on after you log off. It is designed for machines running as kiosks or other publically-accessible scenarios where you want the kiosk account to be the only account available. Even if the user manages to fiddle with the machine and log off the kiosk user, the logon system will just log the kiosk user back on.

As a result, setting the ForceAutoLogon setting effectively locks out all users aside from the one you are forcing. If you do this to one of your machines, you'd better have some other way of administering the machine. (Typically, this is done via remote administration.)

Comments (12)
  1. BryanK says:

    Or the shift key.


  2. Christian says:

    Long time ago I locked me out of a PC with this (and TweakUI). Had to reinstall the OS (NT4). I wish someone told me about the SHIFT-key.

  3. I guess this is why GNOME (e.g.) has a TimedAutoLogon setting, which gives you a chance to cancel the automatic logon (this time only) and to use a different account.

  4. Clayton O'Neill says:

    I really wish there was some way to say "Log me in automatically once, but lock the screen immediately"

    It’s nice that Windows can delay a lot of the startup stuff into the background, but windows booting isn’t what takes the most amount of time for my machines, it’s applications.  Which gets delayed until I login and I get to wait more.

  5. Eddy Boston says:

    I really wish there was some way to say "Log me in automatically once, but lock the screen immediately"

    Couldn’t you put a shortcut to "rundll32.exe user32.dll,LockWorkStation" in your startup group?

  6. ryanm says:

    Eddy, that will corrupt the stack.  It’s actually invisibly crashing when you do it.

  7. Dean Harding says:

    You could always write your own wrapper which just calls LockWorkStation.

    Personally, I tend to remove everything from my Startup folder (and registry keys, etc) that are not absolutely necessary. Which is most things, really.

  8. Jonathan Wilson says:

    I dont know how they do it but on the machines at work, they have a shortcut in the quicklaunch bar that locks the screen automatically for you.

    So it can be done.

  9. Sec says:

    Whoa. I didn’t know that the rundll32.exe call was actually that bad. I am now using a small C wrapper to lock. You can get it (and the binary) at my blog entry

  10. Eddy Boston says:

    My bad.  Shows you can’t trust Google to answer all your questions for you after all.

    Still, you could write a python script.

  11. Ian A says:

    As I recall ForceAutoLogon didn’t exist in NT we had to reset AutoAdminLogon and the DefaultPassword (if not using LsaStorePrivateData) after every logon if you wished the automatic logon to persist. I guess TWEAKUI did this?

    In NT AutoAdminLogon also worked on new user logon, in Win2K and above it seems that if you just use AutoAdminLogon it will only work on PC restart (even if reset on logon). ForceAutoLogon solves this I am pleased to say.

    On the admin side aside from the Shift option or Remote Admin, on Win2K and above we have the handy (depending how heavily you have locked down the Users desktop) CreateProcessWithLogonW function exposed via ‘RUNAS’ in XP/2003 or for use in your own admin utility.

    Lastly I am curious why you would want to autologon and then lock immediately. I guess you could have UI processes that you wish to run that couldn’t run as Services or Scheduled Tasks? or am I missing something?

  12. Norman Diamond says:

    Thursday, March 09, 2006 3:08 AM by Ian A

    > Lastly I am curious why you would want to

    > autologon and then lock immediately.

    Visual Studio 2005 seems to have put some time-consuming initialization in the user’s logon sequence.  Boot, get half of your coffee, logon, lock, get the other half of your coffee, unlock, start working.  I can’t find it in the startup folder though so the timing might be a coincidence (oddly repeatable though).  Office does put some of its initialization in the startup folder.  Some antivirus programs start their search engines as services but do their updating after a user logs on.

Comments are closed.

Skip to main content