Jamf Pro 10.49 Now Available

[PCalomeni]

Today we are releasing Jamf Pro 10.49. Highlights of this release include:

New API Roles and Clients Settings
The new API roles and clients functionality in Jamf Pro provides a dedicated interface for controlling access to the Jamf Pro API and the Classic API.

Local Administrator Password Solution Enhancements
You can now use the local administrator password solution (LAPS) feature in the Jamf Pro API to manage local administrator account passwords on computers via the Jamf management framework. This method for implementing LAPS supplements the existing method for managing the local administrator account passwords via an MDM command.

For additional information on what's included in this release, review the release notes via the Jamf Learning Hub.

To access new versions of Jamf Pro, log into Jamf Account with your Jamf ID. The latest version is located in the Products section under Jamf Pro.

Cloud Upgrade Schedule

Your Jamf Pro server, including any free sandbox environments, will be updated based on your hosted data region below. Review this guide if you need assistance identifying the Hosted Data Region of your Jamf Cloud instance.

Hosted Region	Begins	Ends
ap-southeast-2	18 August at 1400 UTC	18 August at 2300 UTC
ap-northeast-1	18 August at 1500 UTC	19 August at 0100 UTC
eu-central-1	18 August at 2200 UTC	19 August at 0800 UTC
eu-west-2	18 August at 2300 UTC	19 August at 0600 UTC
us-east-1-sandbox/us-west-2-sandbox	19 August at 0000 UTC	19 August at 1000 UTC
us-east-1	19 August at 0400 UTC	19 August at 1700 UTC
us-west-2	19 August at 0700 UTC	19 August at 2000 UTC

[McAwesome]

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.

[MattAebly]

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

[McAwesome]

@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.

[MattAebly]

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.

[McAwesome]

@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?

[Tribruin]

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. 

[bwoods]

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?

{
    "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
    "Identifier": "com.jamf.config.swu",
    "Payload": {
        "TargetOSVersion": "14.0",
        "TargetBuildVersion": "23A5286g",
        "TargetLocalDateTime": "2023-07-06T13:50:00",
        "DetailsURL": "https://www.apple.com"
    }
}

[McAwesome]

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?

[MattAebly]

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

[Sweenster]

@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

[Tribruin]

@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. 

[DBrowning]

@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.

[Tribruin]

@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. 

[MattAebly]

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

[Tribruin]

@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. 

[whiteb]

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.

[MattAebly]

@whiteb 

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

[lordplaza]

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

[rstasel]

@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. 

[MattAebly]

@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_Solutio...

[rstasel]

@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. 

[PE2000]

"autoDeployEnabled": false,

is it set to false by default?

[MattAebly]

@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.

[rstasel]

@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! 

[redsee83]

@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?

[MattAebly]

@redsee83 

For those that want to use the PreStage admin account for a managed admin account, you can choose to skip the management account creation in the User Initiated Enrollment settings and only have that PreStage admin account created. For those not enrolling via a PreStage, the management account can be created as the managed account in the UIE settings.

[mpermann]

@MattAebly can you detail what items specifically Jamf Pro is using the management account for that is created in the User-initiated enrollment setting? My understanding is the account was used to allow Jamf Remote to work and a few other legacy things which are no longer relevant. So I'm wondering whether this account really is required at all anymore for proper functioning of the Jamf binary or the MDM management channel.

[MattAebly]

@mpermann You are correct. The biggest point of the management account was to tag a computer as "managed," although you could not create the management account and just make sure the computer record thought it had a management account for a computer to be managed. That's why we removed the stipulation of needing a management account to be considered managed. Now it's just the checkbox in the computer inventory record to "Allow Jamf Pro to perform management tasks" that considers a computer managed.

[mpermann]

@MattAebly there is a lot of confusion over the need for this account anymore. I see discussion daily on various channels of the MacAdmins Slack around this topic. I'd love to see Jamf publicly state this account isn't needed anymore by any of the Jamf components to properly manage a device. JNUC 2023 is coming up soon, and that would be a really good place to make a point of telling folks this. 😉 Thanks for your clarifications, now I can start pointing people to this thread on Jamf Nation. Have a great day!

[rstasel]

@mpermann I think it's going to be used by the new Jamf Remote Access functionality... my bigger concern is the changes to the default admin account for Prestage enrollments, that seems like it'll be next to useless when/if they force MDM LAPS on it. =/ 

But yes, some guidance on the difference, etc would be good. 

If you missed it, there's much better documentation on LAPS now here: https://learn.jamf.com/bundle/technical-paper-laps-current/page/Local_Administrator_Password_Solutio...

[MattAebly]

