If I'm reading the white paper and important notices correctly, this upgrade will break existing LAPS solutions places have set up.  The LAPS password won't be visible through Jamf directly, but will require an in-house application using the API, which many places won't have built already.  The use of the SetAutoAdminPassword command means that the existing accounts will no longer be reliable for use by IT when someone brings in a machine for updates.  There is no opt-out or way to delay the change for a smoother transition.  And it's all being done right when schools are getting back in session for the Fall semester.

Do I have that right?  This seems like a terrible way to introduce this good feature.

(Edit) Oh yeah and how the API is accessed is changing in this same update, which will slow down testing of those in-house tools now needed to view the LAPS passwords.

Hello, @McAwesome,

Thank you for your feedback and questions. The first iteration of LAPS that we provided solely dealt with the additional admin account being created in a PreStage enrollment. With feedback from that, we wanted a way for customers to also have a LAPS solution on devices that weren't enrolled via Automated Device Enrollment or did not create that additional admin account. Since the Jamf Pro management account has not been used for anything inside of Jamf since the removal of Jamf Remote, the best option was to re-utilize that account for a LAPS account and utilize the Jamf Management Framework for password rotations. Because of the changes needed on the backend during a server upgrade for a migration step, LAPS will need to be enabled with the upgrade to 10.49. We do understand the changes to some existing workflows that will need to be updated with this change. We have recommended not having a known password for the management account for a long time due to the security implications of having a known password on your entire fleet of Macs. This LAPS feature addresses that security concern by having a random password that can only be viewed by Jamf Pro admins with the correct auditing privileges. We have also not prevented having a way to get a known password on an admin account for your computers. This would now need to be accomplished utilizing a policy to create that account with a known password if that's the option you would like to take.

We understand the need for a GUI with the LAPS feature is highly requested from our Jamf Pro community and we are looking into ways to make this a great experience for our users. With the API being the first step of this solution, we're also investigating ways of making the API access easier for admins while we look to implement into the UI.

Thank you for your feedback and we look forward to hearing how we can better our LAPS feature to be accessible for everyone.

Matt

@MattAebly If it was just the Management Account, that would be one thing.  The documentation (and Jamf chat) say it is both that Management Account and the additional Local Admin Account that can be created during a prestage.  Forcing a new LAPS solution onto the latter before a UI is even ready is going to be catastrophic for many institutions, especially right when the academic year is starting.

Thanks, @McAwesome.

The work that we're performing here for both the PreStage LAPS and the Management Account LAPS also helps pave the way of separating user-initiated enrollment settings from PreStage settings. We have changed now what it means for a computer to be considered "managed" and no longer needs a management account present. Our PreStage enrollment users can now have a LAPS account created with the additional admin account and skip creating the management account to have this process work solely with MDM. This also eliminates the need for 2 LAPS accounts being present for these situations if the admin desires.

@MattAebly 

My complaint isn't with the product it's with your rollout.  It's the busiest time of year for Education.  Not every institution has people who can code an in-house app to use the API to access these passwords.  This rollout is forcing them to do that faster than would normally be needed, and you're also changing how the API access is granted in the same update. 

If you had some way to access the LAPS passwords through the UI that would be one thing.  If it only affected the Management Account, it'd be a non-issue.  But since this is a forced on (per Jamf Chat) and it takes over the Local Admin Account created during prestages, it's an extremely serious issue for your customers.

Effectively, your breaking deployments and mass revoking admin from the institution's IT support with less than 2 weeks of notice right before thousands of students, teachers, and staff start the Fall semester all across the country.  I hope you can understand why that is an extremely bad thing to do.

Do you at least have a generic tool you can offer to let institutions that don't have dedicated programmers access the LAPS passwords on machines?

I am going to add my disappointment that Jamf moved forward with implement using the management account as a LAPS account without the ability to disable the migration. Unfortunately I have a small percentage of computer that were setup with the management account to be used as a "support admin" account. Understanding that was a terrible practice, this was changed a couple of years ago, but we still have some computers that were enrolled prior to the change. 

I brought this up during the beta cycle and requested that Jamf offer an option to not immediately migrate the management accounts to LAPS. This is going to very disruptive to my organization. 

Currently beta testing macOS Sonoma and would like to test the new MDM command that functions similar to Nudge and S.U.P.E.R. Unfortunately, this feature doesn't seem to be available in the Jamf Pro API. When can we expect to have the ability to deploy the command below?

