Automating Jamf Infrastructure Manager setups on Red Hat Enterprise Linux

As part of a project, I needed to build an automated setup process for a Jamf Infrastructure Manager (JIM). Thanks to the help of some folks at Jamf, I have a process which runs non-interactively and which does the following on Red Hat Enterprise Linux 7.x:

1. Installs the JIM software
2. Enrolls the JIM with a Jamf Pro server

For more details, please see below the jump.

Creating a least privileged Jamf Pro user account for Jamf Infrastructure Manager setups

As part of working with the Jamf Infrastructure Manager (JIM), I wanted to see if I could find a least-privileged way to enroll a JIM with a Jamf Pro server. As it turns out, it’s pretty straightforward. For more details, please see below the jump.

Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. In my testing in 2016, everything seemed to work right and I didn’t see any problems with it on OS X El Capitan.

Fast forward a couple of years and a colleague of mine, Per Oloffson, began running into a weird problem with upgrading Macs from Sierra to High Sierra. When he upgraded Macs from macOS Sierra to macOS High Sierra, he was finding that Macs that had been migrated from AD mobile accounts to local accounts were having those same accounts break.

We had users who couldn't log back in after upgrading to High Sierra, as it turns out due to superfluous quoting in the AD unbinding script.

— Per Olofsson (@MagerValp) June 15, 2018

After a considerable amount of troubleshooting, he was able to narrow it down to the macOS High Sierra installer changing the password hash on those accounts. But why was it changing them?

The kicker was that they could log back in after unbinding to AD back in February. It was a ticking time bomb though, which blew up after the High Sierra upgrade.

— Per Olofsson (@MagerValp) June 15, 2018

In short, it was changing them because of a bug in my original MigrateADMobileAccounttoLocalAccount.command interactive migration script. Sorry, Per. For more details, please see below the jump.

Sending Jamf Pro notifications to Slack

One of the features offered by Jamf Pro is the ability to send notifications of various events to specified email addresses. Any Jamf Pro user account can be set up to receive these emails, so they’re a convenient way to be notified about events affecting your Jamf Pro service.

These notifications include the following:

• An instance of the Jamf Pro web application in a clustered environment fails
• An updated patch reporting software title is available
• Computer is enrolled using PreStage
• Database backup fails
• Database backup succeeds
• Error occurs during imaging
• Error occurs when policy runs
• Jamf Pro account is locked out because of excessive failed log in attempts
• Jamf Pro fails to add file to JDS instance or cloud distribution point
• License limit is exceeded
• One or more Memcached Endpoint(s) are not reachable
• Restricted software violation occurs
• Smart computer group membership changes
• Smart mobile device group membership changes
• Smart user group membership changes
• SSL certificate verification is disabled
• Tomcat is started or stopped
• VPP token is approaching expiration date

That said, I get enough emails on a daily basis that I’d prefer to have these notifications go to a channel in Slack. That way, my whole team can be notified about issues and there’s a searchable log of when events occurred.

There are solutions for sending notifications directly to Slack, but I wanted to avoid using middleware in favor of using the built-in notifications in Jamf Pro. Fortunately, there’s a way to do that using tools available from Slack. For more details, see below the jump.

Updated Xcode command line tools installer script now available

A while back, I developed a script that will download and install the Xcode Command Line Tools on Macs running 10.7.x and higher.

Most of the time it works fine. However, starting with macOS Sierra and continuing on with macOS High Sierra, I occasionally ran into an odd problem. Apple would sometimes have both the latest available Xcode Command Line Tools installer and the just-previous version available on Apple’s Software Update feed.

The original script was written with the assumption that there would only be one qualifying Xcode Command Line Tools install option available at any one time. When more than one is available, the script isn’t able to correctly identify which Xcode Command Line Tools it should be installing. The result is that the script ends without installing anything.

Apple usually removes the previous version from the Software Update feed within a few days, which allows the script to work normally again. But when it happened this time, I decided to update the script to hopefully fix this issue once and for all. For more details, please see below the jump.