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.