Boxstarter should only modify UAC level, never disable UAC completely #581
Labels
0 - Backlog
Issue is accepted, but is not ready to be worked on or not in current sprint
Improvement
Issues that enhances existing functionality, or adds new features
Checklist
Is Your Feature Request Related To A Problem? Please describe.
Whenever Boxstarter re-enables UAC after it triggered a reboot the UAC is in a 'foggy state' - ignoring ConsentPromptBehavior etc.
In order to bring the host to a clean state again the host needs to be rebooted again.
This 'final reboot' cannot be done from Boxstarter since the reboot would not be a fenced login/suspended bitlocker etc.
This default behavior is currently wanted, since we cannot assume the user has physical access to the machine that runs Boxstarter, therefore we can only do 'fenced reboots' that wind up in a session again.
We could add an option to force a reboot in order to re-enable UAC to a clean state if Boxstarter ever did a reboot during its operation, but this should not be required when this issue is being implemented (and only
ConsentPromptBehavior
is modified while UAC stays enabled all the time).Describe The Solution. Why is it needed?
In brief; iff UAC is enabled, set the property
ConsentPromptBehaviorAdmin
to 0.(!MIND @pauby 's comment below: if it's running on Windows Server 2016 or newer, this won't work on previous releases - we'll need to keep the current mechanism in place for those older OS versions)
This will cause Windows to allow privileged actions without prompting.
https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#registry-key-settings
Then to be sure that your tasks are launched in an elevated shell you can do:
Related Issues
Idea Originally posted by @SuperFlue in #358 (comment)
The text was updated successfully, but these errors were encountered: