babgond

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

PDF: https://tinyurl.com/jnuc2022pdf
Keynote: https://tinyurl.com/jnuc2022key

As a follow-up to my earlier post about working with Microsoft Defender’s tamper protection, I’ve written an Extension Attribute for Jamf Pro which detects and reports on Defender’s tamper protection status. For more details, please see below the jump.

The Extension Attribute uses Defender’s mdatp command line tool to report on Defender’s tamper protection status. Once the mdatp tool is verified to be installed and executable, it’s used to check the tamper protection status. The EA will return one of the following values:

• 000
• 001
• 010
• 100

The returned values indicate the following:

• 000 = The /usr/local/bin/mdatp command-line tool cannot be found or is not executable.
• 001 = Tamper protection is fully disabled.
• 010 = Tamper protection is set to audit mode.
• 100 = Tamper protection is fully enabled.

The Extension Attribute is available below. It’s also available from GitHub using the following link:

https://github.com/rtrouton/rtrouton_scripts/blob/main/rtrouton_scripts/Casper_Extension_Attributes/check_microsoft_defender_tamper_protection_status

Following an upgrade to Jamf Pro 10.41.0, you may notice that you have an alert showing in the Jamf Pro admin console.

When you click on the alert, you will see the following alert notification.

Verification of SSL certificates is disabled.

There will be a link to enable SSL certificate verification.

If you click that link, it’ll take you to Management Settings: Computer Management – Management Framework: Security.

So now what? For more details, please see below the jump.

The SSL certificate in question is the SSL certificate used by Tomcat. Jamf is deprecating the use of self-signed certificates for Tomcat, as mentioned in the Jamf Pro 10.41.0 release notes:

Removal of unverified SSL certificates in Jamf Pro — In a future release of Jamf Pro the option to use an unverified SSL certificate for Jamf Pro will be removed. Customers with Cloud-hosted environments and those with a verified third-party certificate will see no changes. Customers with On-Premise environments using Jamf Pro’s built-in certificate authority to issue SSL certificates need to move to a trusted third-party certificate.

The alert is being triggered if you have the SSL Certificate Verification setting set to one of the following:

• Disabled
• Always except during enrollment

The Disabled setting means the Jamf Pro agent installed on a Mac isn’t verifying certificate trust at all for the SSL certificate that Tomcat is using.

The Always except during enrollment setting means that the Jamf Pro agent installed on a Mac isn’t verifying certificate trust for the SSL certificate that Tomcat is using at enrollment, but does verify that the SSL certificate is trusted for all subsequent communication.

Note: The Always except during enrollment setting was meant to ensure that Jamf Pro could install a root certificate for a self-signed certificate and establish certificate trust that way.

If your Jamf Pro service is using a publicly trusted SSL certificate, the fix is to set the SSL Certificate Verification setting to the following:

• Always

Selecting that setting and clicking the Save button will result in the following warning being displayed. If you’re certain you have a publicly trusted certificate, click OK. Otherwise, click the Cancel button to back the change out.

As long as you have a publicly-trusted SSL certificate for Tomcat, changing the SSL Certificate Verification setting to Always should have no impact. 

If you’re hosted in Jamf Cloud, you should already be using a publicly trusted SSL certificate. If you’re hosting Jamf Pro yourself, I recommend verifying that you’re using a publicly trusted certificate before making that change.

If you are hosting Jamf Pro yourself and don’t have a publicly trusted SSL certificate for Tomcat, I strongly recommend getting one as soon as possible. As Jamf’s release notes mention, the option to not use a trusted certificate will be removed from a future version of Jamf Pro.

One of the features of Microsoft Defender for macOS is tamper protection. This option is designed to prevent Defender or its settings from being removed or changed.

As of posting date, Defender’s tamper protection has three associated topics:

• Disabled: Tamper protection is completely off.
• Audit: Tampering operations are logged, but not blocked.
• Blocked: Tamper protection is on, tampering operations are blocked.

Microsoft has documentation regarding Defender’s tamper protection for macOS, available via the link below:

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/tamperprotection-macos

For more details, please see below the jump.

You can manage tamper protection via running commands via the command line, or via management profiles. The commands shown below allow tamper protection to be disabled completely, set to audit mode, or set to full tamper protection where Defender or its settings can’t be removed or changed.

To disable tamper protection, run the following command with root privileges:

To set tamper protection to audit mode, run the following command with root privileges:

To set tamper protection to full tamper protection mode, run the following command with root privileges:

If management via profiles is desired, the example profiles below will set Defender to audit mode or to full tamper protection.

Audit mode:

Full tamper protection:

To check the current Defender configuration, the following command can be run:

That should return output which looks similar to what’s shown below:

To check specifically for the tamper protection configuration, the following command can be run to check its status:

