Archive

Archive for the ‘Mac administration’ Category

Allowing external boot drives for T2-equipped Macs

June 13, 2020 Leave a comment

With WWDC 2020 only a couple of weeks away, a number of folks are preparing to run the new beta version of macOS. While some will choose to go all-in and run the new OS on their main boot drive, others will prefer to install the new OS onto an external drive. However, for Macs equipped with T2 chips, there’s an extra step involved with allowing your Mac to boot from an external drive. For more details, please see below the jump.

Read more…

Mad, bad and possibly dangerous – a cautionary tale of software installation

June 5, 2020 8 comments

In my career, I’ve run across a lot of terrible installers in a variety of forms. The one I ran across today though is noteworthy enough that I want to point it out because of the following reasons:

  1. It’s an installer application. I have opinions on those.
  2. It’s for a security product where, as part of the installation, you need to provide the username and password for an account on the Mac which has:
  • Administrator privileges
  • Secure Token

Note: I have no interest in talking to the vendor’s legal department, so I will not be identifying the vendor or product by name in this post. Instead, I will refer to the product and vendor in this post as “ComputerBoat” and leave discovery of the company’s identity to interested researchers.

For more details, please see below the jump.

Read more…

Identifying and deleting Jamf Pro inventory records with duplicate serial numbers

May 26, 2020 2 comments

I recently saw an issue where several computers in Jamf Pro were showing up with the same serial number listed in their inventory records. This made it difficult to work with this serial number using the API because Jamf Pro Classic API calls may fail if we’re referencing the serial number in the API call and more than one inventory record exists with that serial number.

First off, how can this happen? Aren’t serial numbers supposed to be unique? They are, but there’s two instances where serial numbers may unfortunately be associated with more than one Mac.

Hardware repair:

When you send a Mac out for repair and the logic board is replaced as part of the repair, the Mac’s existing serial number is flashed onto the replacement logic board.

However, both the old and new logic boards have separate Unique Device Identifiers (UDID) associated with them. When enrolling a device into Jamf Pro, it is possible for a new inventory record to be set up if a device has:

  • The same serial number listed in as an existing inventory record
  • A UDID not found in other inventory records

Parallels macOS virtual machine:

macOS virtual machines set up by Parallels Desktop and other Parallels hypervisor products use the same serial number as the Mac which is running the Parallels hypervisor software. These VMs will likewise have separate Hardware UDIDs associated with them.

So what to do with these duplicate records? My recommendation is to delete them from your Jamf Pro server when you find them, especially if you do a lot of work using the API. To help with this task, a script has been developed to identify and delete unwanted duplicates. For more details, please see below the jump.

Read more…

Enabling Safari to successfully connect after changing a self-signed certificate

April 19, 2020 1 comment

Every so often, I need to use Safari to access something which is using a self-signed certificate. When I do so, Safari now walks you through the following procedure:

  1. Warns you something’s not right and give you the option of either going back or seeing the details.
  2. If you choose to see the details, Safari will let you view the certificate.

Screen Shot 2020 04 18 at 11 27 14 PM

Safari will also give you the option of proceeding anyway.

Screen Shot 2020 04 18 at 11 27 32 PM

If you choose to proceed anyway, Safari will store the self-signed certificate in your login keychain and mark it as trusted.

Screen Shot 2020 04 19 at 2 07 29 PM

With this certificate now marked as trusted, Safari will allow you to visit the website.

Screen Shot 2020 04 18 at 11 27 43 PM

However, what happens when the SSL certificate changes but keeps the same subject name? At this point, connections from Safari to the site will fail with an error message similar to the one described below:

Safari Can’t Open the Page
Safari can’t open the page because Safari can’t establish a secure connection to the server “server.name.here”.

Screen Shot 2020 04 18 at 11 23 11 PM

The reason that this message appears is because Safari is using HTTP Strict Transport Security, otherwise known as HSTS. One of the requirements of HSTS as implemented by Safari is that if the security of the connection cannot be ensured, Safari must terminate the connection and should not allow the user to access the web application.

Since the self-signed certificate stored in your login keychain and the SSL certificate being received don’t match each other, that tells Safari that the certificate being received can’t be trusted. The result is Safari immediately terminates the connection and displays an error message like the one shown above.

However, what if the certificate changing is known behavior and you know that proceeding is safe? It’s possible to re-set Safari’s behavior, but it’s not intuitive. For more details, please see below the jump.

Read more…

