babgond

I recently had a need to set up an on-premise Jamf Pro server for some quick testing. In this case, I needed to set up a Jamf Pro server with the following characteristics:

1. MySQL 8.x installed on the same server as the Jamf Pro Tomcat software
2. Jamf Pro set up as a single instance and not clustered. 

To help simplify the process, I went back to some previous work. I had previously written a script for AWS’s Lightsail service which does the following on Ubuntu LTS:

1. Downloads a Jamf Pro installer from a defined download URL
2. Installs OpenJDK 11, MySQL 8.x Community Server and other tools
3. Creates a new MySQL database for Jamf Pro’s use
4. Installs Jamf Pro
5. Configures Jamf Pro to use the new MySQL database

I’ve now updated it to do the following on Ubuntu 22.04 LTS:

1. Downloads the Jamf Pro 11.x installer from a defined download URL
2. Installs OpenJDK 11, MySQL 8.x Community Server and other tools
3. Creates a new MySQL database for Jamf Pro’s use
4. Installs Jamf Pro 11.x
5. Configures Jamf Pro 11.x to use the new MySQL database

Even though it was written for use with Lightsail, the script should work on any Ubuntu 22.04 LTS install. It’s available via the link below:

https://github.com/rtrouton/aws_lightsail/tree/master/lightsail_jamf_pro_setup/lightsail_jamf_pro_setup_with_mysql_8

I have a Jamf Pro server which is connected to Microsoft’s Entra ID for its directory service. Recently, I received an email from Microsoft letting me know that the SAML signing certificate for the Entra ID app I was using to provide a connection between Jamf Pro and Entra ID was coming up for expiration in about 30 days.

This certificate is used by Entra ID to sign the SAML tokens being issued to the Entra ID app and by default, this certificate is good for three years. For those interested, Microsoft has a KBase article available with more information about this topic:

Tutorial: Manage certificates for federated single sign-on: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on

The instructions for rotation of this certificate are pretty straightforward and were provided in the email sent to me by Microsoft.

I scheduled the rotation during a planned maintenance downtime and everything appeared fine once the new SAML signing certificate was in place and active.

However, when I logged into Jamf Pro following the certificate rotation, I noticed I had a new notification appearing:

Signing Certificate issued by SSO Identity Provider is expiring in 30 days

Since I had just rotated the SAML signing certificate and had verified that the new one (which does not expire in 30 days) was the active one, this message was concerning. After some research, I ran across a Jamf Nation discussion which provided an explanation for the message:

Even though the old SAML signing certificate was now marked as inactive, Jamf Pro was still detecting its presence and reporting (correctly) that it would expire in 30 days.

From there, the solution was straightforward: Delete the inactive SAML signing certificate from Entra ID.

This left only the active SAML signing certificate listed in Entra ID. This certificate has an expiration date greater than 30 days.

Once the inactive SAML signing certificate was deleted, Jamf Pro took about twenty minutes to register that fact. After that, the notification message disappeared from Jamf Pro without additional actions needed on my part

An issue that some Mac admins have had to deal with is that their system management tool is using MDM commands to install installer packages. This usually applies if the system management tool does not have an agent installed on the managed Macs and instead is using only MDM for management.

In those cases, installer packages must have the following attributes for a successful installation via MDM command:

1. Signed with an Apple Developer ID Installer certificate
2. Be a distribution installer package

For criteria #2, this references the fact that there are two kinds of modern installer packages for macOS:

• Component packages: these are the standard type of installer package, which contain an archive of files to install and the information on where the files should be installed.
• Distribution packages: These packages can contain one or more component packages, and may also include additional resources to customize and control the user interface shown in the Installer application.

Both component and distribution packages use the same icon by default, so you can’t tell the difference by visually looking at an installer package. However, you can use the xar command line tool to check inside an installer package and list the files stored inside. The reason why this helps is that all distribution packages will have a file inside named Distribution and component packages will not.

To check an installer package to see if it is a distribution package, use the command shown below:

If it’s a distribution package, you should get output similar to this:

If it’s not a distribution package, you should get output similar to this:

If it is not a distribution package, you can use the productbuild command line tool to convert the installer package into a distribution package. To convert a component installer package to a distribution installer package, use the command shown below:

In this case, package_being_converted_to_distribution.pkg is the name of the package that you want to convert to a distribution package and new_distribution_package.pkg is the name you want to give to the newly-created distribution package.

Note: If converting a signed installer package, the new distribution package will not be signed. If needed, you will need to sign the distribution package following its creation.

Thanks to the folks in the #packaging channel of the Mac Admins Slack who assisted with providing information for this post.

Apple deprecated its OpenBSM audit system beginning with macOS Big Sur, but the audit system itself stayed enabled until the release of macOS Sonoma. As of macOS Sonoma, it is now disabled and does not run by default. The man page includes this deprecation notice section:

If you still need to have the OpenBSM audit system running on macOS Sonoma, it’s possible to re-enable it using the procedure described in the man page. For more information, please see below the jump.

Check if it’s already running

Before enabling, I recommend verifying that it’s not already running. For example, I know that Jamf Pro 10.50 and later will re-enable the OpenBSM auditing system on macOS Sonoma Macs. Please use the procedure below to check and see if something else has already enabled the OpenBSM audit system.

1. Run the following command with root privileges:

If it’s already enabled and running, you should see output similar to what’s shown below:

Enable OpenBSM auditing

If it’s not running you should see output similar to what’s shown below:

If the OpenBSM audit system is not running and you want to enable it, please use the procedure described below:

1. Run the following command with root privileges:

2. Run the following command with root privileges:

3. Restart the Mac.

4. Following the restart, verify that the auditd service is enabled by running the following command with root privileges:

You should see output similar to what’s shown below:

Note: If you have a custom configuration for OpenBSM auditing, you’ll need to add those configuration settings to the following file:

/etc/security/audit_control

For more information on configuration of OpenBSM auditing, please see the audit_control man page or my earlier post on OpenBSM auditing.

The documentation from MacSysAdmin 2023 is available, with the session slides and videos being accessible from the link below:

http://documentation.macsysadmin.se

The video of my session is available for download from here:

• Introduction to Declarative MDM: https://docs.macsysadmin.se/2023/video_h265/Day1Session4.mp4

I also like to thank Patrik Jerneheim again for inviting me to speak at this year’s MacSysAdmin.

Since the release of macOS High Sierra, it has been possible to enable Touch ID authentication for the sudo tool. However, the necessary modifications needed to be re-applied after every update to macOS because the modified file would get overwritten with the OS’s default values each time macOS was updated.

As of macOS Sonoma though, this modification can now be persistent. Apple included the following note as part of the the What’s new for enterprise in macOS Sonoma KBase article:

Touch ID can be allowed for sudo with a configuration that persists across software updates using /etc/pam.d/sudo_local. See /etc/pam.d/sudo_local.template for details.

When examined on macOS Sonoma 14.0.0, the contents of the /etc/pam.d/sudo_local.template file are as shown below:

Copying the /etc/pam.d/sudo_local.template file to /etc/pam.d/sudo_local and uncommenting the indicated line allows Touch ID to work for authentication to the sudo tool.

To assist with the process of enabling and disabling Touch ID authentication for the sudo tool, I’ve written a couple of scripts. For more details, please see below the jump.

The scripts are available via the link below:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/enable_and_disable_touch_id_for_sudo

There are two scripts available at the above location:

• enable_touch_id_auth_for_sudo.sh: Enables Touch ID identification for the sudo tool.
• disable_sudo_touch_id_auth.sh: Disables Touch ID identification for the sudo tool.

Both scripts are set to check if they are being run on macOS Sonoma or later, and will exit with a message if they are run on an earlier version of macOS.

For those who wanted a copy of my declarative device management talk at MacSysAdmin 2023, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/MacSysAdmin2023PDF
• Keynote: https://tinyurl.com/MacSysAdmin2023Keynote

As part of the release of macOS Sonoma 14.0.0, there is a bug which may be triggered if you have deployed a configuration profile which sets password rules for local accounts. An example profile is shown below:

In those cases, you may see one or the other following notifications when you log into macOS Sonoma for the first time.

These notifications don’t actually indicate a problem and clicking on them does nothing but make the messages disappear. However, for shops which are using profiles which set local account password rules, these messages will almost certainly cause tickets asking “What is this and what does it mean?” from your user community.

I have filed feedback with Apple regarding this issue. For those wishing to reference it, it is Feedback # FB12845634.

For the initial release of Sonoma, the best solution identified so far is to suppress the notifications for local password management, to make sure that these notifications don’t appear until Apple releases an update to macOS Sonoma which addresses this problem. To assist with this, I have an example profile available from the link below:

https://github.com/rtrouton/profiles/tree/main/DisableAppleLocalUserAccountPasswordNotifications

Note: The example profile linked above will suppress all local account password policy notifications. If you are using local account password policy notifications for other purposes, this solution may not work for you.

The component in macOS which generates the local account password notifications also exists on macOS Ventura, so you should be able to deploy a profile like the one linked above to macOS Ventura. This should ensure that Macs upgrading to macOS Sonoma also have these notifications suppressed from the start on macOS Sonoma 14.0.0.

Every so often, something gets added to macOS and enabled by default where I wish it was off by default. In macOS Sonoma, that’s the new Click wallpaper to reveal desktop option, which works like this by default.

1. Click on an empty spot on the desktop.
2. Watch your open windows disappear off-screen.

Apple does include a one-time message which explains the behavior, but if you click away from the message it won’t re-appear when you click again on an empty spot on the desktop.

This behavior is managed in System Settings: Desktop & Dock and is listed as the Click wallpaper to reveal desktop setting. This has two settings:

• Always
• Only in Stage Manager

The default behavior is Always. To stop making your windows disappear whenever you click on the desktop, select Only in Stage Manager.

Fortunately for my preferences, I was able to figure out that the Click wallpaper to reveal desktop behavior was controlled via the following setting:

• Domain: com.apple.WindowManager
• Key: EnableStandardClickToShowDesktop
• Value: Boolean

To set the Click wallpaper to reveal desktop setting to Always, run the following command as the logged-in user:

To set the Click wallpaper to reveal desktop setting to Only in Stage Manager, run the following command as the logged-in user:

In my case, I wanted this setting permanently set to Only in Stage Manager so I’ve also written a profile which can enforce this. It’s available via the link below:

https://github.com/rtrouton/profiles/blob/main/ManageClickWallpaperToShowDesktopItems

For those who wanted a copy of my installer package scripting talk at Jamf Nation User Conference 2023, here are links to the slides in PDF and Keynote format.

• PDF – https://tinyurl.com/JNUC2023PDF
• Keynote – https://tinyurl.com/JNUC2023Keynote