Update 2024-01-26: Jamf has finally seen the concern and will no longer be forcing this change. See update on my Jamf Nation thread here: https://community.jamf.com/t5/jamf-pro/upcoming-change-will-enforce-laps-on-prestage-admin-accounts/m-p/308912/highlight/true#M269092

Happy new year, and sorry for being afk for so long.

Quick Definitions before diving into this.

LAPS: Local Admin Password Solution. Something initially created by Microsoft to solve the static local admin password problem (setting the same “sekritpassword1!” password on all your computers “administrator” accounts makes it super bad when that password gets compromised)
ADE/DEP: Automated Device Enrollment/Device Enrollment Program (former name is DEP). This is Apple’s system that allows registering a serial number on Apple’s systems so it automatically joins an MDM solution during Apple’s Setup Assistant.
MDM: Mobile Device Management. A somewhat antiquated term, but still used outside it’s initial intent. This is the management system used to manage/control both computers and mobile devices.
Jamf: Both a company (JAMF, NASDAQ), and a set of Products, in this case, shorthand for Jamf Pro.
Prestage Enrollment: Jamf’s configuration that leverages ADE/DEP assigned machines. Basically “What should I do with this computer that’s been assigned via ADE?”
Secure Token: The “permission” required to unlock FileVault on a FileVault protected computer.
Volume Ownership: An additional “permission” required to apply OS updates and upgrades on Apple Silicon computers
Bootstrap Token: A token escrowed with the MDM solution that can be used to grant a given user account Secure Token/Volume Ownership during OS login.
FileVault: Apple’s full disk encryption technology. Of note, FileVault prevents full OS boot, so the login window seen on a FileVaulted computer is PRE-OS boot. This means anything that requires network access cannot happen at the FileVault login. After FileVault login, that login information is usually passed to the OS so there isn’t a second login prompt.

With that out of the way…

I wanted to bring up that a big change is coming to Jamf soon and they (Jamf) seem to think it’ll be well received all around: forced LAPS for Prestage (ADE/DEP) admin accounts (See bullet 2 here, https://learn.jamf.com/bundle/jamf-pro-release-notes-current/page/Deprecations_and_Removals.html, “Functionality to specify the local administrator account for computers in a PreStage enrollment”).

On it’s face, this sounds great. Static passwords are bad. LAPS is good. Right? Right?!

So yes, Good LAPS is good. Bad LAPS is… bad. Very bad.

First, Jamf is using Apple’s inferior LAPS functionality via the MDM “SetAutoAdminPassword” (https://developer.apple.com/documentation/devicemanagement/set_the_local_administrator_password). This basically just pushes a new hashed password into the OS, which breaks Secure Token and Volume Ownership (due to Apple reality). So Prestage configured admin accounts will no longer have any Crypto permissions (no logging into a Filevaulted computer, Applying updates on Apple Silicon machines, etc.

Second, Jamf is also forcing their same 29 character passwords (like Recovery Lock). 

Jamf has said “you can use the management account!” but many of us with Jamf Pro infrastructures that span several years (with thousands of computers) have management accounts that were used for Jamf Remote, never actual login. Jamf remote is no more, and Jamf decided to repurpose this formerly invisible account to be some kind of “admin” account (I honestly don’t know who they’re talking to sometimes). Those accounts are named who knows what (because it wasn’t visible), have no secure token, and still would rely on Jamf’s immature LAPS.

So, you say, “Just ignore Prestage admin account!” Somewhat easier said than done. If you don’t have that account created via Prestage, you cannot skip account creation (which makes sense, why would you want a computer with no accounts). So, you make the Prestage admin account some throw away account name that you can delete, or use in an emergency with the FileVault recovery key. Then you have a policy create your _real_ admin account. Great (assuming enrollment policies actually run properly). You login, but now notice that that account doesn’t have secure token, and bootstrap hasn’t been escrowed (it’s unclear why this is happening, as the first user to login SHOULD get SecureToken, and bootstrap should escrow. However, having tested this several times on a current macOS 14.2.1 machine, I can confirm this is the behavior). So you have to do the whole “no accounts have secure token, so you can grant secure token to the account itself” (sysadminctl -secureTokenOn username -password “password” -adminUser “username” -adminPassword “password”), and then manually escrow bootstrap (profiles install -type bootstraptoken). All good, but more and more work to work around Jamf’s decisions. 

We’ve spent months trying to convince Jamf to make this change optional. As mentioned, we don’t disagree with LAPS, good LAPS is good. We use it across the fleet of several thousand machines (we used a product called EasyLAPS). We just think their (Jamf’s) implementation is sub-par (and certainly below the level of EasyLAPS, which we pay for because it’s a good product). 

I think Jamf has a blind spot on this, and they’re not properly alerting their users this change is coming, and coming SOON! (we’re being told it’s scheduled for 11.3, which is slated for February). And because they don’t hear anyone upset (other than us?), they think everyone is cool and happy with this change. But they’re also not about to alert everyone either (I’m sure many many Jamf admins don’t bother reading the Deprecations and Removals section of the release notes (note! you should read these! You should read ALL the release notes)). We’ve met more than once with the Project Manager that’s working on the LAPS rollout, and it goes no where (instead of listening to us, and our concerns, it turns into “how can we help you implement our LAPS solution?”). We’ve told Jamf this, but it’s honestly making us look at switching MDM vendors, which I’m sure you realize is a HUGE undertaking.