← PS C:\Blog\rksolutions> cd ..

macOS LAPS vs. Intune Password Compliance Policy: Why It Breaks

· 7 min read ·
Intune Compliance Security M365

A user needs to turn on screen sharing for Microsoft Teams in System Settings (just one of many app permissions that need an admin to approve them), but macOS pops the padlock and demands an administrator. They do not have one, so it lands on your desk. You pull the managed admin (LAPS) password from Intune, take over the device, and paste it in. It bounces. You try again, slower this time, convinced you fat-fingered it. Still nothing. By the third attempt you are no longer sure the managed admin account even exists on this device.

The password is correct. It is the exact value Intune generated and stored. macOS is rejecting it anyway, because something told Open Directory that this account needs to change its password before it can authenticate. Unless you deliberately turned on “Change at next authentication” (in which case this is expected), that “something” on current macOS is almost always a compliance policy carrying password settings.

This post is a snapshot of behavior I have reproduced in test environments running macOS 26.5.x. Apple’s Open Directory enforcement can change between releases, so re-test on your own build before assuming any of this still applies.

Table of Contents

What macOS LAPS actually does

When a Mac enrolls through an Automatic Device Enrollment (ADE) profile that has the local admin account option turned on, Intune provisions a managed administrator with a strong random password, stores it encrypted, and rotates it automatically on the schedule you configure. You retrieve the current password from the Intune admin center under Devices > macOS devices > the device > Passwords and keys.

That managed admin sits on top of Open Directory (OD), the macOS subsystem that owns local accounts and their password policy. This matters, because OD does not treat the LAPS admin as special. Any passcode rule that lands on the device applies to every managed account, the LAPS admin included. That single design fact is the root of everything below.

How you notice the problem

There is no error popup that says “your compliance policy invalidated the LAPS password.” You find out the hard way: an admin authentication prompt rejects the stored password. Installing a package, changing a protected setting, unlocking a system preference, anything that elevates, fails as if you typed the wrong thing.

To confirm it is the account and not your typing, open Terminal on the Mac and authenticate directly against Open Directory:

% dscl . -authonly <admin-name> '<password-from-intune>'
<dscl_cmd> DS Error: -14161 (eDSAuthNewPasswordRequired)

A healthy account returns nothing and exits 0. The error name is the tell: eDSAuthNewPasswordRequired means Open Directory recognizes the credential but will not let the account authenticate until its password is changed. That is what separates this bug from a genuine typo, where you would instead get eDSAuthFailed (-14090). The password is correct; the account is flagged.

Why it happens: compliance policies enforce, they don’t audit

Here is the mental model that trips people up. A compliance policy looks like a read-only health check: it inspects the device and reports a verdict back. It is not. When a compliance policy contains password settings, Intune pushes those rules to the device and macOS enforces them. The compliance engine is policy-applied, not policy-read.

Microsoft says this plainly in its macOS LAPS documentation:

“Password settings configured through compliance policies or device restriction templates enable Change at next authentication by default and can cause sign-in issues for newly created LAPS accounts.”

Microsoft Learn - Configure macOS ADE local account configuration with LAPS

So a compliance policy that merely checks for a password also flips on Change at next authentication, and OD enforces that flag against the LAPS admin. The freshly rotated password is, from OD’s point of view, a password that must be changed before it can be used.

What makes this so easy to miss is that most admins mirror their password requirements in a Settings Catalog configuration profile as well. The compliance policy and the config profile look consistent, the same length, the same complexity, so nothing looks like it is in conflict. The compliance policy’s hidden side effect never draws attention until the managed admin stops authenticating.

This is the shape that causes it, expressed as the macOS compliance policy resource:

{
  "@odata.type": "#microsoft.graph.macOSCompliancePolicy",
  "displayName": "macOS - Passcode Compliance",
  "passwordRequired": true,
  "passwordBlockSimple": true,
  "passwordMinimumLength": 8,
  "passwordRequiredType": "alphanumeric"
}

Every password* key here is enforced, not audited. The moment this policy reaches the Mac, OD applies the rules to all managed accounts.

Because the cause lives in Apple’s Open Directory rather than in Intune, this is not strictly an Intune problem. The same symptom has been reported on other MDM platforms too (see the references at the end), which is exactly what you would expect from an Apple-side cause. Switching management platforms does not move the wall.

The catch even Microsoft flags

You might assume that turning Change at next authentication off makes you safe. It is the right thing to do, but Microsoft documents a known issue where it was not enough:

“There is a known issue that affects devices running macOS versions earlier than macOS 26.4. When a macOS device enrolls via ADE with a configured local admin account and a targeted passcode profile, it prompts for an admin password reset, even if Change at next auth is not enabled or if a value is set for Max Age (days). This does not affect the standard account.”

Microsoft Learn - Configure macOS ADE local account configuration with LAPS

Microsoft’s documented workaround and fix are these:

“As a workaround, manually rotate the admin password after the reset on the device to keep the Intune and device password state in sync. Upgrade your device to macOS 26.4 to resolve this issue.”

