Intune Compliance Policy Breaks Windows AutoLogin

EAS Policy applied by Intune Compliance Policy

Intune Password Compliance Policy breaks AutoLogin configurations by applying Exchange Active Sync (EAS) policies

I came across this issue after deploying Intune enrollment and compliance policies to a large group of pilot machines. I'm writing this to hopefully save someone else the days it took me to piece all this information together.

TLDR Fix at the bottom of this post

We were poised to move out of pilot and enroll the remaining systems in the company when we were notified that we have a shared kiosk style PC that had AutoLogin configured, and stopped working after being enrolled into Intune. If the AutoLogin configuration was set back up it disappeared again shortly after or after a restart breaking it again. This caused us to place the remaining rollout on hold until we could Identify what was going on.

Researching the issue seamed to point to an EAS policy being applied but we couldn't figure out from where. Microsoft documentation has a note specifying EAS policy breaks AutoLogin After finding this note we confirmed the affected computer as well as other computers enrolled into Intune did indeed have the following EAS registry keys.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS\Policies]
"1"=dword:00000001
"2"=dword:0000000e
"5"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS\Policies\MDM]

We confirmed that if you deleted the EAS registry keys AutoLogin would work, but they would return again. After a few more days of researching the issue, and after opening a case with Microsoft Intune support I found the following Tech Community post that seemed to line up with the same issue we were facing. Problem with AutoLogin on multi app Kiosk Win 10. This post appeared to point the finger at an Intune Compliance Policy that was checking for password requirements and device lock settings. I double checked and yep we had one applied to all the systems in the pilot. Removing the Compliance policy did not remove the EAS Registry settings, they still needed to be removed by manually deleting the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS.

We enrolled a few more test systems after removing the password compliance policy, both of the test systems never received the EAS registry keys even after a long weekend of being online. Felt pretty confident the Password Compliance Policy was the original cause of the problem.

Unfortunately, the 2 test systems had some of the EAS Registry keys re-appear even after validating the Compliance Policy was completely removed. Although this time the the keys didn't include any actual settings:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS\Policies]

This again broke the AutoLogin.

After more researching and digging I was pointed at another registry location that contained some policy configurations for Intune HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\. Inside this registry key I found another key called DeviceLock. I verified that my 2 test machines that were still broken both had this key, and my 2 test machines enrolled after the compliance policy was removed did not have this key. The Key contained the following registry settings:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock]
"DevicePasswordEnabled"=dword:00000001
"AlphanumericDevicePasswordRequired"=dword:00000002
"MinDevicePasswordComplexCharacters"=dword:00000001
"MinDevicePasswordLength"=dword:00000004
"AllowSimpleDevicePassword"=dword:00000001

I deleted the entire DeviceLock key on one of the test machines and waited to see if the EAS keys returned. I wrote a little PowerShell script to continually check for the EAS key every 30 seconds and write to the console the time it showed up so I would know if and when it did show up without having to keep checking it manually.

function test ($VALUE) {
    if ($VALUE){
        return $true
    } else {
        return $false
    }
}
$status = $false
$continue = $true
while ($continue) {

$status = test (Get-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\EAS" -ErrorAction SilentlyContinue)
write-output $status

if ($status -eq $true){
    $continue = $false
    Write-output 'Registry Key Showed up at:' (get-date)
    exit
}

start-sleep 30
}

I let this bake for a few hours to see if any of the keys came back. I left it running and locked my PC for the night. When I came back the next morning the console had the following message. It must of showed up right after I locked my PC and walked away for the evening.

Registry Key Showed up at:

Tuesday, June 7, 2022 4:59:00 PM

I thought I was back to square one. I started checking the registry keys, the empty EAS Keys were back, and the DeviceLock key was back but had fewer configured sub keys. However, the configured AutoLogin keys were all still present. So I rebooted my test machine and it attempted to login with the AutoLogin configured account!! The returning DeviceLock key had the following settings configured:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock]
"AlphanumericDevicePasswordRequired"=dword:00000002
"MinDevicePasswordComplexCharacters"=dword:00000001

As expected the other test PC that did not have the DeviceLock key deleted broke again this morning. So we deleted both the DeviceLock and EAS keys on it, set up AutoLogin again, and just waiting to validate this finally fixed it.

TLDR Fix

  1. Remove or exclude PCs from any Intune Password Compliance Policies
  2. Delete EAS registrys keys
  3. Delete DeviceLock registry keys
  4. Configure AutoLogin settings again
    remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\EAS"
    remove-Item -Path "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock"
    

Hopefully this post helps someone out there figure out how to remove this with out a weeks worth of scouring the internet and testing over and over. If you ran into this same issue and this helped you out please let me know in the comments below.