@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.
@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.
@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.
@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!
@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_Solution.html
@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.
@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!
@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.
@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.
@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.
@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.
@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!
Agreed. And I've given feedback to our "buddy" (Customer Success). Would suggest doing the same.
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)?
@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.
@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-pro-and/ba-p/289969
Please advise and thanks again Matt
@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.
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>
@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.
@mpermann Thank you, sir. Got it now. That's pretty cool. Much appreciated.
@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..?
Hey @dstranathan,
I'm seeing the v1 endpoint as deprecated.
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
@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.
@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. =/