To clarify, I have no issues with the Jamf Management Framework method.  My issue is with the MDM Command Method that takes over the Local Admin Account created via the prestage.  I was informed by Jamf Support chat that both methods will be auto-enabled as part of the 10.49 upgrade.

So to confirm: Will both methods be auto-enabled like Jamf Support says or will just the Jamf Management Framework method be enabled like the white paper says?  When @MattAebly says above that it will be enabled due to a migration step required on the back end, is he referring to both methods or just the Jamf Management Framework one?

@McAwesome, that is correct. Due to the changes needed with the migration step for the Management Account, LAPS is enabled by default for the Management Account.
(Edited for clarity.)

@MattAebly Is this for the Management Account only and for the Local Administrator created during prestage? Or only the Management Account?

I think that is where the confusion is at. Thanks

@MattAebly 

This is a huge change, enabling LAPS for the Presage management account is going to 100% break my ADE workflow. 

This is not a change that should be forced upon us. It should be an optional feature that we can adopt when our organization is ready. 

@Tribruin @Sweenster @McAwesome I just ran a wipe and resetup on a device in my dev instance (running 10.49) and the additional account created in the Pre-stage, the password is not cycled via the LAPS changes.

@DBrowning That aligns with what I saw on my first test in my dev. I also looked at the APIs and, from what I saw, the MDM created account was NOT LAPS enabled. But, for some reason, I couldn't enter the password. Wiping and testing again. 

To clarify, with Jamf Pro 10.49.0, LAPS will be enabled by default for the Management Account since we needed a migration step to happen during the upgrade. If your LAPS settings in /v2/local-admin-password/settings is showing:

"autoDeployEnabled": false,

then LAPS is not enabled for the PreStage additional admin account. That will only be enabled if the autoDeployEnabled flag is set to "true."

https://learn.jamf.com/bundle/technical-paper-laps-current/page/Implementing_LAPS.html

@MattAebly So that contradicts what you said in your comment above, but does seem to match my initial testing and checking via the API. Thanks for the update. 

I second everything @McAwesome has said. I happened to have rolled out the third-party macOSLAPS on our pre-stage local admin account not too long ago and am very happy with it. I can understand wanting to set better baseline security practices for customers. But maybe make it opt-in, with a gradual rollout at first?

And I'm still sort of confused. When we get upgraded to 10.49, LAPS will be enabled by default on the management account, which I have set to not get created for awhile now, so that's fine.

Checking our current LAPS settings, (which is only currently available via API?) - I'm seeing 

autoDeployEnabled": false

So we shouldn't really be affected post-10.49 migration, and can continue using macOSLAPS as we have been?

There are probably a decent amount of Jamf Admins out there that have never even been in the API.

@whiteb 

That's correct. If your "autoDeployEnabled" is false, then your PreStage additional admin account will not have LAPS enabled.

@MattAeblyThanks for the clarification. I was in the crowd of panicked admins who haven't touched the API yet!

@MattAebly Totally get rolling this out for the management account. I'm sure a Jamf Pro audit of all customers would show a shocking number of static management account passwords set. We've been set to random for quite some time, so changing it to this is of no issue. Also meshes with rolling out the new Jamf Remote tool (yay!)

For the Prestage admin account though, that's where we're more worried. Will it apply to the Admin account created before setup? One, sounds like it's going to be forced, which creates some timing issues for updating documentation, educating techs, etc. Ideally there would be a way to opt-into this. 

Second, I would really really really like to see some more in-depth documentation on how LAPS is being handled. How do we migrate existing LAPS situations to this? How does it roll the password? How does it handle losing communication with the JPS during a rotation? Does it keep a log of previous passwords? Can we set the password length (unlike the recovery lock code, which is honestly obnoxiously long)? Can we set a delay where during initial setup, a static password gets set then isn't rotated for X minutes (we do this currently using our solution and it's 2 weeks, so techs can easily work on the machine before delivering to user)? 

LAPS is serious business for large fleets of computers in Education. We can't just get ahold of a machine some Faculty member has across the country/world... or that won't respond to technicians. So breaking stuff is bad. 

This really feels like there should be some focus grouping/research done with the install base before rolling this to something like the main admin account. 

@rstasel Thank you for the feedback.

When LAPS is enabled in the settings /v2/local-admin-password/settings by having:

"autoDeployEnabled": true,

 this will apply to the additional admin account created in a PreStage. The reason we are targeting this account is because of the MDM command used to rotate the password, SetAutoAdminPassword. This command can only be used on the MDM-created admin account, or the Additional Admin Account that you create in a PreStage enrollment.

