During JNUC2023, not only was I invited to speak on a panel but I also delivered a talk, titled: Extracting data from Jamf Pro: Hints, Tips and Tricks.
See below for a link to the video, the GitHub repo with all of the links as well as PDF of the slides, and lastly a link to the JNUC2023 playlist.
Continue readingA couple of days ago, a high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Log4j 2 utility was disclosed publicly via the project’s GitHub.
The vulnerability itself allows for Remote Code Execution (RCE) by logging a certain string, with the potential the impact of the exploit being full server control.
More information on this vulnerability can be found at numerous sources, including the below:
Log4j 2 is included within Jamf Pro for logging, but don’t panic!
If you’re a Jamf Cloud customer, then this has already been mitigated as per this post on Jamf Nation.
If you self host Jamf Pro, then the below applies:
Jamf Pro versions older than 10.14 are vulnerable to this issue. Versions 10.14 through 10.34 include Java 11, which partially mitigates the issue. The Jamf Pro 10.34.1 release was made available to address the issue completely. Please update to this version as soon as possible.
https://community.jamf.com/t5/jamf-pro/third-party-security-issue/td-p/253740
If you cannot upgrade to 10.34.1, you can manually update Log4j as per the steps documented here.
And, if you are having to upgrade from a few versions behind, don’t go alone.. take this.
As forewarned by Apple, Richard Purves and recently one of my dataJAR colleagues Richard Mallion, Apple is making a change to APNs on March 31, 2021.
As detailed within the dataJAR blog post, this change is between MDM servers and Apple and not managed devices.
Since Jamf Pro 10.23.0, there has been a toggle to enable this change to HTTP/2 for APNs communication.
However with Jamf Pro 10.28.0 release earlier this week, Jamf Pro will default to HTTP/2 and if you’re self hosting Jamf Pro this release will flip over the APNs communication to use HTTP/2.
If you’re Jamf Cloud, then this change has already been made for you.
So, this short post is just to bring attention to this change for those that need it.
And if you’d like to know more, for more info see the aforementioned blog post on the dataJAR blog.
At dataJAR, I recently worked with a customer which wanted to make use of Jamf Pro’s Enrollment Customization option.
However, with everything setup, we were presented with the message “Error <kCFErrorDomainCFNetwork:303>” whenever trying to load any of the defined PreStage Panes.
I reached out to Jamf Support, but they hadn’t see this issue & searching the macadmins Slack didn’t bring up anything either.
Long story short (& in an attempt to not create my own DenverCoder9 moment), we discovered the issue to be down to the environments ingress controller being configured with HTTP/2 support by default.
As soon as we disabled HTTP/2, everything worked as expected.
Hope this helps someone else too.
With the release of Jamf Pro 10.20.0, Jamf has fixed [PI-007508]. This is the PI for DEP Sync failing due to TLS changes being needed for on-prem installs & one which I blogged here.
The fix from Jamf forces TLS1.2 for connections to Apple for DEP/Automated Device Enrollment.
So, if you made a change to your TLS settings as I mentioned in my previous blog post, you can remove those changes.
At dataJAR, we’ve been running all datajar.mobi deployments with no TLS settings enforced via our setenv.sh for a couple of weeks now & all is syncing as expected.
Within a few posts here & during our JNUC 2019 talk, James & I detailed how we at dataJAR deal with managing 100+ Jamf Pro & released a few repos with various items we use day-to-day.
This blog post is concerned with one of those repos, which is titled: JAMFSoftwareServer.log Messages.
The repo can be accessed via the hyperlink above.
This repo contains a list of messages which can appear in the JAMFSoftwareServer.log, with a note as to what action might be required due to the messages being generated.
For more details see below, else click the link & PR’s are welcomed to expand the repo.
Continue reading
Tonight, Apple released macOS Catalina.
See below on how to block this upgrade with Jamf Pro.
Continue reading
A week after the recent updated Terms & Conditions, we saw DEP sync errors reappear in our datajar.mobi deployments.
Below is some detail on what has caused these new sync errors & how to resolve.
Continue reading
Last night, Jamf released Jamf Pro 10.13.1 & 10.15.1. These were released due to PI-007507.
This PI is noted as a “critical security vulnerability” which “does not pose a risk to private data or managed devices. It does have the potential to impact the integrity and availability of your web server” but “impacts versions of Jamf Pro 9.4 and later”
As Jamf Pro 10.15.0 was only released 19 days ago, 10.15.1 is the 10.15.0 release with PI-007507 having been patched.
However, for organisations that are still on Jamf Pro 10.13.0 or below due to the move to Java 11 needed for Jamf Pro 10.14.0+, Jamf have released 10.13.1, which is also patched.
Please read the following Jamf Nation post for more information, & if you’re not on a recent Jamf Pro release please also see this post before any upgrades are attempted.
Recently we updated all our datajar.mobi instances to Jamf 10.7.1, for Mojave support.
All went well. Except for a couple of instances where their Jamf Infrastructure Manager was being used as an LDAP Proxy.
Well, turns out this was a change to Java 8 Update 181, which we updated to at the same time. And, that this is an issue not just with Jamf Infrastructure Manager, but could be with LDAPS in general.
Below details these changes, & overcoming this issue.
Continue reading