Adding password protection to manually installed management profiles

August 24, 2017 Leave a comment

While working with some colleagues, I recently built a management profile that my one colleague requested to be set as non-removable. Normally, this can be accomplished by setting the PayloadRemovalDisallowed key in the profile to a boolean value of true.

Screen Shot 2017 08 24 at 3 32 10 PM

I provided the profile to my colleague and he tested it out. However, in the course of testing, he discovered that the profile could be removed by a user with administrative rights using the following procedure:

1. Open System Preferences
2. Select the profile in question.
3. Click the minus button.

Screen Shot 2017 08 24 at 3 26 17 PM

4. Be warned about removing a locked profile.

Screen Shot 2017 08 24 at 3 29 52 PM

5. Enter admin credentials when prompted.

Screen Shot 2017 08 24 at 3 27 17 PM

After entering admin credentials, the profile was then removed.

When I checked Apple’s reference documentation on configuration profiles, the issue came down to how the profile was being delivered. Apple’s documentation includes the following note about the PayloadRemovalDisallowed key:

Screen Shot 2017 08 24 at 2 44 26 PM

This profile was being installed by an installer package, so from Apple’s point of view it was being installed manually. That meant that the manual installation behavior, where the profile could be removed by anyone with admin rights, was the applicable behavior here.

Another colleague working with us on this issue suggested adding a removal password to the profile, using Apple’s profile payload.

Screen Shot 2017 08 24 at 3 01 15 PM

A removal password for a profile is designed to allow the removal of a management profile, even if that profile is otherwise set to be non-removable. For more details, see below the jump:

Read more…

Kernel extensions and macOS High Sierra

August 24, 2017 6 comments

As part of the pre-release announcements about macOS High Sierra, Apple released the following KBase article:

As part of the KBase article, Apple included a Changes coming with macOS High Sierra section which featured this note:

macOS High Sierra introduces a new feature that requires user approval before loading new third-party kernel extensions. This feature will require changes to some apps and installers in order to preserve the desired user experience.

Screen Shot 2017 08 23 at 9 33 49 PM

That section in turn links to this KBase article, which describes the behavior in more detail:

To improve security on the Mac, kernel extensions installed with or after the installation of macOS High Sierra require user consent in order to load. This is known as User Approved Kernel Extension Loading. Any user can approve a kernel extension, even if they don’t have administrator privileges.

Screen Shot 2017 08 23 at 10 23 34 PM

What’s all this mean? For more details, see below the jump.

Read more…

Categories: Mac administration, macOS

Setting a macOS VM to automatically boot to Recovery HD using VMware Fusion

August 1, 2017 3 comments

When testing various security functions, like System Integrity Protection or High Sierra’s new kernel extension functionality, it’s often useful to be able to boot a macOS virtual machine (VM) into the Recovery environment. However, it can be challenging to select the VM and hold down Command+R in time to boot to the Recovery environment. This can result in having to try several or more times before you can successfully boot the VM to Recovery HD.

Fortunately, VMware has a setting that enables a forced boot to Recovery HD. For more details, please see below the jump.

Read more…

Identifying the Jamf Pro server set in CasperCheck using an Extension Attribute

July 30, 2017 Leave a comment

As part of my Jamf Pro testing process, I will often set up a VM using a production setup workflow then enroll that newly-setup VM into my test Jamf Pro server. However, as part of my production workflow setup, I will usually install my CasperCheck self-repair solution in order to make sure the machine stays enrolled with my Jamf Pro server.

Unfortunately, this can lead to the following chain of events:

  1. Test VM is enrolled in the test Jamf Pro server
  2. CasperCheck runs on its pre-set schedule and detects that it is not enrolled with the Jamf Pro server specified in the script.
  3. CasperCheck runs its repair functions and enrolls the test VM in the production server.
  4. I wonder why my test VM isn’t talking to the test Jamf Pro server.
  5. I check the CasperCheck log, grumble when I notice that CasperCheck has done its job, and then install the test server’s CasperCheck script on the test VM.
  6. Reboot the test VM to trigger the test server’s CasperCheck script to enroll the test VM into the test server again.

This situation happened infrequently enough in the past that I usually just dealt with it on an individual basis, but I finally decided to fix it by writing a Jamf Pro Extension Attribute to help me identify which Jamf Pro server was specified in the installed copy of CasperCheck . For more details, see below the jump.

Read more…

Session videos now available from Penn State MacAdmins Conference 2017

July 27, 2017 Leave a comment

The good folks at Penn State have begun posting the session videos from the Penn State MacAdmins Conference 2017. The sessions slides and currently-available videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:

As all the session videos have been posted to YouTube, I’ve linked my Storing our Digital Lives: Mac filesystems from MFS to APFS session here:

Deploying a pre-configured F5 Big-IP VPN client

July 27, 2017 Leave a comment

As part of a discussion with a colleague, he said that he needed to build an installer for his shop’s F5 Network’s VPN service but wasn’t sure how. I hadn’t built one of these previously either, so I decided to look into it.

Fortunately, F5 Networks has made the process of creating one a fairly straightforward process, assuming that your VPN administrator can provide the needed config_tmp.f5c configuration file. Assuming that you can get that file, all that’s needed is making sure that the config_tmp.f5c file is located in the same directory as the VPN client installer.

Screen Shot 2017 07 26 at 8 27 48 PM

The reason for this is that the postinstall scripts of the F5 VPN client installer are set to look for that file in that location, and will automatically import the configuration file’s contents if the file is found.

Screen Shot 2017 07 26 at 8 16 13 PM

Once I had both the config_tmp.f5c config file and a copy of the F5 VPN client installer, I was able to create an installer using this method that handled both the installation and the automated configuration of the F5 VPN client. For more details, see below the jump.

Read more…

Generating printer configurations using

July 18, 2017 1 comment

As part of a recent discussion, a colleague posted in the MacAdmins Slack that they needed to deploy printers as part of a DeployStudio workflow. DeployStudio doesn’t natively include this functionality, so that meant developing a way to deploy the desired printers to the appropriate Macs via one of the following methods:

As part of the conversation, I pointed to Nick McSpadden‘s PrinterGenerator tool:

Nick’s tool is designed to create printer configurations for deployment via Munki. However, my colleague wasn’t using Munki in this case and didn’t plan to deploy it. So even though there was a tool that could have solved the problem, adapting it to work for my DeployStudio-using colleague’s needs was going to take some time and effort.

The discussion got me started thinking about the problem of printer deployments and ways to solve it that could work for the vast majority of deployment solutions. After some research and testing, I’ve developed a solution that may work for most deployment needs. For more details, see below the jump.

Read more…

%d bloggers like this: