Accessing Sharepoint sites using Microsoft Office 2016

As part of rolling out Office 2016 for my shop, I noticed that Office 2011’s Microsoft Document Connection application was no longer included with Office. A number of folks in my shop had been using this application to access documents on our Sharepoint servers, so its absence meant I needed to learn how to access Sharepoint sites using Office 2016.

After some research and discussion with colleagues, I was able to figure out how to connect to Sharepoint from within Office 2016 applications. For more details, see below the jump.

Migrating OS X Macs from one Apple push notification certificate to another using Casper

As mentioned previously, I needed to migrate my Casper server from using the Apple Push Notification Service (APNS) certificate generated by one Apple ID to now using another APNS certificate generated by another Apple ID.

This project is fairly straightforward, thanks to a couple of factors:

1. The Casper server in question is managing only OS X devices.
2. I have a way to identify via a Casper Extension Attribute which Macs have MDM profiles associated with the APNS certificate which is no longer active.

I was able to set up a Casper smart group to look for machines that fit the following criteria:

• Criteria: Extension Attribute name (In this case, the EA is named Apple Push Notification Service certificate identifier.)
• Operator: Like
• Value: com.apple.mgmt.External.uuid_of_former_apns_certificate_goes_here

From there, I set up a policy that is scoped to run on the members of that smart group. For more details, see below the jump.

Checking the Apple Push Notification Service certificate identifier used by MDM profiles

A few years ago, I set up my Casper server with an Apple Push Notification Service (APNS) certificate. That by itself is not remarkable, but the way I did it would be frowned upon these days. That’s because I used an Apple ID tied to my work email address to generate it.

The reason that I did this was that back then, you needed to have a paid membership in the Apple iOS Developer Program in order to get an APNS certificate. I was not part of an enterprise team, so the Apple ID I was using to log into my ADC account was tied to my own work email address. Consequently, I generated my initial APNS certificate for my Casper server using an Apple ID tied to my work email address.

Fast forward to 2016 and the world of the Apple Push Certificates Portal, where it’s no longer necessary to have an Apple Developer Connection account to have an APNS certificate. In fact, it’s not a great idea at all because people come and go, but hopefully the Apple ID used to generate your APNS certificate (also known as an MDM certificate or push notification certificate) does not. That’s because you can’t transfer an Apple ID to another email address and only the Apple ID used to generate your initial APNS certificate can generate the new certificate needed for the annual APNS certificate renewal.

For iOS devices, where everything is managed via MDM, changing the Apple ID used to generate your APNS certificate means that you are going to have to re-enroll all of your devices. This is usually a sizable effort and one that should be avoided if at all possible.

For OS X devices, where MDM-only management is still fairly rare, changing Apple IDs (and APNS certificates) is less problematic. You will also need to re-enroll your devices but it should be possible to use alternate means to remove your old MDM profile(s) and make the Mac pull down a new set of MDM management profiles that would incorporate the new APNS certificate for the Mac’s push notifications.

Fortunately, I’m in the situation of having to change out my Apple ID and APNS certificate only on OS X devices. These devices are also managed by my Casper server, so I can automate a fix for the issue using a script like the one below:

	#!/bin/bash
	# This script fixes the MDM computer-level profile for Casper
	CheckBinary (){
	# Identify location of jamf binary.
	jamf_binary=`/usr/bin/which jamf`
	if [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ ! -e "/usr/local/bin/jamf" ]]; then
	jamf_binary="/usr/sbin/jamf"
	elif [[ "$jamf_binary" == "" ]] && [[ ! -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
	jamf_binary="/usr/local/bin/jamf"
	elif [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
	jamf_binary="/usr/local/bin/jamf"
	fi
	}
	# Run the CheckBinary function to identify the location
	# of the jamf binary for the jamf_binary variable.
	CheckBinary
	# Remove the existing Casper MDM profile
	$jamf_binary removeMdmProfile -verbose
	# Request a new MDM profile from the Casper server
	$jamf_binary mdm -verbose

view raw

gistfile1.txt

hosted with ❤ by GitHub

However, I still had one issue – identifying which machines had the “old” MDM profiles associated with the APNS certificate which I was trying to move away from. For details on how this was addressed, see below the jump.

FileVault 2 on El Capitan is now FIPS 140-2 Compliant

Apple officially announced on Wednesday, April 6th that the FIPS 140-2 validations for the cryptographic modules used by iOS 9 and OS X 10.11.x have now been completed. This is significant news for folks who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)

For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.

As part of the announcement, Apple has released KBase articles and guidance for security offices who deal with encryption:

Apple FIPS Cryptographic Modules v6.0 for OS X El Capitan v10.11 – https://support.apple.com/HT205748

Crypto Officer Role Guide for FIPS 140-2 Compliance OS X El Capitan v10.11 – https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT205748/APPLEFIPS_GUIDE_CO_OSX10.11.pdf

According to Apple, the OS X El Capitan Cryptographic Modules, Apple OS X CoreCrypto Module v6.0 and Apple OS X CoreCrypto Kernel Module v6.0, require no setup or configuration to be in “FIPS Mode” for FIPS 140-2 compliance on devices running OS X El Capitan 10.11.x.

FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X El Capitan v10.11 documentation, in the Compliant Applications and Services section.

 

For more information about the validation certification, please see below the jump.

iCloud password option for local users removed in OS X 10.11.4’s Users & Groups preference pane

Starting in OS X Yosemite, Apple introduced a new option to log into your Mac using the password associated with an Apple ID. As of OS X 10.11.4, this option seems to have been removed from the Users & Groups preference pane in System Preferences.

OS X 10.11.3:

 

OS X 10.11.4:

Apple’s KBase article describing how to set up users on OS X El Capitan was last updated on April 13, 2016. It does not include any information on using an iCloud password for a new user account.

This option still appears to be available on OS X 10.11.4 via Apple’s Setup Assistant. If you’re setting up a Mac for the first time and sign into iCloud as part of the setup process, you will be given the option of using your iCloud account to log in.

 

Performance tuning for the Casper JSS

One of the challenges Casper admins can run into is performance tuning, which can require going into parts of the JSS that you normally go into only when JAMF Support asks you to do so. To help with this process, there are formulas which you can use to calculate if your JSS’s Tomcat and MySQL services are configured for best performance.

Before proceeding further, I want to emphasize that a) check with JAMF Support first and b) you should always, always, always make backups of your JSS before changing settings. I assume no responsibility and bear no culpability if your JSS breaks as a result of anything you implement as a result of reading this post. I am also not responsible for incorrect math, ruining anyone’s weekend, or that long talk you now need to have with your boss about why your JSS is now broken.