You should see the following output depending on the configuration:

Tamper protection disabled:

Tamper protection set to audit mode:

Tamper protection set to full tamper protection:

For folks with uninstall scripts for Microsoft Defender, they won’t be able to successfully uninstall Defender or its settings with tamper protection enabled. One way to address this is to add a section at the beginning of the uninstall script which can detect if full tamper protection is enabled and stop the script if it is. An example of this is shown below:

If full tamper protection is enabled, this example script will take the following actions:

1. Display the following message using osascript.

2. Exit after displaying the message.

Privileges is an open source tool from SAP which helps folks manage admin rights for their account. As part of its feature set, it includes an option for time-limited admin using a specific function called Toggle privileges.

However, Toggle privileges’s time-limited admin feature for Privileges is its most misunderstood feature. The reason is that while the ability to set a time limit is only available if you’re using the Toggle privileges function, many users assume that this time-limited admin is available universally to all the functions used to get admin rights using the Privileges app.

It is not. Time limited admin is only available using the Toggle privileges function. If you’re not using the Toggle privileges function, there is no time limitation and you cannot set one from within the Privileges app.

This information is available in the Privileges FAQ:

• Question: By default, is there a time limit on the admin rights granted by Privileges?
• Answer: No. Admin rights are granted until some process (like running Privileges again) takes them away.

• Question: Can I set Privileges to give me administrator rights for a defined amount of time?
• Answer: Yes. You can use the Toggle Privileges option on the dock icon to get admin rights for a set amount of time (the default amount is 20 minutes.)

What does this mean?

1. The only way time-limited admin is currently working on Privileges is by using the Toggle privileges function.
2. If you are clicking on the icon in the dock and not selecting the Toggle privileges function, there’s no time limit.
3. If you’re using the PrivilegesCLI command line tool, there is no time limit.

How long do you have admin if you’re not using the Toggle privileges function? Admin rights are granted until some process (like running Privileges again) takes them away. There’s no time limit.

All of the Privileges management options available for time-limited admin at this time apply only to the Toggle privileges function. If you’re using any of the management settings options listed below, they apply only and exclusively to the Toggle privileges function:

• DockToggleTimeout
• DockToggleMaxTimeout

They will not manage time-limited admin for any of Privileges’ functions outside of using the Toggle privileges function.

What if you want time-limited admin outside of using the Toggle privileges function? You will need to use a separate mechanism. In my case, I usually point folks towards using PrivilegesDemoter:

https://github.com/sgmills/PrivilegesDemoter

This tool uses a separate mechanism for figuring out the timing and then uses the PrivilegesCLI command line tool to take away admin when the time limit set for PrivilegesDemoter expires.

As a follow-up to a previous post, as part of that post I had been running certain shell commands by adding them to a .zshrc file:

• export PS1=”\$ “: Sets the prompt to only display “$” (no quotes) using the PS1 environmental variable.
• unset zle_bracketed_paste: Disable the zsh shell’s bracketed paste feature.

With some additional research, I learned that I could also run these commands using the Run command function which is available in your Terminal settings under the Shell tab.

To replicate what I wanted, I had to enable the Run command option in the Shell tab, then also set Run inside shell. Once those were enabled, I added the following shell commands:

export PS1="\$ " && unset zle_bracketed_paste && clear

• export PS1=”\$ “: Sets the prompt to only display “$” (no quotes) using the PS1 environmental variable.
• unset zle_bracketed_paste: Disable the zsh shell’s bracketed paste feature.
• clear: Removes all contents (including running the commands listed above) from the Terminal window.

The reason why this is nice is that I can now add running these commands to a macOS configuration profile using the CommandString key:

To see this used in context in a macOS configuration profile, please see below the jump.

The following profile sets the following settings:

• Font: Monaco 18 point size

Additional settings:

• Terminal prompt should not show the hostname or the logged-in user.
• Zsh’s bracketed paste feature is disabled

As part of writing documentation today, I was given a script to follow when making some videos as part of the documentation process. The script included the following requirement:

• Prepare the Terminal to not show the hostname or the logged-in user

By default, Terminal in macOS Monterey will show both. How to get rid of this?

Fortunately for me, @scriptingosx had already documented how to do this as part of this post. You can use the PS1 environmental variable to set how your prompt appears in Terminal. After some experimentation, I set the following environmental variable:

PS1="\$ "

To have this prompt appear whenever I opened a new Terminal session, I added the following line to a newly-created .zshrc file in my home folder:

export PS1="\$ "

The .zshrc file is a configuration file for the zsh shell, so adding that and then opening a new Terminal window gave me a prompt which looks like this.

As part of making the videos, I also noticed that when I copied and pasted a command into the Terminal that the pasted text was highlighted automatically. I’d seen this before and ignored it, but I thought it might be an unnecessary distraction for those watching this video later, so I went looking for how to disable it.

