Archive

Archive for the ‘Mac administration’ Category

Apple discontinues macOS Server

April 21, 2022 Leave a comment

After a long run, first beginning with Mac OS X Server 1.0 in 1999, Apple has announced the end of macOS Server as of April 21, 2022. The final version is macOS Server 5.12.2, which runs on macOS Monterey.

Screen Shot 2022 04 21 at 1 46 23 PM

macOS Server 5.12.2 has shed many of the features once supported by macOS Server. As of 5.12.2, the following two services are supported:

Both services are not currently available outside of macOS Server, so Apple discontinuing macOS Server also means the end of the line for Apple’s Open Directory directory service and Apple’s Profile Manager MDM service.

For current customers who have purchased macOS Server, macOS Server 5.12.2 remains available in the App Store.

Screen Shot 2022 04 21 at 1 42 03 PM

Building a Privileges installer package using AutoPkg

April 20, 2022 Leave a comment

In working with folks who want to build installer packages to install the Privileges app, I’ve noticed that a number of them have experienced problems with manually building an installer package for Privileges which correctly installs the Privileges app’s helper tool.

The result of an installer which does not install the helper tool correctly is that when a user requests administrator privileges using the Privileges app, the app prompts them to install the helper tool. This requires administrative rights, which sets up a chicken and egg situation where admin privileges are being required to get admin privileges.

Screen Shot 2022 04 20 at 3 45 38 PM

Fortunately, there is an automated method for building the installer package which (so far) has worked correctly in each case I’m familiar with. There are AutoPkg recipes available for creating a Privileges installer package and AutoPkg is able to build a correctly working Privileges installer package.


computername:~ username$ autopkg search com.github.rtrouton.Privileges
Name Repo Path
—- —- —-
Privileges.munki.recipe apfelwerk-recipes Privileges/Privileges.munki.recipe
Privileges.install.recipe rtrouton-recipes Privileges/Privileges.install.recipe
Privileges.munki.recipe rtrouton-recipes Privileges/Privileges.munki.recipe
Privileges.jss.recipe rtrouton-recipes JSS/Privileges.jss.recipe
Privileges.pkg.recipe rtrouton-recipes Privileges/Privileges.pkg.recipe
Privileges.download.recipe rtrouton-recipes Privileges/Privileges.download.recipe
To add a new recipe repo, use 'autopkg repo-add <repo name>'
computername:~ username$

view raw

gistfile1.txt

hosted with ❤ by GitHub

For more details, please see below the jump.

Read more…

Payload-Free Package Creator 2.4 now available

April 3, 2022 Leave a comment

Payload-Free Package Creator.app, an Automator application that allows the selection of an existing script and then create a payload-free package that runs the selected script, has been updated to version 2.4.

The functionality and operations of the app have not changed from Payload-Free Package Creator 2.3. The main change is that Payload-Free Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Payload-Free Package Creator 2.4, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Payload-Free-Package-Creator

Simple Package Creator 1.5 now available

April 2, 2022 Leave a comment

Simple Package Creator.app, an Automator application that will allow the selection of a self-contained application and creates an installer package that enables the installation of the application with pre-set permissions into /Applications, has been updated to version 1.5.

The functionality and operations of the app have not changed from Simple Package Creator 1.4. The main change is that Simple Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Simple Package Creator 1.5, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Simple-Package-Creator

profiles command includes client-side rate limitation for certain functions on macOS 12.3

March 22, 2022 6 comments

One of the changes brought with macOS 12.3 is that the profiles command line tool now includes a rate limiter for some of its functions:

profiles show

Screen Shot 2022 03 22 at 3 55 30 PM

profiles validate

Screen Shot 2022 03 22 at 3 55 47 PM

In both cases, running these functions may be limited to once every 23 hours.

For those familiar with rate limitation on the server side, where a server may choose to limit how many calls can be received in a set period from a client, this rate limitation is similar but is set and managed entirely on the client side. This means that there is no bypassing the profiles command’s rate limitation in this case for the Mac in question.

One way this may appear is on Macs which are part of the Automated Device Enrollment program, where the Mac can show its enrollment status by running the following command:


profiles show -type enrollment

view raw

gistfile1.txt

hosted with ❤ by GitHub

In the event that this command errors, the profiles command will block further attempts to display this information for the next 23 hours. In this situation, you may see output like that shown below:


username@computername ~ % sudo profiles show -type enrollment
Password:
Device Enrollment configuration:
(null)
username@computername ~ % sudo profiles show -type enrollment
Error fetching Device Enrollment configuration – Request too soon. Try again later.

view raw

gistfile1.txt

hosted with ❤ by GitHub

At this time, I don’t know where the information which tracks this 23 hour limitation is stored, but I did confirm that it is stored somewhere in the writable portion of the Mac’s boot drive. Wiping the Mac’s boot drive, via a disk wipe and OS reinstall or via Erase All Contents and Settings, will remove whatever is tracking and enforcing the 23 hour limitation.

Update – 4-22-2022:

It looks like the file which tracks this information is stored in the following location:

/private/var/db/ConfigurationProfiles/Settings/.profilesFetchTimerCheck

This file is protected by SIP. Thanks to zolotkey in the comments!

Also, in the original version of this post, I had made a mistake and conflated the functions of the following commands:

  • profiles renew -type enrollment
  • profiles show -type enrollment

The profiles renew -type enrollment command can be used to enroll or re-enroll a Mac which is part of the Automated Device Enrollment program with the MDM server that ADE associates the Mac with. To the best of my knowledge, the renew function of the profiles command does not have a client side rate limitation on macOS 12.3. Thanks also to Richard in the comments for catching my mistake and letting me know about it.

Categories: Mac administration, macOS

Python 2.7 removed from macOS Monterey 12.3 beta

January 27, 2022 Leave a comment

As part of the macOS Monterey 12.3 beta cycle, Apple included the following note in the publicly accessible release notes for the macOS Monterey 12.3 beta release:


Python
Deprecations
Python 2.7 was removed from macOS in this update. Developers should use Python 3 or an alternative language instead. (39795874)

view raw

gistfile1.txt

hosted with ❤ by GitHub

Screen Shot 2022 01 27 at 2 19 03 PM

 

https://developer.apple.com/documentation/macos-release-notes/macos-12_3-release-notes

This is a development which Apple has warned about for a while, beginning with macOS Catalina’s release notes:

Screen Shot 2022 01 27 at 2 36 48 PM

https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes

Apple has not included a Python 3 runtime with macOS Monterey, so the removal of Python 2.7 from macOS 12.3 and later will mean that Apple is no longer shipping a Python runtime as part of macOS.

For those who want or need to use an Apple-supplied Python distribution, Python 3 is included as part of Xcode and the Xcode Command Line Tools. Those tools are not part of macOS and will need to be installed separately.

As an alternative, a number of shops have been deploying their own Python 3 distribution. For more information on this, please see Greg Neagle’s Snakes on a Plan session from MacSysAdmin 2020:

Session slides:
http://docs.macsysadmin.se/2020/pdf/SnakesOnAPlan.pdf

Session video:
http://docs.macsysadmin.se/2020/video/Day1Session1.mp4

Categories: Mac administration, macOS

Identifying Intel Macs with Secure Enclave using Jamf Pro

January 7, 2022 Leave a comment

Identifying Intel Macs with Secure Enclave using Jamf Pro

As part of a recent task, I needed to identify using Jamf Pro which Macs in our environment have Secure Enclave and which Macs do not. For Intel Macs, having Secure Enclave means that you have one of the following Macs:

Macs with the Apple T1 Security Chip

  • MacBook Pro (13-inch with Touch Bar, Late 2016)
  • MacBook Pro (15-inch with Touch Bar, Late 2016)
  • MacBook Pro (13-inch with Touch Bar, Mid-2017)
  • MacBook Pro (15-inch with Touch Bar, Mid-2017)

Macs with the Apple T2 Security Chip

  • iMac (Retina 5K, 27-inch, 2020)
  • iMac Pro
  • Mac Pro (2019)
  • Mac Pro (Rack, 2019)
  • Mac mini (2018)
  • MacBook Air (Retina, 13-inch, 2020)
  • MacBook Air (Retina, 13-inch, 2019)
  • MacBook Air (Retina, 13-inch, 2018)
  • MacBook Pro (13-inch, 2020, Two Thunderbolt 3 ports)
  • MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports)
  • MacBook Pro (16-inch, 2019)
  • MacBook Pro (13-inch, 2019, Two Thunderbolt 3 ports)
  • MacBook Pro (15-inch, 2019)
  • MacBook Pro (13-inch, 2019, Four Thunderbolt 3 ports)
  • MacBook Pro (15-inch, 2018)
  • MacBook Pro (13-inch, 2018, Four Thunderbolt 3 ports)

Jamf Pro doesn’t have a specific “this Mac has Secure Enclave” inventory identifier, so I decided to use Apple’s documentation on which Intel Mac models have Secure Enclave to build Jamf Pro smart groups with model identifiers. With Apple’s move to Apple Silicon processors, this list of models should not be added to in the future.

For Intel Macs equipped with T1 chips, here are the relevant model identifiers:


MacBookPro13,2
MacBookPro13,3
MacBookPro14,2
MacBookPro14,3

view raw

gistfile1.txt

hosted with ❤ by GitHub

For Intel Macs equipped with T2 chips, here are the relevant model identifiers:


