Having a password policy is a best practice for security of accounts, whether domain, local or wherever passwords are used. In the Windows world, domain accounts have a default domain password policy. Azure AD accounts have the Azure AD password policy. Accounts local to Windows can have a password policy too, and you can use Intune to set this if you want. In fact, if you deploy the Windows 10 Security baseline in Intune you will be deploying a password policy to your local accounts.
However, deploying a password policy on Windows with Intune can have an unexpected side effect: it can force a local account to change the password at next logon:
If you regular rotate the password for the local administrator account using a LAPS solution, for example, this becomes a right royal pain because password rotation will fail due to the requirement to change the password at next logon.
I first came across this issue when doing Windows Autopilot deployments. Our password rotation solution would fail to rotate the password on the local admin account on some machines. After some lengthy investigation with Microsoft, we discovered there was a compliance policy created in the old Silverlight Intune portal (which we could no longer access) and targeted to these users that was setting a password policy. Compliance policies created in the new portal in Azure override the policies in the old portal, but since no new compliance policy was created for Windows 10, the old policy was still in effect and was causing this issue.
Later I came across this again when rolling out the Windows 10 security baseline in Intune, which by default has a password policy. I noticed that our password rotation solution was failing on recently deployed Azure AD-joined devices, after we enabled the baseline.
What’s going on?!
So why does this happen? Well, when Intune sets a password policy it uses the DeviceLock policies in the Policy CSP. Under the hood, this is using the Exchange Active Sync policy engine to set the password policies, which was created back in the Windows 8 era to enforce some security policies on devices that sync with Exchange. Reading through the documentation, you come across this little nugget:
When password length and complexity rules are applied, all the control user and administrator accounts are marked to change the password at the next sign in to ensure complexity requirements are met.
All you have to do is enable a password policy and some default values will get set for password length and complexity, and these polices will require that a local administrator account change its password at next logon. The reason is that the policy doesn’t know if the currently set password meets the requirements of the policy. The only way it can be sure it complies is to force you to change it, and the new password must meet the policy requirements. In this way it can truthfully report whether the device is compliant to the policy.
Sounds reasonable, but forcing the password change breaks your LAPS solution as you cannot programmatically change the password, or even remove the requirement to change the password at next logon – you’ll get some nice errors if you try.
Logon Failure: EAS policy requires that the user change their password before this operation can be performed
When a password policy is set by Intune, you’ll see some registry keys set under HKLM:\Software\Microsoft\PolicyManager\current\device\DeviceLock.
You’ll also see some Exchange Active Sync keys set under HKLM:\System\CurrentControlSet\EAS\Policies
Once the EAS policies have applied, I could not find any way to override them. Removing the Intune password policy, deleting the EAS registry keys – for me, nothing worked. I still could not programmatically change the local admin password or remove the requirement to change the password at next logon.
The only thing that worked is to satisfy the policy – ie actually log in as the local administrator and change the password when prompted, or log in as another administrator account and use Local Users and Groups to change the password.
I should emphasise that this only affects local accounts, not domain, and the issue was not seen consistently on all machines where the security baseline was applied – it seemed to affect new or recently deployed machines – even those where password rotation had previously occurred successfully.
Since having to manually and interactively change a local admin password is not a feasible option at scale, I simply cannot recommend to use Intune to set a password policy if you are using a password rotation solution. Remember that a password policy can be set in different places in Intune – as part of a Windows 10 security baseline, as a configuration profile, using OMA-URIs directly, or with a compliance policy.
Is there a fix?
A workaround that has been successful for me is to use secedit to set a password policy for local accounts. This ageing utility still works nicely to deploy a local security configuration and it doesn’t use EAS policies so it doesn’t force local accounts to change their passwords to comply with the policy.
You can open secpol.msc on a test machine and set the password policy as you desire:
Then from an admin cmd, run secedit to export the configuration:
secedit /export /areas securitypolicy /cfg C:\Temp\seceditexport.txt
Open the text file and copy the parts of the policy that you want into a PowerShell script like so:
$INF = @"
[Unicode]
Unicode=yes
[System Access]
MinimumPasswordAge = 1
MaximumPasswordAge = 180
MinimumPasswordLength = 8
PasswordComplexity = 1
PasswordHistorySize = 24
LockoutBadCount = 10
ResetLockoutCount = 60
LockoutDuration = 1440
RequireLogonToChangePassword = 0
ForceLogoffWhenHourExpire = 0
[Version]
signature="`$CHICAGO`$"
Revision=1
"@
$null = New-Item -Path "$Env:SystemRoot\security\database" -Name secpolicy.inf -ItemType File -Value $INF -Force
$Process = Start-Process -FilePath Secedit.exe -ArgumentList "/configure /db secedit.sdb /cfg $Env:SystemRoot\security\database\secpolicy.inf /overwrite /quiet" -NoNewWindow -PassThru -Wait
$Process.ExitCode
Deploy this as a remediation script using Proactive remediations in Endpoint Analytics, or an MEMCM compliance item using a dummy detection method to ensure it runs regularly.
Just be careful to avoid policy conflict by only including security configurations (like password policy) that are not being set elsewhere, as for example the Windows 10 Security baseline in Intune will also set local account security policies.
May your services always be up, code always compiles and beer always be cold. You just helped me immensely.
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.
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.
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.
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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EAS
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\[ENROLLMENTID]\default\Device\DeviceLock
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock
I hope it helps you with your issue.
Great info, thanks for posting.
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 = @(
‘HKLM:\SYSTEM\CurrentControlSet\Control\EAS’
“HKLM:\SOFTWARE\Microsoft\PolicyManager\Providers\$enrollmentID\default\Device\DeviceLock”
‘HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock’
)
foreach ($key in $deviceLockKeys) {
Remove-Item $key -Force -ErrorAction Continue
}
Did you find a fix for this?
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.
Hi Mario . Did you finally get a resolution from the MS Sev A ticket ? Please share thanks
Hey there, I end up just resetting the local passwords and implemented LAPS
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!
Ouch!
This is still a problem as of today. Does anyone know if there is any updated fix?