Can we silently re-enroll Macs?

[howie_isaacks]

We have discovered a large number of Macs in our fleet that appear to no longer have the Jamf agent installed on them. This may be because users used the "jamf removeFramework" command on them. I have been working on figuring out how we can get these systems re-enrolled. For years I have used the command "sudo profiles renew -type enrollment" command to re-enroll Macs that are in Apple Business Manager. Running this command requires me to interact with the Mac to complete the enrollment process. I tested this a few days ago on my test Mac to take note of everything that happens after the profiles command is ran. We would like to do this in the background silently. We have an agent called Aternity installed on all of these Macs. We know they're in use and active. They're just not connecting to Jamf Pro. Aternity can send scripts to the Mac, and my thought was that we could run the profiles renew command in a script pushed out to these Macs. Are there any options that can be used with this command to make it silent? I did look at the man page for profiles. I saw a lot of options that will probably be useful in the future but I saw nothing that would re-enroll a Mac silently. Are there any ways to do this without alerting the user? I would love some suggestions.

[sdagley]

@howie_isaacks I don't have a Mac I can test it on, but I believe installing the MDM profile would require user authorization since it's going to want to install a certificate in the System keychain which requires admin auth to do that as of macOS Big Sur

[howie_isaacks]

As I wrote this, I figured this would be the answer, but I had to ask. Below is a response that may lead to a decent solution.

[Hugonaut]

@howie_isaacksthat's a really tough position, might not be a way around user interaction, in the event another jamfer doesn't provide a more viable solution, shoot me a message on slack & I can assist in some troubleshooting. To give you an idea, What I've done to remediate this in the past is create a quickadd package for said server, extracted the jamf agent, created a custom package & deployed it to the machine via a 3rd part tool as you've stated, once on the device, it does a partial "enrollment" & we can use the jamf agent to do stuff, we can use various tools like this - https://github.com/Rocketman-Tech/Jamf-Self-Healing - to perform a "full enrollment", along side invitation ids & manipulating Jamfs MDM Profile ID, etc, but user interaction is pretty much required. A lot of this hinges on the devices being in ABM & Prestage. But yeah, user interaction 🤔

[howie_isaacks]

Thanks! I have a pretty full day today, but I will reach out on Slack. If we have to do this with user interaction, I can live with it. I still haven't solved the mystery of how these systems became unenrolled in the first place. If the users are admin users and they know the command they can run it.

[talkingmoose · Accepted solution]

If you enrolled the devices using Automated Device Enrollment and disabled Allow MDM Profile Removal, then the end user cannot completely remove management, which is to your advantage.

Jamf Pro 10.36.0 introduced a new API endpoint /v1/jamf-management-framework/redeploy/{id} to self-heal enrollments.

https://www.modtitan.com/2022/02/jamf-binary-self-heal-with-jamf-api.html

You can test with it directly in the API documentation without needing to script.

[howie_isaacks]

Thanks! I will look at this.

[MatG]

Try this
https://github.com/red5coder/Jamf-Framework-Redeploy

[howie_isaacks]

I like this! Thanks!!!!

[whiteb]

Looking for a way to do this, but in mass quantities.

I think jamf deprecated something server-side to where this script no longer works: https://www.modtitan.com/2022/02/jamf-binary-self-heal-with-jamf-api.html

I see I can do it through the API, or using that .app, but really hoping to do in batch quantities. Script on that website I'd linked used to work great.

[whiteb]

Disregard the above, the 'request auth token' function in my script wasn't correct, leading to '401 unauthorized' errors. Script still works as intended once fixing that.

[howie_isaacks]

Thanks for reminding me about this. I remember reading about it when Jamf Pro 10.36 was released. I tried this on my test Mac after running the "jamf removeFramework" command. It worked perfectly. This is a good kick in the butt to finally learn how to use the API. The API is the one major skill I lack with Jamf Pro. It has always been a matter of not needing to use it, so I didn't learn it.

[rocketman]

We just created a version of our script that allows you to make changes to a large number of devices based on a CSV or TXT file: https://github.com/Rocketman-Tech/Jamf-Self-Healing

[howie_isaacks]

I had an issue with this script last month. I reported it. I didn't see any response.

[Mrak]

Is it possible to automate it? 

[howie_isaacks]

I actually did find a way to automate this. Several months ago, I wrote a script that uses the API command to redeploy the Jamf framework. My script is basicaly the same as a lot of other scripts that do this. I just wanted to learn how to do it myself instead of using someone else's script. We have been having an issue with LAPS not working properly. My support team would try to use the password stored in a computer's inventory and find that it doesn't work. On investigation, I found that for some reason, the password rotation was not happening on some Macs. We are currently not using the MDM LAPS that would be setup during PreStage. We are using the Jamf binary LAPS that relies on a Mac to check-in and run inventories to get the password rotated. I created a policy that first deploys a script that deletes the LAPS account (management account), and then it deploys my script to run the Jamf management framework command to re-enroll the Mac. This recreates the Jamf binary LAPS account. The user is unaware that this happened since I first excluded their Mac from any enrollment policies that would be visible to the user. We are using an enrollment customization in our PreStage that prompts the user for their AD credentials but when a Mac gets re-enrolled by this policy, the login prompt does not appear. I can see that the information that gets pulled down from our LDAP connection is still present in User and Location. I am still testing this process to see if it causes any issues, but so far, it looks like a good way to re-enroll a Mac without the user being disturbed. For this to work, it does require that the Jamf binary is working properly.

[Mrak]

Can you share the script? Also can you share the criteria that you used for tracking out those devices. I set it up for checkin in last 24h and no inventory update in longer than 7 days. 

[howie_isaacks]

Here's the script. I recommend that you test it a lot to understand how it will work in your environment. 

#!/bin/zsh

# API login
jamfProURL="https://yourserver.jamfcloud.com"
username="apiuser"
password="SuperDuperSecretPassword"

# computer serial number
serialNumber=$(system_profiler SPHardwareDataType | grep Serial | /usr/bin/awk '{ print $4 }')

# request auth token
authToken=$( /usr/bin/curl \
--request POST \
--silent \
--url "$jamfProURL/api/v1/auth/token" \
--user "$username:$password" )

# parse auth token
token=$( /usr/bin/plutil \
-extract token raw - <<< "$authToken" )

tokenExpiration=$( /usr/bin/plutil \
-extract expires raw - <<< "$authToken" )

localTokenExpirationEpoch=$( TZ=GMT /bin/date -j \
-f "%Y-%m-%dT%T" "$tokenExpiration" \
+"%s" 2> /dev/null )

# determine Jamf Pro device id
deviceID=$(curl -s -H "Accept: text/xml" -H "Authorization: Bearer ${token}" ${jamfProURL}/JSSResource/computers/serialnumber/"$serialNumber" | xmllint --xpath '/computer/general/id/text()' -)
echo "The JSS ID of this computer is $deviceID"

# re-enrolling the Mac
echo "Running the Jamf management API command"
curl -X 'POST' \
  "$jamfProURL/api/v1/jamf-management-framework/redeploy/$deviceID" \
  -H 'accept: application/json' \
  -H "Authorization: Bearer $token" \
  -d ''

This Jamf Nation thread has a post of the extension attributes that I use to track down Macs with MDM issues. https://community.jamf.com/t5/jamf-pro/help-with-tracking-down-macs-that-are-not-communicating-over-... Since my script above uses MDM, it may not work on a Mac that is having trouble with MDM functionality. Right now, my dilemma is getting the Jamf binary LAPS account to work properly. The only way to get it working right is to remove and reinstall it.