For right now, the ability to specify an additional admin account password is allowed so long as your LAPS setting for autoDeployEnabled is set to false. When that is set to true, LAPS will then be enabled for that account and its password will be randomized based on our default settings.

Speaking of settings, additional settings and configurations are something that we would like to explore further. Providing this feedback via our Ideas space will help us shape what additional features to provide for LAPS. Having a GUI is one big item that is widely requested, but knowing about other customization settings wanted (password length, delays in rotations, etc.) would be helpful to know to build out the roadmap. This is just the first iteration of this feature.

We do have a document that goes over the LAPS feature in some detail. If there's further information you would like to see on that document, please let us know.

https://learn.jamf.com/bundle/technical-paper-laps-current/page/Local_Administrator_Password_Solution.html

@MattAebly Thanks for the reply! You keep saying "Additional admin account". What do you mean "Additional"? We're just creating the single admin account during prestage, and skipping the setup step making a normal account.

I'd be happy to supply via Ideas, but tbh, for years now it's felt like shouting into the void. Edit: here's that Idea: JN-I-27528

We're just worried that you all keep trucking ahead with this without pausing to get feedback. I'm totally cool with the current state of it. Using it for the management account makes 100% sense. 

You mention leaving it at false, and I get that... the issue is the release notes, deprecations (top item: https://learn.jamf.com/bundle/jamf-pro-release-notes-current/page/Deprecations_and_Removals.html) say we're going to lose the ability to set a password in prestage in the future. But no mention at all on how long that will be. If it's a year or so, great. But given how fast this existing LAPS functionality is rolling, and how long we've all been waiting for the config profile redesign... it could be anything from 10.50, to 10.70. 

I've looked at that document, and yeah, it still leaves MANY unanswered questions (which I posed above).

How does the password get escrowed, does JPS generate a password then push to client to rotate?
How does the JPS know when password was rotated?
How does a reversion happen (if one does) if there's a failure to agree on what the password is on the client? 
Are the previous passwords kept somewhere? 
What happens if the client loses connection to the JPS during rotation?
Does it correctly account for powernap and not try to rotate when the machine isn't really "awake"? 
How do you migrate to this from an existing LAPS setup?

Some of these are ideas, some of them are documentation to help us Jamf admins understand the risks, etc. 

"autoDeployEnabled": false,

is it set to false by default?

@PE2000 These are the default values:

{

"autoDeployEnabled": false,

"passwordRotationTime": 3600,

"autoRotateEnabled"; false,

"autoRotateExpirationTime" 7776000

}

@rstasel Thank you for creating that idea, it's much appreciated and I will tell you that we see all of them that come in. As for the implementation questions you've posted, I will recommend to reach out to your Customer Success Manager to further discuss. I'm not sure how much of the detailed information can be publicly shared, but if there is some that we can add to our documentation, I'm all for adding more detail to answer any lingering questions.

For anyone else reading through the thread, I just want to try and simplify the changes that we are doing with 10.49.0. For the PreStage admin account that's being created with a known password, none of that workflow is changing at this time unless LAPS is enabled in your settings by flipping the "autoDeployEnabled" flag to true. Setting that to true will enable LAPS for that PreStage admin account. For the management account in 10.49.0, that account will transition to a LAPS account automatically and the password for it will now be randomized and secured.

As for the timing of deprecating the known password in the PreStage admin account, that is something that is still a while away. I will say that we are looking at possibly deprecating it at least 6 months after a GUI is enabled for LAPS in Jamf Pro. After the GUI is GA'd, we'll give a better timeline as to when specifying the password will be removed, but there will be sufficient time to adjust workflows based on feedback from you all. This is not something we want to just forge ahead and disregard any current workflows, but at the same time we want to make sure that we are helping secure accounts in an easily usable manner.

@MattAebly Thanks. I've already reached out to customer success and am waiting to hear back. Basically identical feedback to what i posted in the idea. 

That's great info for when stuff is being deprecated, thank you for sharing that! Might we suggest adding that to the deprecation notes?

And yes, please, any info that can be shared in documentation would help put some of our fears at ease here. We just want to know you all are handling corner cases where the laps password could potentially get broken as breaking the admin password on tens/hundreds/thousands of computers is bad. =)

Thanks again! 

@MattAebly 

Since you say "We have changed now what it means for a computer to be considered "managed" and no longer needs a management account present." Once we enable laps for prestage, can this local acct be used to login to user initiated devices or will the mgmt acct have to be used?