Windows Autologin stopped working

Do you ever find yourself troubleshooting why autologin has stopped working on Windows?

There is a series of devices that require to autologin. These are usually Kiosk devices, or Monitoring Boards, TVs etc etc.

Randomly the devices that needed autologin all stopped working. Around about the same time. We checked the usually suspects (Did someone lock the account again?) Did we apply a new security policy that blocked it? Did a Windows update break it.

Lets take a step back and remind ourselves how Auto Login works. The key requirements to make the Auto Login work are

1. A working username and password. (AD user or local user )
2. A Windows device. ()
3. The following registry keys set

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DefaultDomainName"="timstechblurbs.local"
"AutoAdminLogon"="1"
"DefaultUserName"="AutomationUser"
"DefaultPassword"="ALongAndComplacatePAsswordNoOneCanRemeber"
"AltDefaultUserName"="AutomationUser"
"AltDefaultDomainName"="timstechblurbs.local"
"ForceAutoLogon"="1"

If we have all of these set the PC should auto login.

Where is the problem?

The Auto Logins stopped working. After re adding the keys, it didn’t help. The DefaultPassword key was deleted and the ForceAutoLogon was set to 0. Something is changing this.

We spun up ProcMon with Boot Logging enabled and started digging into the results. It looks like LoginUI is delete the Keys during shutdown

A Further check of the Event logs show and EAS Policy is responsible. But why. (These accounts don’t have mailboxes.)

We dig and dig, to find there is no mail, nor a reason to connect to Exchange online. We delete the policy and it comes back after a few hours.

How does Intune fit into this?

All the devices are enrolled in SCCM, and AAD Hybrid join and enrolled into Intune. In testing, we deleted a device from Intune and blocked enrolment. They AutoLogin keys stayed and the EAS Policy was removed.

After checking the Configuration Polices applied in Intune, we found no culprits. We already exclude the device from most of the Intune Polices.

However when checking the Compliance polices, we are setting minimum Password length. We have found our problem!!!

But wait. We aren’t applying the Compliance policy to any devices, and the autologin users usually aren’t Synced to AAD? Turns out our assumption was wrong. The user were Synced to AAD and the compliance policy was set to All users. There our problem.

How can we fix this

First things first. Lets exclude the Auto Login users from the compliance policy and sync the device. It can take hours / days for the policy to be removed from the device status.

Then added the autologin keys back to the device and waited in the hope that this problem is solved. Unfortunately the problem returned shortly after.

Turns out Intune does a very good job of caching settings on the device and will keep them there.

You either need to

1. Delete the device from Intune, and let it Re enrol.
2. Set up a new compliance policy removing the settings.
3. Manually intervene, find and delete the keys. and Script the fix.

I chose the 3rd option. There are too many computers to remove them from Intune. We don’t want a compliance policy set up that could be applied in the wrong place. I set up the fowling script to delete the keys, Add the autologin back and to Sync with Intune.

### 
# Reset the Device Auto Login after device is joined to AAD and Intune
# Ensure the Complance Policy is not set on the device. Otherwise the problem 
# will come back in a few days
###

param ([String] $LoginUser = "AutomationUser"
, [String] $LoginDomain = "timstechblurbs.local"
, [String] $LoginPassword = "ALongAndComplacatePAsswordNoOneCanRemeber")


$NodeCacheKeys = Get-ChildItem -path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\NodeCache\CSP\Device\MS DM Server\Nodes\' -recurse -erroraction silentlycontinue | Get-ItemProperty | where {$_.'NodeUri' -like "*/DeviceLock/*"}    

foreach ($key in $NodeCacheKeys)
{
        Write-Host $key.PSPath
        Remove-Item -Path $key.PSPath -Recurse -WhatIf
}

$PolicyKeys = Get-ItemProperty -path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock\' -erroraction silentlycontinue 

Write-Host $PolicyKeys.PSPath
Remove-Item -Path $PolicyKeys.PSPath -Recurse 


$EASKeys = Get-ItemProperty -path 'Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS\Policies' -erroraction silentlycontinue 

Write-Host $EASKeys.PSPath
Remove-Item -Path $EASKeys.PSParentPath -Recurse


Get-ScheduledTask -TaskName "Schedule to run OMADMClient by server" -ErrorAction Continue | Start-ScheduledTask

Set-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name DefaultDomainName -Value $LoginDomain
Set-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name AltDefaultDomainName -Value $LoginDomain
Set-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name AutoAdminLogon -Value "1"
Set-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name ForceAutoLogon -Value "1"
Set-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name DefaultUserName -Value  $LoginUser
Set-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name DefaultPassword -Value $LoginPassword