Upcoming change will enforce LAPS on Prestage admin accounts (important!)

[rstasel]

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.

[Deanna · Accepted solution]

Thanks @rstasel 
Jamf is looking forward to bringing LAPS functionality to the GUI and in 11.3 you'll have the ability to view/rotate passwords from the Inventory page. The ability to configure settings via the GUI will be in a subsequent release.  There's been a lot of chatter about the PreStage account and I can share that:

• LAPS will not be on by default for the PreStage account
  
  • The ability to set a static password in the PreStage will remain. 
    • This means that there will be no change to your current static passwords.
• The ability to enable LAPS for the PreStage account will be available in the GUI in a future release.  Admins will have the ability to "opt-in" to automatic password rotation.

Current workflows that rely on a static password in the PreStage will remain unchanged.  More information to follow in an upcoming blog post.  

[Deanna]

The release notes will be updated and I will advise once complete.  Until then, to re-iterate, LAPS is optional and admins will continue to be able to set a static password.  This has not changed from prior conversations/posts.  

[Deanna · Accepted solution]

The deprecation notice will be removed in 11.4 RC

[A-bomb]

Thank you, @Deanna.

[rstasel]

Yes, thank you Deanna! 

[mark_lynch]

Much appreciated!

[atomczynski]

Thank you @Deanna for your help and the update.

[dstranathan]

To confirm, PreStage admin accounts will continue to be able to be set to a static password for the remainder of 2024?

[Deanna]

Yes, confirmed.  You can continue to use a static password.  We are not removing this ability at this time.  Workflows that require a static password in the PreStage will not be impacted.  

[dstranathan]

Thanks Deanna. Ugh, wait: This Jamf Pro 11.3 document (dated yesterday Feb 19 2024) states that LAPS will be REQUIRED for PreStage account. Comments?

[Deanna]

LAPS is not required.  It is optional.  You can continue to create a static password.  We will update the document.  Thank you for the feedback. 

[dstranathan]

Just a heads-up, @Deanna -  that Jamf document I linked to previously is still incorrect (after 7 days). 

"Functionality to specify the local administrator account for computers in a PreStage enrollment—

In a future release, the ability to specify or modify a local administrator account password in a PreStage enrollment for computers will be removed from Jamf Pro.

Once implemented, the local administrator password solution (LAPS) will provide equivalent functionality for securely viewing and modifying macOS account passwords on managed computers. For more information, see the Local Administrator Password Solution for Jamf Pro technical paper."

[rstasel]

Hey @dstranathan fwiw, they don't change existing release notes... she mentioned today that the 11.4 release notes will remove the deprecation notice. https://community.jamf.com/t5/jamf-pro/upcoming-change-will-enforce-laps-on-prestage-admin-accounts/...

[dstranathan]

Thank you for clarifying.

[atomczynski]

@rstasel, I appreciate the dedicated effort you've put into collaborating with Jamf on this project, as well as our productive exchange of direct messages and the exploration of ideas and solutions.

I'd like to take a moment to extend my gratitude publicly to @Deanna for our insightful meeting on this topic. Her excellent communication skills and genuine interest in understanding my concerns created a sense of true partnership.

A heartfelt thank you goes out to the entire Engineering Team for attentively listening to our input and recognizing the potential impacts on specific workflows.

[cwaldrip]

This is great to hear. We're searching for a good LAPS solution but would love to leverage our existing Jamf system, So far nothing else has met our requirements. 🤞🏻

[rstasel]

Check out EasyLAPS. Jamf’s LAPS solution is/wasn’t it if you plan to use the account…

[ericbenfer]

I am working with a Jamf environment that currently does not have any Jamf LAPS capable admin accounts.

They did not create a “Management Account” in User-initiated enrollment.

They did not create a “local administrator account” int PreStage Enrollment.

We have since specified a “Management Account” and a “local administrator account”. With two separate names.

They are using Apple Business Manager Automated Device Enrollment. There are some locations that do not have ABM, so they are using User-initiated enrollment. (That is begin resolved).

LAPS is working with newly enrolled Mac systems using either admin accounts. 

Is there away to retroactively add a User-initiated enrollment “Management Account”?

I’ve tried using “jamf policy -trigger enrollmentComplete”. This will successfully re-run the enrollment policies, but it does not create the “Management Account” from User-initiated enrollment.

“profiles -N” does work. But that requires user interaction.

Thoughts?

[ericbenfer]

https://community.jamf.com/t5/jamf-pro/retroactively-creating-jamf-laps-capable-admin-accounts/m-p/3...

[atomczynski]

@Deanna

It would greatly benefit us to have the internal teams gather and share an update. Currently, the information we receive doesn't completely match the release notes. As mentioned previously, clearer definitions are needed. While some progress has been achieved, it seems like we've taken steps backward in certain areas, nearly reverting to square one.

[Deanna]

Hi @atomczynski We will update the document for clarification.  Work is in progress and I will advise.  I appreciate the feedback.  Thank you for your patience.