@mpermann, yeah that nugget about the management account is kind of buried in the Deprecations and Removals area of our 10.49 release notes. The top item in the Removals table explains that change as well:

This change simplifies the way computers are considered managed by Jamf Pro. Previously, Jamf Pro reported a computer as managed only when Allow Jamf Pro to perform management tasks was selected in its inventory record and management account credentials were provided. Starting with Jamf Pro 10.49.0, only the Allow Jamf Pro to perform management tasks must be selected for Jamf Pro to consider a computer managed.

---

https://learn.jamf.com/bundle/jamf-pro-release-notes-10.49.0/page/Deprecations_and_Removals.html

Might give you something a little more formal that explains not needing the management account.

[mpermann]

@rstasel if it is the case that the upcoming remote access product is going to require the Jamf management account as created in User-initiated Enrollment section, I'd really love to get @MattAebly to confirm that. 

@MattAebly I would contend that the way it was written in the release notes in 10.46.0 and 10.49.0 doesn't explicitly state you no longer need the account for managing a device. It just says you can't specify or modify the credentials on that account. I make the friendly suggestion that Jamf be more clear in documentation that the Jamf management account as created in User-initiated Enrollment section is no longer needed. I think it could go a long way to help clear up the confusion on whether the Jamf management account as created in User-initiated Enrollment section is needed or not. Thanks for taking the time to respond to my messages. It's appreciated!

[MattAebly]

@rstasel @mpermann The management account would not be required to use Jamf Remote Assist.

@mpermann Definitely understand where you're coming from. I'll check with Tech Comm and see if we can get that better communicated.

[rstasel]

@MattAebly oh, well, then I'm in the same boat as "what is this account for then?"

But given the LAPS documentation, kinda wonder the two accounts should just get collapsed into a single account. 

[mpermann]

@rstasel the thing is you don't need either account to manage a computer. You may only need a local admin account if you're making your end users standard users. If your end users are admins like mine, I don't need any account other than the end user's admin account on the computer. If a user forgets their password, I use the escrowed FileVault PRK key to unlock and reset the password. Hence, why I say there is a lot of confusion around what is required to manage a computer with Jamf Pro. 

[rstasel]

@mpermann yes, that's one argument. We have a global "admin" account that we used EasyLAPS for rotating the password. That's what our techs use to access the machine. it has cryto user and volume ownership. The account gets created during setup, tech does setup, makes the user's account (sometimes migrates their data) and hands it off. Yes, we could just rely on PRK, but then a tech either needs user's password (bad) or they're resetting user's password (almost as bad) if they need to work on machine. 

We would rather just continue to use the admin account created during prestage, or manually during UIE (easylaps can also create it) for techs, and never interact with the user's account if possible. 

[mpermann]

@rstasel I understand why you have a global admin account to manage computers in your environment. But my point is more that Jamf doesn't need that account to manage the computer. Organization IT departments my need an account to manage computers from, but it doesn't have to be that account. There are many different ways to get a global local admin account onto a computer. In my opinion, the "Create management account" under the User-initiated enrollment is not a good method and I can point to lots of folks on the Mac Admins Slack channels that have ran into weird issues when having that option enabled.

My goal of posting was to merely point out to the Jamf folks that there is no explicit documentation that states what that account is used for and that it really isn't needed any longer for Jamf to function properly and manage the device,

Not having a global local admin account is certainly not an ideal situation for all organizations. In my organization any troubleshooting that needed to be done on the computer was generally done in person or remotely in the end users account with the end user's knowledge and assistance. I realize that methodology doesn't work in all organizations. But it's pretty challenging to troubleshoot an issue that only exists in the end user's local profile from another account. 😉 Hence why we did the troubleshooting and support from the account where the problem was happening.

Anyway, I'm straying from my original goal of finding out what the Jamf admin account is being used for and whether or not it is needed anymore. But I appreciate your discussion @rstasel and @MattAebly's answers to my questions. Have a great day folks!

[rstasel]

Agreed. And I've given feedback to our "buddy" (Customer Success). Would suggest doing the same. 

[dstranathan]

Playing catch-up here on the topic of PreStage admin account and LAPS.  Im totally confused here. Can you assist, please?

I have been reading about LAPS on Slack, JamfNation, Jamf admin docs and Reddit; this topic is confusing and lots of people are sharing contradictory information.

Questions:

Can anyone confirm if Jamf Pro 10.50 REQUIRES the PreStage admin account to use LAPS?

Can I enable/disable PreStage LAPS in Jamf until I'm ready to leverage it?

Can I set a temp initial password and have it rotate at a later date (for example: 14 days after deployment)?

[MattAebly]

@dstranathan Thanks for your questions. Happy to help clarify.