After some research, I found that this was zsh’s “bracketed paste” feature, which was introduced as part of zsh 5.1. This feature can be turned off using the following command:

unset zle_bracketed_paste

Adding entries for both the prompt and turning off bracketed paste to my .zshrc file gave me the Terminal behavior I wanted:

export PS1="\$ "
unset zle_bracketed_paste

I also performed additional customization of my Terminal experience, but those modifications were managed using a configuration profile. For more details on that, please see this previous post:

https://derflounder.wordpress.com/2019/12/19/deploying-terminal-profile-settings-using-macos-configuration-profiles/

I recently needed to prune some Time Machine backups, where I wanted to manually delete some older backups while not deleting everything on the drive. When I researched this, the guidance provided used the procedure described below:

1. Connect your external backup drive to your Mac if needed.
2. Launch the Time Machine app.
3. Use the timeline on the right of the screen or the arrows to navigate to the backup date you want to delete. Alternatively, use the Finder window to navigate to the file or folder you want to delete.
4. After selecting the date or file you want to delete, click the Action (…) button in Finder and choose to either Delete Backup or Delete All Backups of [Your File]

For an HFS+ formatted Time Machine backup drive, this guidance is correct. However, my Time Machine backup drive is APFS formatted. When following this guidance, I ran into the following issue:

1. Connect your external backup drive to your Mac if needed.
2. Launch the Time Machine app.
3. Use the timeline on the right of the screen or the arrows to navigate to the backup date you want to delete. Alternatively, use the Finder window to navigate to the file or folder you want to delete.
4. After selecting the date or file you want to delete, click the Action (…) button in Finder.

With APFS-formatted Time Machine backup drives, only the option to restore files is available. The Delete Backup or Delete All Backups options are not available.

So how can unwanted Time Machine backups be manually deleted? For more details, please see below the jump.

You can remove unwanted backups using either the Finder, or by using the tmutil command line tool.

To remove unwanted backups using the Finder, use the procedure described below:

1. Connect your external backup drive to your Mac if needed.
2. Open a new Finder window and select the backup drive.

You should see your backups listed in the Finder window.

3. Select the backup you want to delete and click the Action (…) button in Finder.

Note: You can also control-click on the desired backup to access the same options.

4. Select the Delete Immediately… option.

5. When prompted to confirm, click the Delete button.

Once confirmed, the backup should be deleted and disappear from the Finder window.

To remove unwanted backups using the tmutil command line tool, use the procedure described below:

1. Connect your external backup drive to your Mac if needed.

2. Open a Terminal window and run the following command:

tmutil listbackups

Note: You may be prompted to grant full disk access to the Terminal in order to run this command.

3. Identify the backup you want to delete. For this example, we’re using the following backup:

2022-07-01-154751.backup

To delete the backup using the tmutil command line tool, you need two items of information:

1. The path to the drive it is stored on.
2. The time stamp of the backup.

The path to the drive is going to depend on what the drive is named. In this example, the name of the drive is Backup so the path name should be as shown below:

/Volumes/Backup

The time stamp of the backup is going to be the name of the backup prior to the .backup part of the name. In this example, the backup is named 2022-07-01-154751.backup so the time stamp should be as shown below:

2022-07-01-154751

4. Once you have the path and time stamp, run the command shown below with root privileges to delete the backup:

tmutil delete -d /path/to/backup/drive -t timestamp_of_backup

You’ll need to provide the path and time stamp information using tmutil‘s -d flag for the path and the -t flag for the time stamp. For our example, where the path is /Volumes/Backup and the time stamp is 2022-07-01-154751, you would run the command shown below with root privileges to delete the backup:

tmutil delete -d /Volumes/Backup -t 2022-07-01-154751

The specified backup should be deleted.

5. Run the command shown below to verify that the backup has been removed:

tmutil listbackups

This post is focused on using Time Machine’s own tools to manage Time Machine backups, but you can also access and delete Time Machine APFS snapshots using Disk Utility on macOS Monterey. For more information on this, please see Howard Oakley‘s post linked below:

https://eclecticlight.co/2021/11/09/disk-utility-now-has-full-features-for-managing-snapshots/

The MacDevOps YVR folks have posted the session videos for from MacDevOps YVR 2022, including the video for my Managing Admin Rights in the Enterprise session.

For those interested, all of the MacDevOps YVR 2022 session videos are available on YouTube.

For convenience, I’ve linked my session here.

The good folks at Penn State have been posting session videos from the Penn State MacAdmins Campfire Sessions to YouTube. As they become available, you should be able to access them via the link below:

I’ve linked my Leveling Up – Managing admin rights in the enterprise session here: