As part of the release of Casper 9.93, JAMF has added options for suppressing the iCloud and Diagnostics pop-up windows to the following MDM profile payloads:
- Login Window
- Security & Privacy
The iCloud pop-up window can be managed via the Login Window profile payload. To suppress the iCloud pop-up window, click on the Options tab for that payload and check the Disable Apple ID setup during login option.
The Diagnostics pop-up window can be managed via the Security & Privacy profile payload. To suppress the Diagnostics pop-up window, click on the Privacy tab for that payload and uncheck the Allow sending diagnostic and usage data to Apple, and sharing crash data and statistics with app developers option.
As part of the process of deploying Macs, Mac admins may want to add one or more local user accounts with a pre-determined password. The reasons for this may include the following:
- Setting up a local administrator account.
- Setting up a “loaner” user account for a pool of loaner laptops.
- Setting up a local user account that automatically logs in at startup for a Mac used as a kiosk.
- Setting up a generic “student” account for use in a school’s computer lab.
These accounts can be set up using a script, but that usually means having the password for the local account stored in the script in a way that anyone with access to the script can easily read the password. An alternative to this approach is to use CreateUserPkg.app, a open source utility written by Per Olofsson. CreateUserPkg.app generates installer packages which can be used on Mac OS X 10.5.x and later to create local user accounts and securely set the associated account’s password. For more information, see below the jump.
As part of a discussion of security issues with some colleagues this morning, the question of how to disable Bonjour advertisement came up on OS X El Capitan and later came up. Bonjour advertisement is how your Mac sends out an “I’m here and this is a list of the services I have available” message via Bonjour. In certain environments, this is undesired behavior and the advertisement service needs to be disabled.
The reason why the question came up is that, on OS X Yosemite and earlier, the process of disabling Bonjour advertisement looked like this:
1. Run the following command with root privileges to unload the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:
launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
2. Run the following command with root privileges to edit the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:
defaults write /System/Library/LaunchDaemons/com.apple.mDNSResponder ProgramArguments -array-add &quot;-NoMulticastAdvertisements&quot;
3. Run the following command with root privileges to load the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:
launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
As of OS X 10.11.x though, System Integrity Protection blocks the editing of the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file because of the file’s location inside of the SIP-protected /System directory.
To accommodate this change, Apple made a change to mDNSResponder on OS X El Capitan and later to allow it to pick up settings from the following file:
The ability to disable Bonjour advertisement is among the settings which can be applied to the new /Library/Preferences/com.apple.mDNSResponder.plist file. To disable Bonjour advertisement in OS X El Capitan and later, use the following procedure:
1. Run the following command with root privileges:
defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool YES
2. Restart the Mac
3. Once the Mac has restarted, Bonjour advertisement should be disabled.
For those who want to disable Bonjour advertisement using a management profile, I’ve created a .mobileconfig file and posted it here on Github:
Update – 8-22-2016: My colleague Steve Yuroff tested the profile independently and let me know that this may not be manageable via a profile after all. I re-tested and was able to reproduce his results. We have both verified that running the defaults command listed above does produce the expected behavior.
I’ve filed a bug report about this. For those interested in duping this bug, the bug report ID is 27952362. I’ve also cross-posted it to OpenRadar:
As part of the process of upgrading my Casper server, I generally create a new installer for the Casper agent in the form of a QuickAdd installer package. This process usually looks like this:
1. Update the Casper Suite applications on the Mac where I’m generating the new QuickAdd installer package.
2. Open Casper Recon.
3. Sign into Casper Recon.
4. Select QuickAdd Package from the Recon sidebar.
5. Set up the desired options for the QuickAdd installer package.
6. Click the Create button.
7. Choose a name for the new QuickAdd installer package.
8. Wait for Recon to create the QuickAdd installer package.
9. Take the newly-created QuickAdd package and use it to replace the existing QuickAdd packages used by CasperCheck and my deployment workflows.
The reason I use this process is that Casper’s Recon application is able to generate a QuickAdd installer package with an unlimited enrollment invitation. With an unlimited enrollment invitation, I can use the same QuickAdd installer package multiple times to enroll multiple machines. This is in contrast the user-based enrollment process via the JSS, which by default generates a QuickAdd installer package with a one-time-use enrollment invitation.
I have this Recon-based process documented, but it’s always been something I’ve wanted to automate at least somewhat. Recently, as part of a discussion with my colleague Tom Larkin, I learned that a Casper JSS server which is configured to send out emails is capable of generating enrollment invitation emails, which include a link to download a JSS-generated QuickAdd. That invitation can be set to link to a QuickAdd with an unlimited enrollment invitation and an expiration date many years in the future, which effectively gives me the ability to generate the QuickAdd installer packages I want without the need to use Casper’s Recon application. For more details, see below the jump.
As a follow up to yesterday’s post about setting up smart groups which automatically include a specified operating system and later, my colleague Erik Gomez sent me a heads-up about a new feature in Casper 9.93:
As part of Casper 9.93, JAMF has included new smart group operators as part of supporting its new patch reporting feature. The Operating System Version is one criteria which was updated and it now has the following operators available:
- Is Not
- Not Like
- Greater Than
- Less Than
- Greater Than or Equal
- Less Than or Equal
The new Greater Than and Less Than operators can completely replace the technique I’ve been using, as they make it straightforward to specify an operating system version number and then set the appropriate operator to automatically include all Macs whose OS version numbers are greater or less than the specified version number. For more details, see below the jump.
As part of setting up Casper policies, you need to set which Macs will be receiving these policies by setting the scope. The scope defines which Macs or users will be receiving these policies.
When preparing to set the scope for a policy, I will often build and use smart groups. These are a special kind of group, where the members are defined based on one or more attributes (like the Mac’s operating system version, IP address, Mac model, etc.) and therefore the group’s membership is dynamically growing and shrinking based on the numbers of Macs with the specified attributes.
Once the smart group has been set up with the desired attributes, I then set the smart group and its membership to be specified as the scope’s Target Computers.
For many software deployment policies, the software in question often has system requirements that cover a range of operating systems instead of just one version of Apple’s OS. For example, Google Chrome 52.0.2743.116 has the following system requirements:
OS X Mavericks 10.9 or later
Update 8-5-2016: Casper 9.93 and later includes new smart group functionality which can entirely replace the technique described in this post. For more details, please see the post linked below:
To deploy Chrome via Casper, the smart group should be set up with attributes that include Macs running 10.9.x. and later. To accomplish this, I had previously set up a smart group that looked like this:
Note: The trailing period after the last number is used by Casper to include all relevant matches. So “10.10.” will also pull in Macs running the following versions of OS X:
However, I was finding that I later needed to go back on an annual basis to those smart groups and add new entries. For macOS Sierra, the smart group would need to be edited to look like this:
An discussion with my colleague Jeremy Reichman provided me with a solution to this issue. I had been setting up my smart groups to include those machines which has the OSs I wanted by setting the smart group attributes to say “I want these OS versions.”
A better answer is to say “I don’t want these OS versions,” and then specify the OS versions that are NOT wanted in your smart group. The result is that your smart group is then populated with whatever is left after excluding the unwanted versions. For example, to get all Macs running 10.9.x or later, you can set up a smart group that looks like this:
Note: It’s unlikely to have 10.1.x through 10.4.x in a modern Mac environment but they’ve been included for completeness’ sake.
The resulting smart group membership should include all the machines that aren’t running the specified OS versions, which may include Macs running 10.9.0 through 10.999.999.
This makes the job of scoping a Chrome software deployment policy easier because the smart group membership will now automatically match the specifications of Google Chrome’s system requirements of OS X 10.9 or later.
One of my customers reported an unusual problem today with their keyboard, mouse and trackpad. When they tried to to use Apple’s Mail or Messages applications on OS X El Capitan, both Mail and Messages were unresponsive to either keyboard, trackpad or mouse input.
However, when they selected another non-Apple application like Firefox or Google Chrome, their keyboard, trackpad and mouse behaved normally. Other Apple-installed applications like Safari were also responsive to keyboard, trackpad and mouse input.
When I checked the logs, the main clue I could find was that when I clicked on Mail or Messages, I would see an entry like this appear in /var/log/system.log:
09:02:06.100 sandboxd: () Mail (458) deny hid-control
hid in this instance refers to something which Apple classifies as a Human Interface Device, which include the following devices:
- Keyboards and pointing devices such as mice, trackballs, and joysticks
- Front-panel controls such as knobs, switches, sliders, and buttons (for example, controls on non-Apple displays)
- Controls that might be found on games or simulation devices such as data gloves, throttles, and steering wheels
So for some reason the sandboxd process was denying access to Messages and Mail for the mouse, keyboard and trackpad. Why? For more details, please see below the jump.