Upcoming deprecation of setting local admin account passwords via PreStage Enrollment

[csmith122]

I have to ask why are we removing this ability, Im the IT guy who wears multiple hats at work, the support person, the server guy and the network guy. Removing the ability for IT admins to set a Prestage Admin account and password is just going to create headaches for the EDU IT admin. I dont think it should be forced on every one and would work better if it was a toggle switch that you can enable or opt into. 

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—
In an upcoming release, the ability to specify or modify a local administrator account password in a PreStage enrollment for computers will be removed from Jamf Pro (estimated removal date: March 2024).

[sdagley]

@csmith122 Take a look at the new LAPS functionality in Jamf Pro: https://learn.jamf.com/bundle/technical-paper-laps-current/page/Local_Administrator_Password_Solutio... It's replacing what you used to do with a Prestage created admin account.

[Tribruin]

@sdagley , the problem with LAPS is that it is not fully implemented. At minimum, Jamf needs to add a way to retrieve the LAPS password from the Jamf Pro GUI. For organizations that don't have robust solutions for API calls (like educational institutions), it is impossible to retrieve the password. 

But the bigger issue with this change is that Jamf is not listening to its customers and instead pushing a potentially breaking change on its customers. Some organizations need a standard admin account setup to assist with deployment. Again, educational customers may need to pre configured hundreds of computers for students. Asking the tech to look up a new password for every new build? That is going to be a killer. Not every organization can easily support full zero touch deployment using ADE. 

Jamf has already made turning on LAPS for the MDM account option by requiring making a change via the API. I am not sure what Jamf is gaining by forcing this change. Let an organization make the decision. 

I am hoping that Jamf, at the minimum, makes a few concessions. One suggestion is to continue to allow a defined password and set the rotation to not happen for X hrs or days. This would give techs enough time to configure and then make the account LAPS enabled. 

[csmith122]

I did not even know that we cant see the password in the JAMF UI, while we have some minor API calls that we do on the JSS we dont have anything like this implemented. Worse case scenario I was worried that I would have to have a laptop next to me to use the jamf pro UI to look up the password. Now it seems like you cant even do this. This needs a better solution JAMF, as a customer of your product for 10+ years I did not expect you to limit us like this. 

Talking it over with a friend it will just require me to create a policy that creates a local admin account after the machine has gone though the prestage enrollment, set this to run on the enrollment complete trigger and it will do the same thing. Not the end of the world just needless extra work just to get a basic admin account on the end users device. 

[mm2270]

This doesn't address the main issue, which is, why should the new LAPS functionality be forced on customers? I'm not saying LAPS generally speaking is a bad thing or something we shouldn't all be looking at, but how is it any of Jamf's business whether we use LAPS or not in our environments?

I agree that this change should be optional. If not permanently, then at least at first for a while, to give everyone a chance to really test it out and make any necessary changes to their device enrollment workflows. The new LAPS feature is not fully baked right now IMO, and yet Jamf is saying they will force it on anyone that wants to have a local admin account created as part of Prestage enrollment in just a couple of months?

[csmith122]

I have looked at this and its not a solution when i have to pre configure 1800 devices every summer. I agree with mm2270
This doesn't address the main issue, which is, why should the new LAPS functionality be forced on customers? I'm not saying LAPS generally speaking is a bad thing or something we shouldn't all be looking at, but how is it any of Jamf's business whether we use LAPS or not in our environments?

[Wgphoto]

I'm glad I just stumbled across this post. This is pretty crazy that this is being forced on customers. Why do they keep taking away functionality that helps the solo guys like myself and others? Jamf Remote was useful for more than actual remote sessions. In fact, I never used that part of it. Now that tool is gone. What do we get to replace it? A pure remote session functionality. Don't need it. Now they want to take away local admin creation at prestige, to replace with much more complicated LAPS situation. Don't need it, don't want it. This should absolutely be a choice based on customer needs.

[Wgphoto]

Must have missed this on the first go round, but the fact that we can't easily get the LAPS password in the standard Jamf Pro GUI is a dealbreaker. I wouldn't even know where to start with API stuff. again, this should be based on customer need, not forced down our throats. JAMF, listen to your customers. At the very least, wait until this can all be done within Jamf Pro.

[JoshRouthier]

This is definitely a dealbreaker for us. The crux of the problem for our organization is the fact that LAPS does not have a GUI interface yet (which we've been eagerly waiting for). I can understand Jamf notifying users of the upcoming change, but to not offer any "we're working on some alternative solutions", and just "this will be deprecated on such an such a date" is not helpful to us at all. I'll be reaching out to our account manager regarding this change.

[Wgphoto]

I've done the same, as well about removal of Jamf Admin app. We use this and they don't have alternative solution.

[atomczynski]

I've been in discussion with Jamf and heard back from them.

We should be seeing more details soon about Jamf LAPS from the Team at Jamf working on this solution in the form of a post in Jamf Nation.
In the meantime check out this Feature Request: https://ideas.jamf.com/ideas/JN-I-27528

[phunkywan]

I came across this little diddy to help retrieve the LAPS without the API. Shoutout to Pro4tlzz. You basically add it to your browser bookmark bar, and use it to retrieve any local passwords.

https://github.com/pro4tlzz/pro4tlzz.github.io/blob/main/jamf/JamfGetLapsPassword.html

[Deanna]

Hi @csmith122 Thanks for the feedback.  I want to share an update below.

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.  

[Tribruin]

@Deanna  Thank you for the update.

And thanks to Jamf for listening to our concerns. 

[csmith122]

This is great to hear, thanks for the update ! 

[mm2270]

Thanks for the update on this @Deanna This is great to hear! Thanks for listening to customer concerns around this.

I do have one question about it. You mentioned in your other separate post that 'this deprecation is on hold'. Does this mean the ability to specify local admin account creation during Prestage will eventually be deprecated, or that it's being put on hold while Jamf researches how to implement this as an optional change?

I'm hoping it's the latter, but either way, I'm glad we won't be forced into this change in the next couple of months.

[Deanna]

Hi @mm2270 the work is on hold as we determine the right path forward.  There are no plans to remove the ability to set a static password on the 2024 roadmap.  The deprecation notice will stay posted for visibility, but the timeline will be removed.  

[mm2270]

Ok, thanks for the clarification. Sounds good!