15 thoughts on “A case of the unexplained: Intune password policy and forced local account password changes

  1. Having the same issue. It’s crazy. I’ve spend hours tracking it back and the fact that this cannot be easily disabled is crazy! Especially that Intune itself offers an autologon / kiosk profile. And it does not work out of the box.

  2. This didn’t work or I’m missing something/wrong expectation. Ran the posh script on a test PC and it changed the LSP as indicated but that didn’t change the checkbox on the accounts re “User must change password at next logon”. Still getting EAS message.

    1. The PS script is simply an alternative way to deploy a password policy. It won’t remove or replace a password policy already set by Intune. Once the Intune password policy has applied, I couldn’t find any way to remove it from the device.

    2. I had a similar issue with Teams Rooms where an Intune password policy was once applied and then removed. But the EAS password policy stayed and disabled the Teams Rooms Autologon after every restart. So I have reached out to MS support and they gave me this solution to remove the EAS policy completely, which actually worked for me:

      · Log into your Team Room System.
      · First, let’s “sync” the changes from InTune by going to “Start -> Settings -> Accounts -> Access work or School”.
      · Click on the “Connect to [CompanyName Azure AD] and then click on “Info”.
      · In the “Managed by CompanyName screen”, scroll down and click on “Sync”.
      · Wait for the sync to finish.
      · Now for the fun part: open up the Registry Editor.
      · Go to the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS” key.
      · Under the “EAS” key, delete the “Policies” folder (and MDM sub-folder if it exists).
      · Go to “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\”
      · There will be a folder with a GUID under that “Accounts” key: make a note of the GUID that is shown there. That’s your “EnrollmentID”.
      · Go to “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers” and locate the folder under that key that has the same GUID as your EnrollmentID.
      · Under the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\[ENROLLMENTID]\default\Device\” go to the “DeviceLock” folder.
      · Delete all the keys in the “DeviceLock” folder: keys like “DevicePasswordEnabled”, “AllowSimpleDevicePassword”, “AlphanumericDevicePasswordRequired” should be deleted. Seriously, feel free to delete all the keys in there.
      · Now, this is important, go to the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock” registry folder.
      · This is where the settings from each Policy Provider are copied into and this indicates which settings are currently active! So, you need to delete all the keys you find in there… for example “DevicePasswordEnabled”, “DevicePasswordEnabled_ProviderSet”, “DevicePasswordEnabled_WinningProvider”,  “AllowSimpleDevicePassword”, “AllowSimpleDevicePassword_ProviderSet”, etc, etc… there might a bunch of keys in there to delete so have fun deleting them all.
      · Once your “spring cleanup” of the registry is done, open a command prompt in admin mode.
      · Issue a good ol’ GPUPDATE /FORCE to ensure that the “AdminAutoLogon” and other settings that are supposed to be pushed by your GPO are applied to your domain joined Team Room System and are set correctly.
      · If you want to be paranoid, go back to the Registry Editor and then go to “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon”… and verify that “AdminAutoLogon” is set to “1” and that the “DefaultUserName” user name is set to “Skype” as it should be (as per your GPO).
      · When you are ready, close everything and reboot the Team Room System.
      Finally, over the next few days, monitor the room to make sure the “Auto Logon” thing works correctly.

      So the trick is to delete the keys here:

      I hope it helps you with your issue.

      1. Thanks so much for this information. Here’s a quick PowerShell script to address.

        $enrollmentID = ((Get-Childitem ‘HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\’).Name).Split(‘\’)[-1]

        $deviceLockKeys = @(

        foreach ($key in $deviceLockKeys) {
        Remove-Item $key -Force -ErrorAction Continue

  3. Encountered same issue with ALL our local accounts on PC’s. LapsAdmin and other accounts were all affected by the “Change Password” issue when trying to use them.

    Annoying as heck. Logged a MS Sev A ticket as retail stores is affected.

  4. So funnily enough, a compliance policy from Intune caused this error for me even though I didn’t have any of the password restrictions set with it (thanks Microsoft!). So, all of my computers (over 5oo) are now jacked up with the local accounts. So, that’s fun. But I tried this and still getting the EAS error. I’m just having to result in manually resetting them on all of the machines… yay!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.