Notes from the Ontinue fleet, 2025.

The thing everybody had learned to live with

Reboot a Mac. FileVault asks for your password. Expected; that is the disk unlocking.

Then the Entra ID login window comes up and asks you to sign in again.

Two unlocks, every reboot. Nobody filed a ticket about it, which is the part that stuck with me. It had been like that long enough that people decided this is how work laptops are. You only hear about the things that stop people working. Everything else becomes background noise, and background noise is where this kind of thing sits for years.

It should be one password. So I went looking for why it was not.

Why it happens

The FileVault pre-boot screen is Apple’s and it is not optional. The disk is encrypted, so something has to unlock it before macOS is meaningfully running, and no MDM skips that.

What normally happens next is that macOS takes the credential you just typed and passes it through to the login window, logging you straight in. One password, one login, even though two separate things authenticated you.

That passthrough is the whole trick, and it can be switched off:

Domain: com.apple.loginwindow
Key:    DisableFDEAutoLogin
Value:  true

That is what was set. It lives in com.apple.loginwindow as a custom settings payload, not in the Jamf Connect profile, which is part of why it is not the first place you look.

With it on, FileVault unlocks the disk and hands you to the login window with nothing carried over. Jamf Connect puts up its own window and makes you authenticate against Entra from scratch. That is prompt number two. Nothing was broken; it was doing exactly what it had been told to do.

The part I got wrong at first

My first read was that somebody had set this by accident and never revisited it.

Wrong. Jamf explicitly recommends setting DisableFDEAutoLogin to true. The reasoning is sound: FileVault passthrough bypasses Jamf Connect entirely, which means it skips your identity provider. With passthrough on, a user can boot and be sitting at the desktop without Entra ever being consulted. For a lot of shops that is unacceptable.

So this was the vendor-recommended configuration, and turning it off meant deliberately overriding it. That is a different conversation, and a more interesting one.

The tradeoff, stated honestly

Restoring passthrough is not a free win.

What you give up: Entra is no longer consulted on reboot. The login is trusted on the strength of the FileVault unlock. There is also a keychain and password-sync angle. The Jamf Connect login window is what reconciles the local account password and login keychain against the IdP, and skipping that window on reboot means the reconciliation does not happen there. Users still hit the Jamf Connect window on logout, so it is not gone, it is just not on every restart.

What you get: every person on the fleet stops typing their password twice a day.

I think that is the right call in this environment. The FileVault password is the account password. The disk was already encrypted. The device was already managed and enrolled. The login happens on hardware we control. The extra Entra check on reboot bought a thin slice of assurance and charged every user for it, daily.

It is environment-dependent, though. A shop with conditional access requirements that need the IdP evaluated on every login should keep the second prompt; that is exactly what Jamf’s recommendation protects. A shop with frequent IdP password changes might care more about the reconciliation happening on every restart.

The honest version: I overrode a vendor recommendation for user experience, and I can defend the specific reasons it was safe here.

The other double login

This trips people up constantly. There are two different “Jamf Connect makes me log in twice” problems.

  1. After a reboot: FileVault, then the login window. That is this post. DisableFDEAutoLogin and passthrough.
  2. During account creation: you authenticate to the IdP in a browser window, then it asks for your password again locally. Different problem. That one is OIDCUsePassthroughAuth in Jamf Connect Login (2.5+ for Google, 2.6+ for Azure), and it needs OIDCNewPassword set to false.

Passthrough Authentication does not fix the reboot one. I have watched people try it and get confused when the second prompt survives a restart. Similar symptom, different layer, different fix.

What I took from it

Nobody reports friction; they absorb it. No ticket, no complaint, a whole fleet typing their password twice a day. If I had not rebooted my own machine and got annoyed, it would still be that way. Some of the best endpoint wins are in what people stopped bothering to mention.

Find out whether a setting is deliberate before calling it a mistake. I walked in assuming sloppiness and found a documented vendor recommendation. That turned “fix a misconfiguration” into “make a posture decision and own it”, and those need different conversations with the security team.

“Why is it like this” beats “how do I turn this off”. I could have flipped the key, watched the prompt disappear, and moved on. Knowing that the FileVault screen is unskippable, that passthrough is what collapses two authentications into one password, and that switching it on costs an IdP check and a keychain reconciliation is the difference between having fixed something and being able to defend it when someone asks why the posture changed.