none
Global policy for new "Use my sign-in info to automatically finish setting up my device after an update or restart"?

    Question

  • Is there a local or group policy that will allow me to control the default for the new "Use my sign-in info to automatically finish setting up my device after an update or restart" setting in Windows 10 RS3 / 1709 build 16251 and later, as opposed to having to visit the opt-out on each individual user account?

    This feature is causing an issue for an application which didn't expect "an interactive Windows user logon session already exists for this, even though no credential provider instance in any terminal session has been used to create a new interactive Windows user logon session yet."  i.e. The fact that this user gets "logged on" in some manner that totally bypasses the credential providers creates unintended consequences.

    Rather than having users randomly encounter the errors this creates, and rather than having to remember to disable the feature on every Windows user account created on the machines in the future, looking for the new global policy that may have also been created to control this.

    I have not been able to locate a new policy in GPEDIT or Process Monitor as of yet, so I wanted to also just ask whether such a policy exists.

    Thursday, September 14, 2017 3:48 PM

Answers

  • As finally identified through Process Monitor, the global policy is "DisableAutomaticRestartSignOn" (a.k.a. "ARSO") under the [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System] registry key.

    Since the "DisableAutomaticRestartSignOn" policy itself is not new, I presume what build 16251 and later are claiming to be "new" functionality is that this policy is now used even during "normal restarts", as opposed to just Windows Update-initiated restarts.

    The automatic login itself is apparently implemented by LSASS.EXE's lsass!LsarConfigureUserArso writing a normal AutoAdminLogon policy during the restart request, which is then honored & immediately deleted by WINLOGON.EXE upon reboot.



    • Edited by Alan Adams Thursday, September 14, 2017 4:49 PM Formatting
    • Marked as answer by Alan Adams Tuesday, October 24, 2017 3:35 PM
    Thursday, September 14, 2017 4:49 PM

All replies

  • As finally identified through Process Monitor, the global policy is "DisableAutomaticRestartSignOn" (a.k.a. "ARSO") under the [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System] registry key.

    Since the "DisableAutomaticRestartSignOn" policy itself is not new, I presume what build 16251 and later are claiming to be "new" functionality is that this policy is now used even during "normal restarts", as opposed to just Windows Update-initiated restarts.

    The automatic login itself is apparently implemented by LSASS.EXE's lsass!LsarConfigureUserArso writing a normal AutoAdminLogon policy during the restart request, which is then honored & immediately deleted by WINLOGON.EXE upon reboot.



    • Edited by Alan Adams Thursday, September 14, 2017 4:49 PM Formatting
    • Marked as answer by Alan Adams Tuesday, October 24, 2017 3:35 PM
    Thursday, September 14, 2017 4:49 PM
  • It's cool that you were able to find that with Process Monitor. I suppose setting it in GPO would do the same thing, right?  Computer Configuration -> Administrative Templates -> Windows Components -> Windows Logon Options.

    Method 2 here appears to be another (more complicated) way to do the same thing:

    https://www.tenforums.com/tutorials/49963-use-sign-info-auto-finish-after-update-restart-windows-10-a.html

    For those curious, MS describes the tweak to this feature here (16251+), about halfway down the page. It's really too bad that they glommed the app restart feature onto the original feature, which has to do with completing updates. I'm perfectly OK with that behavior, but hate random apps starting automatically when I haven't set them to.

    https://blogs.windows.com/windowsexperience/2017/07/26/announcing-windows-10-insider-preview-build-16251-pc-build-15235-mobile

    I looked at the new set of policies pertaining to 1709 in the newly-released GPO spreadsheet, and see nothing specifically about this, so I guess the above is it for now.

    Tuesday, October 24, 2017 5:53 AM
  • Yes, the registry key specified is the same registry value that the Group Policy or Local Policy would set.  The "more complicated" approach is the per-user opt-out, which also has both UI and registry configuration available.

    In our specific case, the fact that "ARSO is now used on every normal user restart" was exposing the fact that Windows would perform an AutoAdminLogon as this user /before/ the credential providers were ever even instantiated.

    From a credential provider perspective we were completely expecting AutoAdminLogon support, and do handle "real" AutoAdminLogon scenarios successfully.  But in this ARSO case, the AutoAdminLogon is performed before credential providers are ever even loaded, and the AutoAdminLogon policy itself is deleted from the registry before the credential providers are allowed to load (unlike "real" AutoAdminLogon scenarios).

    There is nothing inherently illegal or wrong about any of that, and "deleting the policy before the credential providers ever see it existed" was probably intentional for some technical reason.

    But it created a logic scenario the credential provider wasn't prepared for.  i.e. "There is already an interactive user's Windows logon session created on this machine for this terminal session, before any credential provider instance has ever been offered the opportunity to log on an interactive user to this terminal session."

    The short-term solution will be to set the global/machine-wide policy to disable ARSO use for all users, both current users and future users.   The long-term solution is to handle exactly the intention ARSO had, which was to "re-establish the logged-on user session" after a restart.  Our credential provider initiates the establishing of network connections for the interactive user session, which the current ARSO mechanism completely bypasses when performing the "non-real" AutoAdminLogon.

    Tuesday, October 24, 2017 3:52 PM
  • Unfortunately, while that works around the problem that you describe, it has no effect on the related app restart feature, despite what the blog post says (I wonder if it did work in 16251 but then stopped working somewhere along the road to 1709).

    I tried both the UI way (on a non-domain machine, which actually had the UI setting available) and the policy way. Good apps to test this with are Task Manager and Registry Editor, both of which are registered to restart.

    So this aspect of it is going to take further digging. Shutdown /r is the only way I know of right now (you'll notice its counterpart, the new Shutdown /g available too, which is effectively what Windows must be doing by default now for restarts performed via the Start menu).

    Tuesday, October 24, 2017 4:25 PM
  • Windows 10: How to stop apps from re-launching after a reboot or shutdown?
    https://blogs.technet.microsoft.com/yongrhee/2018/04/03/windows-10-how-to-stop-apps-from-re-launching-after-a-reboot-or-shutdown/

    Yong Rhee [MSFT]

    Tuesday, April 3, 2018 5:30 PM
  • Nice, but a couple places in the blog you mention 1703. It began in 1709.
    Tuesday, April 3, 2018 5:49 PM