1

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>
David
  • 13
  • 3

3 Answers3

0

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.

Mitch
  • 21,223
  • 6
  • 63
  • 86
  • With your solution, don't we end up log off at the end of the procedure? Auto logon only execute the first time, I believe, as else we would not be able to change session. And yes, this is insecure : in it's very nature. It is a bypass and a attempt to have the benefice of having a password and not having it. As for being able to look up the password in the registry second commenter address that. (There for, after you commented, so no chamming you or anything.) – David Jan 04 '22 at 14:11
  • The custom shell would either clear the autologon keys (in which case you would be left at the login screen) or set them to the actual user’s login info (which would trigger as soon as the custom shell logs off). – Mitch Jan 04 '22 at 14:52
0

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

  1. Add you script to the computer startup scripts
    • Computer Configuration\Windows Settings\Scripts (Startup/Shutdown)
    • Startup (add your powershell script here) computer startup script
  2. Enable the synchronous processing of startup scripts
    • Computer Configuration\Administrative Templates\System\Logon ->
    • Always wait for the network at computer startup and logon: Enabled Synchronous startup script

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.

ZivkoK
  • 366
  • 3
  • 6
  • Look like there was a misunderstanding: the key is change when I look it up in the registry, but it feel like it is done after auto logon execute. Which defeat the purpose of what I am trying to archive there. As the first time the state of the condition (true | false) change windows will still act as if it wasn't. Oh! and I did manually set DefaultUserName and DefaultPassword as they wouldn't change. Forgot to include that. Also, thanks for the AutoLogon tool. It was a flaw in my planning that I had yet to iron out. – David Jan 04 '22 at 14:25
  • SysInternals AutoLogon is good idea! – Alexander Jan 04 '22 at 15:54
0

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.

Alexander
  • 1,232
  • 1
  • 15
  • 24