Microsoft Learn - Configure macOS ADE local account configuration with LAPS

None of this makes compliance password settings wrong to use, the trade-off is just worth being honest about. Rotating the password by hand when you take over a device is a perfectly fine approach, and if it suits your workflow there is nothing wrong with it. Just know who ends up doing it: if your Intune RBAC roles do not let the helpdesk rotate the macOS LAPS password, every reset escalates to whoever holds that permission, which is often you.

Is the admin account even there?

Before you blame the bug, rule out a simpler explanation: maybe the account was never created in the first place. ADE enrollment can hiccup - a network drop during Setup Assistant, a profile that lands late - and a half-finished enrollment can leave the device without a managed admin at all. From the prompt, that looks identical to a rejected password, so confirm the account actually exists before going further.

Run these on the Mac:

% id <admin-name>
uid=503(<admin-name>) gid=20(staff) groups=20(staff),80(admin)

% dseditgroup -o checkmember -m <admin-name> admin
yes <admin-name> is a member of admin

If id returns “no such user”, the account was never delivered, investigate the enrollment, not the password. If the account exists but is not in admin, the profile bound the record without the group membership. If both look healthy but dscl . -authonly still fails, you are looking at the enforcement bug.

On the tenant side, the Passwords and keys pane shows whether Intune is holding a password for this device and when it last rotated. If the pane is empty or the rotation date is old, Intune is not managing the credential the way you think it is, and that is a device or MDM-channel problem rather than the Open Directory bug.

Check Healthy result What it means if it fails
id <admin-name> shows a uid and the admin group “no such user” - the ADE profile never created the account
dseditgroup -o checkmember -m <admin-name> admin yes ... is a member of admin account exists but is not an admin - profile delivered the record without the group
dscl . -authonly exits 0 with no output a correct password is rejected with eDSAuthNewPasswordRequired - the enforcement bug
Passwords and keys pane (Intune) a stored password with a recent rotation date empty or stale - Intune is not rotating the credential, look at the device or MDM channel

The fix that works today

The fix is to stop letting the compliance policy carry the passcode rules and deliver them declaratively through DDM instead. Two steps:

  1. Remove the password settings from your macOS compliance policy. Take passwordRequired and its companions out so the policy stops implicitly enabling Change at next authentication.
  2. Recreate the requirement in a Settings Catalog passcode profile. The Settings Catalog is applied declaratively through DDM, not enforced the way a compliance policy is, so it sets your rules without flipping the forced-change flag against managed accounts. The one setting that clears the lockout is Change at next authentication, set explicitly off (shown here as the single setting fragment, not a complete policy you can import on its own):
{
  "settingDefinitionId": "passcode_changeatnextauth",
  "choiceSettingValue": { "value": "passcode_changeatnextauth_false" }
}

Moving to DDM costs you no enforcement. The same declarative profile still lets you require and shape the passcode: demand it exists, force alphanumeric complexity, set a minimum length, lock out after failed attempts, expire passwords on a schedule, and block reuse. Set the values to match your own baseline; the only one that matters for this bug is passcode_changeatnextauth, kept off. Here are a few examples:

Setting What it controls
passcode_requirepasscode Whether a passcode is required at all
passcode_requirealphanumericpasscode Require letters and numbers, not just digits
passcode_minimumlength Minimum passcode length
passcode_changeatnextauth Force a change at next sign-in - keep this off, the key fix from this post
passcode_maximumfailedattempts Failed attempts allowed before lockout
passcode_failedattemptsresetinminutes When the failed-attempt counter resets
passcode_maximumgraceperiodinminutes Grace period before a passcode is required again on wake
passcode_maximuminactivityinminutes Idle time before the screen locks
passcode_maximumpasscodeageindays Maximum passcode age before it expires
passcode_passcodereuselimit How many previous passcodes are blocked from reuse

With the requirement delivered this way, rotate the admin password once more from Intune and confirm it authenticates before you need it under pressure:

% dscl . -authonly <admin-name> '<password-from-intune>'
%

No output, exit 0. That is the only proof that matters. Make this check part of your routine after every rotation and on every new macOS release.

Conclusion

The lesson is smaller than the symptom suggests: a compliance policy is enforcement, not an audit. On the Mac that distinction is expensive, because Open Directory applies password rules to every managed account and the LAPS admin gets caught in it. This is not a reason to avoid compliance policies, it is a reason to be deliberate about where the password requirement lives. If rotating the admin password by hand when you take over a device fits your workflow, that is a valid choice, just be clear on who in your RBAC model actually holds that permission. My own preference is to push the requirement declaratively through DDM (the Settings Catalog), with Change at next authentication off, so the forced change never happens and there is nothing to rotate after the fact. Either way, verify with dscl . -authonly after each rotation.

This is a snapshot of macOS 26.5.x behavior. The ADE enrollment variant is resolved in macOS 26.4 (per Microsoft Learn), but the underlying enforcement still comes from Apple’s Open Directory, so re-test whenever you move to a new major release.

References

← back to all posts next: Intune Anomalies Report →
PS Select-String -Pattern
↑↓navigate ↵open escclose