Reposting this from my personal website to gain some visibility. 

UPDATE 1: I'm being told now that this change IS RETROACTIVE. Meaning your dozens/hundreds/thousands of endpoints that have been configured with Prestage enrollment, and an admin account created in that process, will have that password randomized. Which will break Secure Token/Volume Ownership/etc. Maybe you're okay with this, but if you're not, you NEED to reach out to your Jamf Representative and tell them. 

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”).

And to start with, I applaud Jamf for working on a LAPS solution. All we've ever asked in this whole thing is: Make it optional (for those that already have a solution, or want to see this bake longer). If you know this is going to break your fleet, you need to reach out to your Jamf rep and let them know. 

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.