One other thing to be aware of is that I’m going to be focusing on Linux and Windows in this post since those are the platforms that I’m most familiar with for hosting a Casper 9 JSS.

For more details, see below the jump:

Displaying documentation of all options available with the Casper agent

I recently learned that there’s a way to display all the various verbs which can be used with the Casper agent’s jamf binary in one list, including the verbs which are normally hidden from view. For more details, see below the jump.

Identifying FileVault 2 institutional recovery keys on OS X El Capitan

On OS X 10.9.0 – 10.11.x, you can run the following command to verify if a FileVault 2-encrypted Mac is using an institutional recovery key (IRK) as a valid recovery key.

fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an IRK, this command will return true.

Otherwise it will return false.

As part of the release of OS X 10.11.2, a new function was added to fdesetup‘s hasinstitutionalrecoverykey verb. Now, in addition to identifying whether or not FileVault 2 on a particular Mac has an institutional recovery key, a new -device option has been added which outputs a SHA-1 hash in hexadecimal notation of the IRK’s public key. This helps Mac admins answer two questions about institutional recovery keys:

1. Is an IRK being used as a valid recovery key on this Mac?
2. If an IRK is in use, which one is being used?

The -device option needs to be supplied with an identifier for the encrypted drive in question. This can be in the form of a BSD device name ( /dev/diskX ), the mount path ( /Volumes/Macintosh HD or / ), or a UUID for the Logical Volume or Logical Volume Family of a CoreStorage volume.

To display the hash for an IRK’s public key on the Mac’s boot volume, run the command below with root privileges:

fdesetup hasinstitutionalrecoverykey -device /

It should output the hash of the IRK’s public key in hexadecimal notation.

This value should be consistent across all FileVault 2-encrypted Macs which are using this IRK, so it should help Mac admins identify if a particular Mac is set up with the correct FileVault 2 institutional recovery key (or keys) used by their shop.

To assist with this, I’ve written a script to report the hash of the IRK’s public key. For more details, see below the jump.

DeployStudio 1.7.3 updated from build 160401 to build 160404 to address Active Directory binding issue

Following the release of DeployStudio 1.7.3, I discovered and reported a problem with the Active Directory binding to the DeployStudio folks.

@deploystudio I’ve found a problem with the new AD profile-based binding in DS 1.7.3: https://t.co/PUJq8LF2CI

— Rich Trouton (@rtrouton) April 1, 2016

To address the issue, they released a new version of DeployStudio but didn’t change the version number from 1.7.3. Instead, the new DeployStudio 1.7.3 has a different build number:

• DeployStudio 1.7.3 build 160401 – released April 1st, 2016
• DeployStudio 1.7.3 build 160404 – released April 4th, 2016

If you have already installed DeployStudio 1.7.3, I recommend checking to see which build you have installed. If needed, upgrade both your DeployStudio server and DeployStudio boot sets to DeployStudio 1.7.3 build 160404.

For more details on identifying the different builds of DeployStudio 1.7.3, see below the jump.

DeployStudio 1.7.3 using configuration profiles for Active Directory binding on OS X El Capitan

As part of the release of DeployStudio 1.7.3, DeployStudio is now using an unsigned configuration profile to manage binding to an Active Directory domain for Macs running OS X 10.11.x.

DeployStudio 1.7.3 AD binding on 10.11 uses a Configuration Profile behind the scenes:https://t.co/UfHWaS23AA#MacAdmin

— Tim Sutton (@tvsutton) April 1, 2016

This undocumented change currently appears to apply only to Macs running OS X El Capitan. Earlier versions of OS X are still being bound to AD using Apple’s dsconfigad tool. For more details, see below the jump.