We do not yet require the PreStage admin account to use LAPS. This is something we are looking at in the future and will give you all a good amount of time notice for the change. This will secure up the other area where Jamf Pro could be issuing a known password to your fleet of Macs (other area being the management account with a known password). We understand that this is also a big change, so any feedback regarding it we are definitely open to.

LAPS comes disabled already in all 10.48+ servers. You can utilize the LAPS setting API endpoint to turn on/off the feature.

Speaking of feedback for ideas, that idea of having the password rotate at a later time is something that we've heard from a few admins. It's certainly something we can look into adding as a feature in the future.

[dstranathan]

@Mat Thanks for responding sir. More questions...

From 2015 until April I had a single UIE Jamf Management admin account. I have hundreds of Macs with this account.

But starting in May I was advised by Jamf (in a FV2 pre-planning meeting) to replace the UIE Jamf Management admin account in favor of a PreStage admin account for various reasons, including the fact that the PreStage account gets a Secure Token instantly and can be used for  FV2, the sysadminctl command, Software Update, etc, and Jamf thought it would be perfect for me as an admin and my techs (and it could be used for ARD, SSH etc as needed for support). At this stage, I have hundreds of Macs with only the PreStage account.

So as of September 2023 have a mix of Macs with the UIE Jamf Management admin account and Macs with the PreStage account (different names & different passwords). Its geting confusing for my support staff. But now I might have to pull a 180 (again) and start deploying only a UIE Jamf Management admin account to ensure we have an account that can leverage FV2 if needed (and have a Secure Token that wont break after LAPS rotation)

Im still on-prem running Jamf Pro 10.46.1 JSS but have purchased Jamf Cloud and am ready to migrate this fall. Since I paid for Jamf Cloud, Jamf requires me to upgrade my JSS servers to be in step with the Cloud version before I migrate my database. I have no choice.

I was planning on updating my JSS servers to 10.50 this weekend but I put the breaks on this until I have more info.

I'm getting ready to deploy FV2 for the first time to hundreds of Macs. But at this point I have to halt this project too.

If I upgrade to Jamf Pro 10.49+ my older Mcs with the (UIE Jamf Management admin account) then my techs cant support FV2 workflows on hundreds of my older Macs because they dont have a clue how to use the Jamf API. This will be a nightmare for them.

I cant move forward on Jamf Pro 10.50+ without more info regarding the PreStage either account because that account will (soon) be worthless when it comes to FV2, Software Updates and anything that uses a Secure Token or the sysadminctl command. I was SHOCKED to find out that the PreStage account can't use LAPS because it will break the crypto key of the account. This was NEVER told to my by Jamf in any of our FV2 planning meetings. In fact, I can find multiple articles about Secure Tokens, PreStage accounts and FV2 that never mention this (major) caveat - many of the docs are from Jamf or are posted in JamfNation and Slack. 

Having no UI for my techs to use when it comes to LAPS is a huge mistake on Jamf's part. You should have deployed LAPS when it was feature-complete and had a management UI. Im fine running the API personally but the rest of my staff are dead in the water. These kinds of knee-jerk changes are making my org reconsider buying and managing Macs. The overhead is becoming too much for my team.

I thought there were a couple of community tools for LAPS but 1 is totally gone now (404 error):

https://github.com/red5coder/Jamf-LAPS/

And the other appears to have no traction, no tech docs and not much info:

https://github.com/PezzaD84/JAMF-LAPS-UI



