The ForceAutoLogon setting doesn’t do what most people think

Date:March 6, 2006 / year-entry #81
Tags:tipssupport
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20060306-08/?p=32053
Comments:    12
Summary: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...

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.

    http://blogs.msdn.com/oldnewthing/archive/2004/01/15/58973.aspx

  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 http://blogmal.42.org/tidbits/windows-xlock.story

  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.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index