Jamf Pro deprecating the ability to issue a Tomcat certificate from the Jamf Pro built-in certificate authority
As part of the release of Jamf Pro 10.30, the following entry was added to the Deprecations section of the Jamf Pro Release Notes:
Functionality to issue the Tomcat SSL/TLS certificate from Jamf Pro’s built-in certificate authority — Jamf Pro’s functionality to issue the Tomcat SSL/TLS certificate from the JSS built-in certificate authority (CA) will be discontinued in a future release of Jamf Pro. The release version for this change has not been determined.
Before this change occurs, it is recommended that all on-premise Jamf Pro instances leveraging this functionality switch to a publicly trusted third-party CA to issue the Tomcat SSL/TLS certificate. This will prevent the potential loss of MDM communication from Jamf Pro to enrolled devices.
If needed, a Tomcat SSL/TLS server certificate for Jamf Pro may be issued from an internal certificate authority. The JSS built-in CA will maintain its current ability to manually issue server certificates to other servers.
For shops which use Jamf Pro’s built-in certificate authority to create the SSL certificate used by the Tomcat web application, this means that at some point in the near(ish) future, you will need to plan to use a certificate for your Jamf Pro server which is no longer being issued by your Jamf Pro server’s built-in certificate authority.
For more details, please see below the jump.
Session videos from MacDevOps YVR 2021 now available
The MacDevOps YVR folks have posted the session videos for from MacDevOps YVR 2021, including the video for my Ride on the Release Train session.
For those interested, all of the the MacDevOps YVR 2021 session videos are available on YouTube. For convenience, I’ve linked my session here.
Slides from the “Ride on the Release Train” session at MacDevOpsYVR 2021
For those who wanted a copy of my talk at the MacDevOpsYVR 2021 conference, here are links to the slides in PDF and Keynote format.
PDF – https://tinyurl.com/MDOYVR2021PDF
Keynote – https://tinyurl.com/MDOYVR2021Keynote
WWDC 2021 notes
This week, like last year, I’m attending Apple’s WWDC 2021 conference from the comforts of home. As part of this, I’m taking notes during the labs and session videos. Due to wanting to stay on the right side of Apple’s NDA, I’ve been posting my notes to Apple’s developer forums rather than to here.
To make it easier for Mac admins to access them, I’ve set up a post in the forums where I’ve linking the various forum posts with my notes. It’s available via the link below:
Updated Jamf Pro MDM lock script to add reporting feature
Previously, I’d written a script to manage sending device lock commands using the Jamf Pro Classic API. After writing it, I thought that it would be a good idea if the script could also generate a report that could be handed off to others so I forked the script and updated it to generate a report in .tsv format. Since others might prefer the original script without the automatically generated report, I left that one alone and have made the forked copy into its own script. For more details, please see below the jump.
Using the Jamf Pro API to send device lock commands via MDM to multiple Macs
Most Mac admins have had this conversation at one point or another over the course of their careers:
“$Very Important Person left their Mac behind in a cab! What do we do?”
“OK, no worries. We can send a command to lock the computer or have it erase itself. Do you want it locked or wiped?”
At that point, the admin pulls up their MDM admin console and depending on what the response was (lock or wipe), send out the appropriate MDM command accompanied by a PIN code. Once received, the Mac will then turn itself into a paperweight which does or doesn’t erase itself.
Doing these one at a time is a pretty straightforward process. For example, here’s how it looks in Jamf Pro to send a device lock command via MDM:
1. Log into Jamf Pro using an account which can send lock commands via MDM.
2. Go to the appropriate computer inventory record.
3. Select the Management tab.
4. In the Management Commands section of the Management tab, click the Lock Computer button.
5. Enter the PIN code which will later be used to unlock the Mac. If desired, you can also enter a message which will appear on the lock screen.
6. Click the Lock Computer button.
7. Click the OK button in the confirmation window.
Once the device lock command has been sent, the Lock Computer button’s text should temporarily change to Command Sent.
For a small number of machines (10 or less), the method outlined above works fine. But once you get beyond that number, this process gets time-consuming and unwieldy. Fortunately, there is also a way to use the Jamf Pro Classic API to send device lock commands. For more details, please see below the jump.
Using curl for telnet testing on macOS High Sierra and later
As part of introducing macOS High Sierra, Apple removed the telnet tool from macOS. This was part of Apple’s overall effort to improve security, as telnet does not use encryption and its traffic can be intercepted and read. However, telnet did (and does) serve a useful function as a quick way to check if it is possible to connect to a remote server on a particular port.
While there are alternative tools available for this task (like netcat), it’s also possible to still create a telnet connection on macOS using another tool: curl
For more details, please see below the jump.
Blocking account logins to the ?failover login page on Jamf Pro
As part of Jamf Pro’s single-sign on (SSO) logins, there’s an option to bypass the SSO login using the following URL:
https://your.jamf.pro.server.here:8443/?failover
This URL is designed to let you bypass the SSO login page and take you to Jamf Pro’s own login, so that if your SSO provider is having a bad day, you can still log into your Jamf Pro server.
For those wanting to make sure that that their folks are only using SSO for logins, this can seem like a security hole. Fortunately, there’s a way to plug it. For more details, please see below the jump.
AutoPkg repo and logfile cleanup scripts for use with autopkg-conductor
As part of running autopkg-conductor over a long period of time, you may see a large percentage of disk space used on the Mac where you’re running AutoPkg and autopkg-conductor. This is because AutoPkg doesn’t remove older files from ~/Library/AutoPkg/Cache and autopkg-conductor does not remove older logfiles from ~/Library/Logs. To assist with this issue, I’ve written a couple of scripts. For more details, please see below the jump.
Using Signing Manager with autopkg-conductor
I’ve recently been working with Twocanoes Software’s Signing Manager in combination with my autopkg-conductor tool for managing AutoPkg runs. I’m happy to report it’s possible, but you may need to make some adjustments to how autopkg-conductor is being launched. For more details, please see below the jump.
Recent Comments