Once the PreStage admin account requires LAPS my entire ABM/DEP deployment/enrollment workflows will be broken: My techs need to log into a freshly enrolled Mac at least 1 time (with the PreStage account creds) in order to make a couple of mandatory tweaks (not my call on this workflow so I can't change it). 


Leveraging LAPS for the PreStage account makes total sense for security at some point (7-14 day grace period after a Mac is assigned to production etc), but if the password changes as soon as enrollment is complete then it will totally break my deployments. Im all for leveraging LAPS in some capacity, but to have it dumped on customers with little or no control is unacceptable.

We don't use 'zero-touch' deployments we are 'light touch'. We don't allow users to create an account at the Apple Assistant - we MUST use the PreStage account at enrollment deployment time before anyone else logs in. I hope I have enough time to retool my workflows and get a plan ready for this. I really hope Jamf will allow the PreSage admin account to have a temp static password that will work for x amount of days.

This doc from WIllaim got my LAPS juices flowing back in April and was the genesis of why I decided to move from a UIE Jamf Management admin account to a PreStage admin account in the first place. In fact I called a meeting with Jamf to start planning my FV2 project based on ideas I got from this article. But the Jamf doc fails to mention 2 critical facts:

-The PreStage admin account can't be used for FV2 etc because the Secure Token will be killed after LAPS.
-UIE Jamf Management admin account can also be used with LAPS

See https://community.jamf.com/t5/tech-thoughts/how-to-securely-manage-local-admin-passwords-with-jamf-p...

Please advise and thanks again Matt

[mpermann]

@dstranathan have a look at this little “bookmarklet” your techs can add to their computer so they can easily access the LAPS password. I use it and it works great. You just go to the computer record you want to pull the LAPS password off and then open the bookmark and it pops up a little UI to enter the admin name and it returns the password. I haven’t done any extensive personal testing with the LAPS so I’m going to leave most of your questions to the Jamf person to try and answer. 

[dstranathan]

Thanks @mpermann I will check it out. It is just HTML. How do I use this? Do I plug in my JSS URL into 'window.location.href'? Sorry if this is a dumb question. Wasn't what I expected. 

<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<!-- <meta http-equiv="refresh" content="0; URL='https://pro4tlzz.github.io'" /> -->
<script type="text/javascript">
window.location.href = "https://pro4tlzz.github.io/jamf/JamfGetLapsPassword.html"
</script>
<title>404 - 301 redirect</title>
</head>

<body></body>

</html>

[mpermann]

@dstranathan here is information on how to use it. You don't have to make any changes to the bookmark. Just open it when your on the computer record you desire the LAPS password of. 

[dstranathan]

@mpermann Thank you, sir. Got it now. That's pretty cool. Much appreciated.

[dstranathan]

@MattAebly When I try and verify the status of my LAPS accounts using your info above (or this link) 

The /api/v2/local-admin-password/settings endpoint is shown as "Deprecated" and greyed out..?

[MattAebly]

Hey @dstranathan,

I'm seeing the v1 endpoint as deprecated.

[dstranathan]

Hi @MattAebly I just saw the Deprecations doc for Jamf Pro 11 (see link below). It mentioned PreStages admin accounts are going to be forced to use LAPS, but still no date is given. Do you know when this will occur?  What cant Jamf just come out and give customers a date or even a ballpark window like "Q2" etc?

I wish there was a way to enable/require LAPS, and still allow customers to set an initial temp LAPS password for x days so my techs can still log into new Macs during deployment/enrollment. Once PreStage accounts use LAPS my techs will basically be locked-out of our own Macs. How do I submit this request and get Jamf to listen to my ideas for consideration?

My workflow is not zero-touch. We are 'light-touch' with a focus on customer service. My techs log into a newly-enrolled Mac with our PreStage admin account and kick-off deployment DEPNotify style workflow policies from Self Service (or at 'enrollmentCompete' trigger). When LAPS becomes required for the PreStage admin,  they would have no way to log in. Sure, the techs could check the new computer record in the JSS and then get the PreStage admin's LAP password, but...

1 This is an extra manual step for the techs.
2 Currently Jamf doesn't even provide a native UI for seeing LAPS passwords (Jam'f cart is ahead of the horse here)
3 I cant risk having the LAPS password rotate on my techs while they are actively running deployment policies and preparing our new Macs for production.

Thoughts?

See  https://learn.jamf.com/bundle/jamf-pro-release-notes-current/page/Deprecations_and_Removals.html

[MattAebly]

@dstranathan thanks for the reach out.

There still is not a particular targeted version for the password setting in a PreStage to be removed. We want to make sure to give you all at least a 6 month notice for that change since it is so heavily-impacting to existing workflows. We're also looking into ways we can enhance the LAPS workflow to make removing the password setting less impactful. Your idea about having an initial set password for that account and then rotating after a set amount of time is also a request that has been brought up multiple times that we'd like to look into.

For any of your ideas with LAPS feature requests, I'd recommend using our ideas portal: ideas.jamf.com. We monitor the requests that come in, and it does help build out our initiatives and feature improvements to our products. 

We do want to make sure that good alternatives are in place for this PreStage account before we make any big changes to it. And you all will be notified when we're hoping for the changes to take effect. We're just not at that point yet.

[rstasel]

@MattAebly would be great if we could just, not force it. some of us have existing LAPS products/workflows and I'm not sure you guys are going to be able to match that functionality. Unless this is something you all are being forced to do from Apple, please just leave it optional so those with existing LAPS can leave as is, and those with existing LAPS can continue to use that. That also gives you all time to tweak on your LAPS implementation and when it meets a customers need, then they can migrate over. 

Just a thought... and not trying to diminish the work you all have put into this, but it seems like something that should continue to be optional rather than forcing it at some future (unknown) date (which, you admitted giving a heads up for, which is great...) 

As it stands now, we would likely end up setting up ANOTHER account that used our existing LAPS process, and ignore the prestage admin account. =/