Slides from the “SAP In The Haus” session at Penn State MacAdmins 2021

July 15, 2021 2 comments

For those who wanted a copy of my talk from Penn State MacAdmins 2021, here are links to the slides in PDF and Keynote format.

AutoPkg recipes for OS X Lion and OS X Mountain Lion OS installers now available

June 30, 2021 Leave a comment

Now that Apple has made direct download links available for Lion and Mountain Lion, I’ve written AutoPkg .download and .pkg recipes for the following OS X installers:

These recipes will download the disk images linked to the relevant KBase articles, extract the installer packages stored inside the disk images and rename the disk images and installer packages with the OS name and version number.

One thing to be aware of is that the downloaded installers do not themselves install the relevant version of OS X. Instead, they install the Install.app for that version of OS X into the /Applications directory.

Screen Shot 2021 06 30 at 5 36 49 PM

Another thing to know is that the downloaded installers are signed using Software Update signing certificates which expired in 2019. As of June 30th, 2021, I do not know if Apple is planning to re-sign the installers with the current Software Update signing certificate.

Screen Shot 2021 06 30 at 4 26 25 PM

One of the consequences of this is that I cannot use AutoPkg’s code signature verification as part of the AutoPkg recipes, since AutoPkg’s current code signature verification will error when it hit the expired certificates. If Apple does choose to re-sign these certificate with valid non-expired signing certificates, I’ll add code signature verification to the recipes.

If you do need to use these installers, setting the system clock on your Mac to a date and time before the October 24th 2019 expiration date will allow these certificates to appear as valid again and any expiration-related issues should go away.

The AutoPkg recipes are available via the links below:

OS X Lion: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXLion
OS X Mountain Lion: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXMountainLion

Categories: AutoPkg, Mac OS X, OS X

Backing up Self Service bookmarks for Jamf Pro 10.30.0 and later

June 23, 2021 Leave a comment

A while ago, I wrote a post on how to back up your Jamf Pro Self Service bookmarks. I’ve been using that process to back up my bookmarks and it’s been working fine until after my upgrade to Jamf Pro 10.30.0. At that point, my script stopped working. When I checked into it and talked with some colleagues, it became apparent that Jamf had made a change with how they stored bookmark information for Self Service.

In 10.29.x and earlier, Jamf had stored bookmarks as individual plist files in the following location:

/Library/Application Support/JAMF/Self Service/Managed Plug-ins

Screen Shot 2020 09 27 at 11 31 16 AM

In 10.30.x and later, the /Library/Application Support/JAMF/Self Service/Managed Plug-ins directory has disappeared.

Screen Shot 2021 06 23 at 10 37 24 AM

Jamf now stores bookmark information inside an XML file named CocoaAppCD.storedata in the user’s home folder at the following location:

~/Library/Application Support/com.jamfsoftware.selfservice.mac/CocoaAppCD.storedata

Screen Shot 2021 06 23 at 10 35 51 AM

Inside the CocoaAppCD.storedata file, the bookmarks are stored as XML objects similar to what is shown below:

<object type="SSBOOKMARK" id="z169">
<attribute name="url" type="string">https://www.bananas.com</attribute>
<attribute name="priority" type="int64">5</attribute>
<attribute name="displayinbrowser" type="bool">1</attribute>
<attribute name="name" type="string">Bananas.com</attribute>
<attribute name="jssdescription" type="string">Bananas.com</attribute>
<attribute name="installstatus" type="int64">0</attribute>
<attribute name="id" type="int64">2</attribute>
<attribute name="iconurl" type="string">https://ics.services.jamfcloud.com/icon/hash_95740013589cddd19b2192016788dd9e91e735f8ff5213f92005f4eb92ac16b6</attribute>
<attribute name="compliance" type="bool">0</attribute>
<attribute name="buttontext" type="string">Open</attribute>
</object>

view raw
Bananas.com.xml
hosted with ❤ by GitHub

Screen Shot 2021 06 23 at 4 22 03 PM

Fortunately, I was able to figure out a way to do the following:

  1. Parse the document for the bookmark XML objects.
  2. Split them out into individual XML files.
  3. Name the files using the title of the Self Service bookmark.

For more details, please see below the jump.

Read more…

Jamf Pro deprecating the ability to issue a Tomcat certificate from the Jamf Pro built-in certificate authority

June 15, 2021 1 comment

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.

Screen Shot 2021 06 15 at 3 08 31 PM

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.

Screen Shot 2021 06 15 at 3 11 52 PM

For more details, please see below the jump.

Read more…

Categories: Jamf Pro, Java, Linux, PKI

Session videos from MacDevOps YVR 2021 now available

June 14, 2021 1 comment

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

June 10, 2021 Leave a comment

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

June 8, 2021 Leave a comment

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:

https://developer.apple.com/forums/thread/681818

Categories: Documentation, WWDC 2021

Updated Jamf Pro MDM lock script to add reporting feature

June 1, 2021 1 comment

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.

Read more…

Using the Jamf Pro API to send device lock commands via MDM to multiple Macs

May 28, 2021 1 comment

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.

Screen Shot 2021 05 28 at 2 48 00 PM

3. Select the Management tab.

Screen Shot 2021 05 28 at 2 48 01 PM

4. In the Management Commands section of the Management tab, click the Lock Computer button.

Screen Shot 2021 05 28 at 1 57 43 PM

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.

Screen Shot 2021 05 28 at 1 58 56 PM

6. Click the Lock Computer button.

Screen Shot 2021 05 28 at 1 58 57 PM

7. Click the OK button in the confirmation window.

Screen Shot 2021 05 28 at 1 59 42 PM

 

Once the device lock command has been sent, the Lock Computer button’s text should temporarily change to Command Sent.

Screen Shot 2021 05 28 at 1 59 49 PM

 

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.

Read more…

Using curl for telnet testing on macOS High Sierra and later

May 23, 2021 Leave a comment

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.

Read more…

Categories: Mac administration, macOS
%d bloggers like this: