Session videos from Jamf Nation User Conference 2022 now available

Jamf has posted the session videos for Jamf Nation User Conference 2022, including the video for my Running Jamf Pro at Scale, from SAP with ❤️ session.

For those interested, all of the the JNUC 2022 session videos are available on YouTube. For convenience, I’ve linked my session here.

Apple making changes to maximum lifetime limits for SSL certificates as of September 2020

All SSL certificates have a set amount of time which they’re good for, which means that at some point they expire. As an example, the SSL certificate currently used by www.apple.com has the following expiration date and time:

Friday, October 23, 2020 at 8:00:00 AM Eastern Daylight Time

As of today, March 5th 2020, the maximum lifetime for publicly trusted SSL certificates is 825 days, or roughly 27 months.

Apple has announced that, starting on September 1, 2020 at 00:00 GMT/UTC, all new SSL certificates being issued by specific Root Certificate Authorities (Root CAs) must not have a maximum lifetime longer than 398 days, or roughly 13 months, in order to be accepted as a valid certificate on Apple’s iOS, iPadOS, macOS, watchOS, and tvOS operating systems.

What certificates are affected?

This does not affect all SSL certificates. It will affect certificates issued on or after the September 1, 2020 start date by the Root CAs which are preinstalled with Apple’s iOS, iPadOS, macOS, watchOS, and tvOS operating systems.

Since these CAs are installed along with the OS, the certificates issued by these Root CAs are trusted by Apple’s OSs without any additional work needed by the end user. These Root CAs include commercial SSL vendors like Go Daddy, DigiCert and other companies.

What certificates are not affected?

Certificates issued by the specified preinstalled Root CAs before the September 1, 2020 start date are not affected. If they have a lifespan longer than 398 days, Apple will continue to accept them as valid until their set expiration date as long as they were issued prior to September 1, 2020 at 00:00 GMT/UTC.

Certificates issued by Root CAs which do not come with the operating system are also not affected. So if your company, school or institution has their own Root CAs , SSL certificates issued by those CAs are not affected by the new maximum lifetime restriction. Those CAs can continue to issue SSL certificates with lifetimes longer than 398 days.

Note: These Root CAs are not trusted by default by Apple’s operating systems. Instead, the Root CA’s root certificate would need to be installed and set as a trusted root by either the user or a system administrator.

Does this affect anyone other than Apple?

As of now, this is a unilateral move by Apple which hasn’t been adopted by other vendors. That said, Google had proposed something similar in September 2019 so it would not be surprising to see Google also adopt this at some point.

Will this affect only web browsers?

SSL certificates are used by a variety of applications and tools to help provide secure communication, so the effects of this change will not be restricted to web browsers like Safari. Non-compliant certificates may result in network services or applications failing to work properly.

Session videos from Jamf Nation User Conference 2019 now available

Jamf has posted the session videos for from Jamf Nation User Conference 2019, including the video for my “MDM: From Nice-To-Have to Necessity” session.

For those interested, all of the the JNUC 2019 session videos are available on YouTube. For convenience, I’ve linked my session here.

Slides from the “MDM: From “Nice to Have” To Necessity” session at Jamf Nation User Conference 2019

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

• PDF – https://tinyurl.com/JNUC2019PDF
• Keynote – https://tinyurl.com/JNUC2019Keynote

For those folks at the talk who were interested in Privileges and ProfileCreator, please see the links below:

• Privileges: https://github.com/SAP/macOS-enterprise-privileges
• ProfileCreator: https://github.com/ProfileCreator/ProfileCreator

New TLS security requirements for iOS 13 and macOS Catalina 10.15

As part of the information published at WWDC 2019 by Apple, the following KBase article has been released:

Requirements for trusted certificates in iOS 13 and macOS 10.15: https://support.apple.com/HT210176

This KBase article describes how Apple is implementing new security requirements for TLS server certificates. These certificates are used by servers to encrypt communication between Apple devices and those servers, to make sure that all communication between the servers and those devices is protected.

• Certificate key sizes must be 2048-bit or greater
• SHA-2 must be used for the certificate signing
• DNS hostname of the server must be listed in a Subject Alternative Name (SAN) certificate extension in addition to being listed in the Common Name field of the certificate.

Also, all TLS certificates issued after July 1, 2019 must meet these additional requirements:

• Must be valid for 825 days (27 months) or less
• Must contain the following Object Identifier in the ExtendedKeyUsage extension: id-kp-serverAuth

What happens if you use iOS 13 or macOS Catalina to try to connect to servers with TLS certificates which don’t meet these standards? The connection will fail because the OS will reject the certificate as being invalid. This may result in a web browser not connecting, an app crashing or some other undesired behavior.

As part of testing iOS 13 and macOS 10.15 ahead of their release dates, I strongly recommend testing the various services used at your workplace to make sure that the TLS certificates used by the services of your company, school or institution are able to pass these requirements. Otherwise, you may find some unfortunate surprises on Release Day this fall.

Backing up extension attributes from Jamf Pro

While working with extension attributes on Jamf Pro, I prefer to download then and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:

1. I have an off-server backup for the extension attributes
2. I can track changes to the extension attributes

To help me manage this, I have two scripts which do the following:

1. Use the Jamf Pro API to identify the Jamf Pro ID numbers of the extension attributes.
2. Download each extension attribute as an XML file using its Jamf Pro ID number.
3. Format the downloaded XML.
4. Identify the display name of the extension attribute.
5. Identify if it was a String, Integer or Date extension attribute.
6. If it’s a macOS or Windows extension attribute and it has a script, extract the script.
7. Save the downloaded XML or script as Extension Attribute Name Here to a specified download directory, based on whether it was a String, Integer or Date extension attribute.

For more details, please see below the jump.

Backing up smart and static groups from Jamf Pro

When working with smart and static groups on Jamf Pro, especially more complex smart groups, I prefer to download then and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:

1. I have an off-server backup for the groups
2. I can track changes to the groups
3. If needed, I can make a change to a smart group and upload via the API instead of having to edit in the web console.

Up until recently, I didn’t have a good process for handling this but I was able to develop a way as part of working with an engineer from Jamf. After some work, I was able to build two scripts which do the following:

1. Use the Jamf Pro API to identify the Jamf Pro ID numbers of the smart and static groups.
2. Download each group as an XML file using its Jamf Pro ID number.
3. Format the downloaded XML.
4. Identify the display name of the group.
5. Identify if it was a smart or static group.
6. Save the downloaded XML as Group Name Here.xml to a specified download directory, based on whether it was a smart or static group.

For more details, please see below the jump.

Backing up configuration profiles from Jamf Pro

When working with configuration profiles on Jamf Pro, I prefer to download and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:

1. I have an off-server backup for the profiles
2. I can track changes to the profiles

Up until recently, this had been a manual process for me where I would download the profiles in question from the server and then upload them to my source control tool.

My process looked like this:

1. Download the profiles from the Jamf Pro server using the Download button.

2. Remove the code-signing and formatting the profile using a process similar to the one described in the link below:

https://macmule.com/2015/11/16/making-downloaded-jss-configuration-profiles-readable/

3. Move the profile to the correct directory in my source control repo.
4. Review changes and commit to the repo.

However, as I’ve started using profiles more, this process got cumbersome and I wanted to automate at least the download part of the process. After some work, I was able to build two scripts which do the following:

1. Use the Jamf Pro API to identify the Jamf Pro ID numbers of the configuration profiles.
2. Download each profile using its Jamf Pro ID number
3. Decode and format the profile
4. Identify the display name of the profile
5. Save the profile as Display Name Here.mobileconfig to a specified download directory.

For more details, please see below the jump.

T2, FileVault and brute force attack protection

Apple recently released an overview document for its new T2 chip, which includes how the new T2 chip-equipped Macs have new protections against brute force attacks. This protection only applies if FileVault is enabled and is similar in concept to how iOS devices set with passcodes are protected against brute force attacks.

On iOS, if an incorrect passcode is entered more than five times, a one minute delay is set.

After the sixth try, the delay is now five minutes and the delays get longer from there until the device has the 10th wrong passcode entered and the device wipes.

On Apple iOS devices with a Secure Enclave, those delays are enforced by the Secure Enclave processor. Similarly, the T2 chip-equipped Macs also have a Secure Enclave processor which is managing access attempts and introducing delays.

For Macs with Secure Enclave, the enforcement looks like this:

• 30 unlock attempts via using the password at the login window or target disk mode
• 10 unlock attempts via using the password in Recovery Mode
• 30 unlock attempts for each enabled FileVault recovery mechanism
• iCloud recovery
• FileVault personal recovery key
• FileVault institutional recovery key

The maximum number of unlock attempts is 90, regardless of the mix of methods used. After 90 attempts, the Secure Enclave processor will no longer process any requests to do the following:

• Unlock the volume
• Decrypt the volume
• Verify the password / recovery key

Delays are also imposed on macOS between attempts.

So what happens after 90 attempts? Does the Mac lock forever and become a paperweight?

After checking with AppleCare Enterprise, the answer is that the Mac will not be a paperweight, but that the Mac’s boot drive will need to be erased before it can be used again. This approach helps make sure that the Mac is still usable, but also ensures that the encrypted data stored on the boot drive is no longer recoverable.

For more information about brute force protection for encrypted iOS and macOS devices, I recommend checking out Apple’s currently available white papers:

• iOS: https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf
• macOS: https://www.apple.com/mac/docs/Apple_T2_Security_Chip_Overview.pdf

PPTP VPNs no longer supported by Apple’s built-in VPN client on macOS Sierra and iOS 10

Starting in OS X El Capitan and iOS 9, people trying to set up a PPTP VPN connection on their iOS device or on their Mac would get a warning that looked like this:

iOS:

OS X:

The reason for these warnings is that a number of security vulnerabilities have been found in this VPN communications protocol. These warnings have been Apple’s way of encouraging their customers to stop using PPTP for their VPN connections and move on to other more secure VPN protocols.

As part of preparing for the release of macOS Sierra and iOS 10, Apple has publicly announced they’re moving from warning folks about PPTP to removing PPTP support altogether from Apple’s built-in VPN client. In place of PPTP, Apple is again recommending the use of other VPN communications protocols that are more secure.

For those who will still need to access PPTP VPNs, you may be able to use a third-party client to do so on macOS Sierra. A couple of third-party VPN clients I’m aware of which currently support PPTP on OS X El Capitan are Shimo and VPN Tracker.