Startup script may install to the wrong user, causing UAC to remain disabled, especially in AD (Active Directory) environments

[Degats]

To preface, we came across this issue as boxstarter is now used as part of the latest NodeJS installers, so the user is likely not aware of what boxstarter is, what it's intended for and its quirks.

Expected Behaviour:

As I understand it, (correct me if I'm wrong) if boxstarter is installing prerequisits or otherwise needs to reboot before completion, it will/can attempt to do the following:

1. Disable Windows Update (maybe)
2. Disable UAC
3. Save a script in the "Startup" directory of the (elevated) user running boxstarter
4. (Force) reboot the machine
5. (Attempt to) auto-login, causing the startup script to run
6. Script installs what it needs to, then:
7. Re-enable UAC
8. Re-enable Windows Update (if 1 happened)
9. Delete's the startup script.

(The order of 1-3 and 7-9 may actually be different, but that's irrelevant for the purposes of this issue).

Scenario we encountered:

• "NormalUser" running boxstarter does not have local administrator rights (following best practises)
• "NormalUser" uses UAC to elevate to the "LocalAdmin" AD Domain user in order run boxstarter
• As part of the installation, boxstarter triggers a machine reboot, and "NormalUser" logs back in as normal when prompted by windows.
• boxstarter installation does not continue.
• "NormalUser" discovers he can no-longer elevate to another user to manage Domain resources, run Task Manager or Powershell as admin etc. and is unable to re-enable UAC because of it.
• He then logs out of "NormalUser" and logs back in to the machine as "LocalAdmin" (which luckily happens to be the account used to elevate boxstarter)
• boxstarter script runs, completes the installation and cleans up by turning WU and UAC back on.
• I hear an exclamation from the other side of the office about this weirdness ;)

To finish the installation and clean up, you need to log in to the system using the account that was used to elevate the original installation (LocalAdmin).

Under certain circumstances, especially in an AD environment, this may not be possible (although I haven't yet had chance to test to be sure):

• There may not have been a LocalAdmin profile for the startup script to be installed to if:
  • LocalAdmin had never logged into this machine before and therefore the profile had never been created
  • The Group Policy setting "Delete user profiles older than a specified number of days on system restart" is configured and LocalAdmin hasn't logged in within the timeout, therefore the profile had been previously deleted.
• LocalAdmin does not have the "Allow log on locally" security policy right granted, and therefore can't create an interactive session for the startup script to be called.

Security issues/side effects:

• In the scenario above, LocalAdmin is running everything elevated until the system is rebooted again (even in other scenarios when boxstarter is used & working as intended); changing the UAC setting requires a reboot to apply properly and even if boxstarter triggers another reboot after finishing, all other programs have been running elevated.
• If UAC remains disabled and a different local administrator logs in, all their programs will be running elevated, potentially without their knowledge.
• It is also possible (if unlikely, but weird combinations can happen especially under AD) for a user with local administrator privileges ("LeeroyJenkins" sounds appropriate) to elevate the boxstarter installation as a different user "LocalAdmin". This would also cause the installation to not continue after reboot, leaving UAC disabled. However in this case, as "LeeroyJenkins" is a local admin, all software they (and any other user with local admin rights) run is now automatically elevated, until either someone notices UAC is disabled or "LocalAdmin" logs in to finish the installation and clean up.

Notes

While this is vastly more likely to be a problem in an AD environment, it is still possible to happen on other machines as Group Policy still exists locally.
If you need a log file for this, let me know and I'll see what I can do.
Raising this issue as requested in #358

[MPagel]

my +1 to this scenario is here: nodejs/node#23987 (comment)