Like this:

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:

I have an off-server backup for the groups

I can track changes to the groups

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:

Use the Jamf Pro API to identify the Jamf Pro ID numbers of the smart and static groups.

Download each group as an XML file using its Jamf Pro ID number.

Format the downloaded XML.

Identify the display name of the group.

Identify if it was a smart or static group.

Save the downloaded XML as Group Name Here.xml to a specified download directory, based on whether it was a smart or static group.

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:

Use the Jamf Pro API to identify the Jamf Pro ID numbers of the configuration profiles.

Download each profile using its Jamf Pro ID number

Decode and format the profile

Identify the display name of the profile

Save the profile as Display Name Here.mobileconfig to a specified download directory.

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:

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.

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.

Like this:

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.)

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.

Like this:

Apple announced on Saturday, August 8th that the FIPS 140-2 validations for the cryptographic modules used by iOS 8 and OS X 10.10.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.)

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 Yosemite v10.10 documentation, in the Compliant Applications and Services section.

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