Kernel extension warning dialogs in macOS Catalina 10.15.4

March 25, 2020 1 comment

As part of macOS Catalina 10.15.4, Apple has begun displaying a new dialog window message concerning third-party kernel extensions. macOS Catalina is the last macOS to fully support the use of kernel extensions and these messages are meant to notify users of the following:

  • macOS had detected that a third-party kernel extension had been loaded.
  • The loaded kernel extension would be incompatible with an unspecified future version of macOS

Image  1

To further reinforce the message that kernel extensions are going away, Apple refers to them in the message window as “legacy system extensions”. System extensions were introduced as part of macOS Catalina and are Apple’s replacement for kernel extensions.

As of macOS 10.15.4, these messages are informational only and do not indicate that anything is wrong with the referenced third-party kernel extension. For more information, please see the link below:

https://support.apple.com/HT210999

Screen Shot 2020 03 25 at 8 55 48 AM

Blocking the messages

For a number of managed environments, these messages can be prevented from appearing. As long as a third-party kernel extension is whitelisted using an appropriate configuration profile, the message for it should not appear.

For more information about whitelisting kernel extensions using a configuration profile, please see the links below:

https://derflounder.wordpress.com/2018/04/12/whitelisting-third-party-kernel-extensions-using-profiles/
https://support.fleetsmith.com/hc/en-us/articles/360037495013-What-is-a-kernel-extension-
https://support.apple.com/guide/mdm/kernel-extension-policy-mdm88f99b98a/web

Categories: Mac administration, macOS

Disabling telemetry for Microsoft’s Visual Studio Code

March 20, 2020 1 comment

Recently, I was tasked with figuring out how to disable telemetry for Microsoft’s Visual Studio Code. Normally, you can disable telemetry in a Microsoft application through using a macOS configuration profile or by using a defaults command. In this case though, Microsoft bought Visual Studio Code along with the rest of Xamarin, and Xamarin had some different ideas on where and how to store settings.

In the case of Visual Studio Code, the command to disable telemetry is stored as a .json file in the following location:

/Users/username_here/Library/Application Support/Code/User/settings.json

Screen Shot 2020 03 20 at 12 56 55 PM

After some research and some work with an open source tool named jq, I was able to figure out how to handle disabling the telemetry setting. For more details, please see below the jump.

Read more…

Identifying which MDM server a Mac is enrolled with

March 18, 2020 Leave a comment

Every so often, you may run across a Mac which is enrolled in an MDM server which is different from the one it should be. However, if you’re checking remotely, it may be difficult to identify which one it is.

To help with this task, there is a script available which will parse the MDM enrollment profile on your Mac and identify the DNS name of the MDM server. For more details, please see below the jump.

Read more…

Jamf Pro Inventory Update and recon functions – alike, but not the same

March 13, 2020 3 comments

As part of discussing the outcome of a troubleshooting session concerning Jamf Pro and profile deployment with a teammate, I learned that the two functions that Jamf Pro uses to update its computer inventory worked in a similar fashion, but they weren’t identical.

The differences turned out to be important for profile deployment. For more details, please see below the jump.

Read more…

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

March 6, 2020 2 comments

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

Screen Shot 2020 03 05 at 4 41 31 PM

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.

Screen Shot 2020 03 05 at 4 27 54 PM

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.

Categories: iOS, Mac administration, macOS

Fixing Homebrew’s rsyslog on macOS Catalina

February 26, 2020 Leave a comment

As part of some recent testing, I needed to install rsyslog and the instructions I had referenced using Homebrew to do it. I used the following procedure to do it:

1. Set up a new VM running macOS 10.15.3 in VMware Fusion.

2. Inside the VM, open Terminal and install Homebrew by running the following command:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

3. Once Homebrew was installed, install rsyslog by running the following command:

brew install rsyslog

4. Copy a pre-configured rsyslog.conf file to /usr/local/etc/rsyslog.conf.

5. Set the following permissions on /usr/local/etc/rsyslog.conf:

File permissions

Owner: root - read, write
Group: wheel - read
Everyone: read

6. Start rsyslog by running the following command with root privileges:

brew services start rsyslog

When I checked on rsyslog though, it wasn’t running or accepting logs from remote Macs like it should be. What had happened?


Update – 3-5-2020: The problem described by this post has now been fixed:


 

For more details, please see below the jump.

Read more…

Categories: Mac administration, macOS, Unix
%d bloggers like this: