Disabling login window clock display on macOS Sonoma

One of the changes with macOS Sonoma is to the login window, where the username blanks and icons were made smaller and moved down to the bottom of the screen and a large clock display is enabled by default near the top of the login window.

For folks who don’t want the clock display, it’s possible to turn it off via System Settings. In the Lock Screen settings, set the Show large clock option to one of the following settings:

• On Screen Saver and Lock Screen
• On Lock Screen
• Never

The Never setting will stop from being displayed on either the login window or as part of the screen saver.

For more information, please see below the jump.

Clearing the logged-in Microsoft SSO user on macOS using Microsoft’s Company Portal app

As part of working on a task recently, I ran into an issue with Microsoft’s Enterprise SSO plug-in on macOS. This plug-in enables single sign-on for Entra ID accounts for applications which support it. In this case, the issue was the following:

Desired behavior:

1. Open application.
2. Click the login button.
3. Be prompted for the Entra ID user account to sign in with.
4. Log in with that user account.

Actual behavior:

1. Open application.
2. Click the login button.
3. Be automatically logged in as the Entra ID user registered for single sign-on.

Unfortunately for my use case, I really needed to have the application in question prompt the user for which account they needed to log in with because a user account other than the one registered for single sign-on needed to be able to sign in to the application in question.

After some discussion in the #jamf-intune-integration channel in the Mac Admins Slack, I was pointed towards a way to sign out the account which was enabled for single sign-on using Microsoft’s Company Portal application. With no account enabled for single sign-on, the application would now prompt for a user account to sign in with. For more details, please see below the jump.

How many NTP time servers does macOS support? One

The subject of the blog post reveals the main discussion point of this post, which is that macOS since macOS 10.13.x High Sierra has only supported setting one NTP (Network Time Protocol) server as a way to set the system time in macOS. For more on this, please see below the jump.

Preparing installer packages for installation using MDM commands

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:

xar -tf /path/to/pkg_name_goes_here.pkg | grep -o Distribution

view raw

gistfile1.txt

hosted with ❤ by GitHub

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

	username@computername ~ % xar -tf /path/to/pkg_name_goes_here.pkg | grep -o Distribution
	Distribution
	username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

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

	username@computername ~ % xar -tf /path/to/pkg_name_goes_here.pkg | grep -o Distribution
	username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

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:

/usr/bin/productbuild –package /path/to/package_being_converted_to_distribution.pkg /path/to/new_distribution_package.pkg

view raw

gistfile1.txt

hosted with ❤ by GitHub

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.

Re-enabling OpenBSM auditing on macOS Sonoma

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:

	DEPRECATION NOTICE
	The audit(4) subsystem has been deprecated since macOS 11.0, disabled since macOS 14.0, and WILL BE REMOVED in a future version of macOS. Applications that
	require a security event stream should use the EndpointSecurity(7) API instead.
	On this version of macOS, you can re-enable audit(4) by renaming or copying /etc/security/audit_control.example to /etc/security/audit_control, re-enabling the
	system/com.apple.auditd service by running launchctl enable system/com.apple.auditd as root, and rebooting.

view raw

gistfile1.txt

hosted with ❤ by GitHub

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.

Enabling Touch ID authentication for sudo on macOS Sonoma

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:

	# sudo_local: local config file which survives system update and is included for sudo
	# uncomment following line to enable Touch ID for sudo
	#auth sufficient pam_tid.so

view raw

gistfile1.txt

hosted with ❤ by GitHub

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.

Suppressing undesired local account password policy notifications on macOS Sonoma

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:

	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
	<plist version="1.0">
	<dict>
	<key>PayloadContent</key>
	<array>
	<dict>
	<key>PayloadDisplayName</key>
	<string>Passcode</string>
	<key>PayloadIdentifier</key>
	<string>com.apple.mobiledevice.passwordpolicy.3BCA8E01-3CB9-4D6B-8338-518C51B80AAF</string>
	<key>PayloadType</key>
	<string>com.apple.mobiledevice.passwordpolicy</string>
	<key>PayloadUUID</key>
	<string>F0B7EB5D-5DF1-4DDC-8A80-01CA458E6157</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
	<key>allowSimple</key>
	<false/>
	<key>forcePIN</key>
	<true/>
	<key>maxFailedAttempts</key>
	<integer>10</integer>
	<key>minLength</key>
	<integer>15</integer>
	<key>minutesUntilFailedLoginReset</key>
	<integer>15</integer>
	<key>requireAlphanumeric</key>
	<true/>
	</dict>
	</array>
	<key>PayloadDescription</key>
	<string>Sets password rules for local accounts on this Mac.</string>
	<key>PayloadDisplayName</key>
	<string>Local Account Password Rules</string>
	<key>PayloadIdentifier</key>
	<string>com.company.9EF1E03A-5DEB-4D1F-9E14-D76AFF153C35</string>
	<key>PayloadOrganization</key>
	<string>Company Name</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>40829036-5EAF-42C9-9678-D27F0C28654B</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
	</dict>
	</plist>

view raw

Local Account Password Rules.mobileconfig

hosted with ❤ by GitHub

 

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.

 

Managing the “Click wallpaper to reveal desktop” setting in macOS Sonoma

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:

/usr/bin/defaults write com.apple.WindowManager EnableStandardClickToShowDesktop -bool true

view raw

gistfile1.txt

hosted with ❤ by GitHub

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

/usr/bin/defaults write com.apple.WindowManager EnableStandardClickToShowDesktop -bool false

view raw

gistfile1.txt

hosted with ❤ by GitHub

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

Blocking Oracle Java

As a follow-up to my previous post on removing Oracle Java, it’s possible that Mac admins may be requested to block Oracle Java in place of removing it. This may be challenging, but possible with the right information and tools. For more details, please see below the jump.

Removing Oracle Java from macOS

As of January 23, 2023, Oracle made a change to how they’ve licensed Oracle’s Java (which is a separate license from the ones used for open source Java distributions like OpenJDK.) The new license terms are described here in Oracle’s FAQ, but to summarize the main difference between the old licensing and the current licensing is that Oracle introduced a new employee-based metric.

• Old license: License costs were based on how many employees your company has which used Oracle’s Java.
• Current license: License costs are based on how many employees your company has.

See the difference? Previously, if your company had 1000 employees and 2 used Oracle’s Java for purposes which required payment under the old license, the company paid for 2 licenses. Under the current license, if your company has 1000 employees and 2 use Oracle’s Java, Oracle may say that now the company needs to pay for 1000 licenses.

There’s more to it and I am not the person to turn to when needing explanation of complex legal and financial questions, but the operational consequence for Mac admins is that companies which had previously been OK with Oracle Java being installed on their Macs may now be coming to their Mac admins, asking how Oracle Java can be removed and kept off.

To assist with this, I’ve written a script which should remove Oracle Java JREs and JDKs on macOS. For more details, please see below the jump.