iMac20,1
iMacPro1,1
MacPro7,1
Macmini8,1
MacBookAir8,1
MacBookAir8,2
MacBookAir9,1
MacBookPro15,1
MacBookPro15,2
MacBookPro15,3
MacBookPro15,4
MacBookPro16,1
MacBookPro16,2
MacBookPro16,3
MacBookPro16,4

view raw

gistfile1.txt

hosted with ❤ by GitHub

For more details, please see below the jump.

Read more…

Preventing user and location inventory information from being changed by the jamf binary’s recon verb

December 27, 2021 Leave a comment

You can allow or prevent local administrators on the computer from changing User and Location inventory information in Jamf Pro with the jamf binary by using the Allow local administrators to use the jamf binary recon verb to change User and Location inventory information in Jamf Pro checkbox. This is a feature which first appeared in Jamf Pro 10.20.x, but may not be well known.

Screen Shot 2020 03 17 at 10 54 47 AM

This setting is enabled by default and can be configured by navigating to Settings > Computer Management > Inventory Collection in Jamf Pro.

Screen Shot 2021 12 27 at 11 42 08 AM

Screen Shot 2021 12 27 at 11 43 13 AM

What this setting affects are the following options associated with the jamf binary’s recon verb:


-endUsername
-realname
-email
-position
-building
-department
-phone
-room

view raw

gistfile1.txt

hosted with ❤ by GitHub

Screen Shot 2021 12 27 at 12 10 53 PM

Why disable this setting? If you have workflows which leverage the user and location information stored in Jamf Pro, being able to change this setting from a managed Mac using the jamf binary’s recon verb may have security implications. In particular, PKI certificate authorities set up in Jamf Pro may use the user and location information stored in Jamf Pro to issue certificates to managed Macs.

Screen Shot 2021 12 27 at 11 39 03 AM

In the context of certificates used for authentication, being able to change the user and location stored in Jamf Pro from the managed Mac’s end may mean that an enduser with the ability to run the jamf binary’s recon verb may be able to get authentication certificates for someone other than themselves assigned to their Mac.

Screen Shot 2021 12 27 at 12 12 47 PM

If you do not have any workflows that use the recon verb’s options specified above, my advice is that you disable this setting and remove the ability of managed Macs to change the user and location information stored in Jamf Pro using the jamf binary’s recon verb.

Screen Shot 2021 12 27 at 12 02 48 PM

Disabling Recent Tags in the Finder window sidebar

November 29, 2021 Leave a comment

Every so often, something gets added to macOS and enabled by default where I wish it was off by default. The Tags section of the Finder’s sidebar is one of those additions.

Screen Shot 2021 11 29 at 10 04 13 AM

Fortunately for my preferences, I recently figured out (thanks to Bob Gendler’s method for discovering settings via the unified logs) that display of the Tags section was controlled via the following setting:

Domain: com.apple.finder
Key: ShowRecentTags
Value: Boolean

To show Recent Tags in the Finder’s sidebar, run the following command as the logged-in user:

defaults write com.apple.Finder ShowRecentTags -bool true

Screen Shot 2021 11 29 at 10 41 26 AM

Here’s how the Recent Tags setting should now appear in the Finder preferences:

Screen Shot 2021 11 29 at 10 03 48 AM

 

To remove Recent Tags from the Finder’s sidebar, run the following command as the logged-in user:

defaults write com.apple.Finder ShowRecentTags -bool false

Screen Shot 2021 11 29 at 10 40 53 AM

 

Here’s how the Recent Tags setting should now appear in the Finder preferences:

Screen Shot 2021 11 29 at 10 06 54 AM

 

The new setting will not apply until the Finder is restarted, which can be accomplished via either logging out and logging back in or running the following command as the logged-in user:

killall Finder

Screen Shot 2021 11 29 at 10 06 16 AM

 

After the Finder restart, the Tags section should no longer appear in the Finder window sidebar:

Screen Shot 2021 11 29 at 10 06 24 AM

 

In my case, I wanted them off permanently 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/DisableRecentTagsinFinderSidebar

Categories: Mac administration, macOS

Running Jamf Pro actions from outside Jamf Pro

November 1, 2021 2 comments

Every so often, I need to have Jamf Pro perform actions where it’s difficult to arrange the timing and task order I want using the options available from the Jamf Pro server’s end. An example of this would be following an OS upgrade. I want the following:

  • Update the computer inventory record in Jamf Pro as soon as possible that the OS upgrade has occurred.
  • Don’t interfere with any other processes that Jamf Pro may be running at that time.

To address this, I want to use the following workflow:

  1. Make sure the Jamf Pro agent hasn’t run anything for at least the last five minutes.
  2. Enforce the Jamf Pro agent’s management framework
  3. Send the Jamf Pro server an updated inventory.

To run these tasks, I’m using a self-destructing LaunchDaemon and script. For more details, please see below the jump.

Read more…

%d bloggers like this: