Changing Registry\...\Winlogon\AutoAdminLogon before auto logon execute - windows

Question

The situation/context/intent
I try to run a task (on windows 10) which activate or deactivate auto logon depending on the NetConnection name (to see if I am home). The script works and is executed, but I guess the task is too late, since auto logon use the pre-existing value over the one set by the script. Or, is it that the script is delayed by the Wi-Fi, which maybe still launching, allowing auto logon to do its things or something like that?
What I tried
Well first, I look on the internet, but all I could find was how to activate auto logon and nothing near what I try to do.
Then, on stackoverflow, I did found something call gina.dll. Turn out, it has bean replace by credential provider. Which look like an aventure better avoided and, I think, it is just the interface to logon anyway.
Then I tried to use the event, kernel-Boot id 30, which, should be monitoring the start up process. "Maybe this would be earlier than the default startup", I thought. But, I observe the same result as with "on startup". (Maybe it is the same thing as "on startup".)
The script (PowerShell)
$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
if((Get-NetConnectionProfile | select -ExpandProperty Name) -ceq "The connection name"){
Set-ItemProperty $RegPath "AutoAdminLogon" -Value "1" -type String
}else{
Set-ItemProperty $RegPath "AutoAdminLogon" -Value "0" -type String
}
The exported task
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2022-01-02T17:37:14.7356723</Date>
<Author>LAPTOP\admin</Author>
<Description>Connexion automatique à admin</Description>
<URI>\Tâche personalisé\Connexion automatique</URI>
</RegistrationInfo>
<Triggers>
<BootTrigger>
<Enabled>true</Enabled>
</BootTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>I probably do not want that out there</UserId>
<LogonType>Password</LogonType>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>StopExisting</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>false</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
<UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT1M</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>PowerShell</Command>
<Arguments>C:\ScriptPersonnalise\ConnexionAutomatique.ps1</Arguments>
</Exec>
</Actions>
</Task>

Answer 1

Sorry David, my mistake, I didn't get your point. You were perfectly right with your analyse.
But You won't be able to do what you want by using scheduled tasks. Even when configured at boot time, the scheduled task/script will be execute after the processing of AutoAdminLogon by the system.
For your script to be executed before the system gets there, you need to use Group Policies. Two thing to do:
Start Group Policy Console by running gpedit.msc
Add you script to the computer startup scripts
Computer Configuration\Windows Settings\Scripts (Startup/Shutdown)
Startup (add your powershell script here)
Enable the synchronous processing of startup scripts
Computer Configuration\Administrative Templates\System\Logon ->
Always wait for the network at computer startup and logon: Enabled
Et voilà!
consider using a tool from SysInternals called AutoLogon that can help you achieve your goal in a slightly more secure way as it allows you to use an encrypted password.

Answer 2

Starting with the obvious comment of this being insecure, you could likely default autologon to a second account with a custom shell. The custom shell would wait for network, update autologon appropriately, the logoff.

Answer 3

As far as you define the environment of Windows 10 and knowledge of plain tex username/password you can implement your own Credential Provider.
Your provider will be called for ICredentialProvider::SetUsageScenario and ICredentialProvider::GetCredentialCount.
This time you can take a decision to do autologon or not.
As a result of your evaluation you may return TRUE at pbAutoLogonWithDefault parameter.
Later your provider will be called for ICredentialProviderCredential::GetSerialization where you can serialize username and password.