macOS Big Sur 11.4 and Proxy via Profile – Finally Fixed

macOS 11.4 was released this week and one issue we have been dealing with and raised with Apple in December 2020 is finally fixed.

The Big Sur 11.4 release notes for Enterprise are as below the one we are interested in for this article is number 5.

  1. Using MDM to install software updates works more reliably on Mac computers with Apple silicon.
  2. Resolves an issue where first login with a mobile account does not create a login keychain.
  3. Setup Assistant no longer skips Location Services when account creation is skipped by MDM.
  4. App installations from MDM are no longer canceled during setup when the country is changed.
  5. Resolves an issue where DNS lookups may fail when using an authenticated proxy or a proxy configured with a PAC file.
  6. Resolves an issue where the Kerberos SSO extension may fail to renew credentials.
  7. Resolves an issue where iCloud Keychain sync could not be restricted by MDM.
  8. Resolves an issue where StorNext volumes from fsforeignservers file would not mount automatically.

This item refers to when a Profile is used to set a Proxy using a authenticate PAC URL. This worked fine in Catalina but in Big Sur when the Profile was used this then caused a failure to contact our internal domain name due to the DNS lookup issue it caused. This was easily demonstrated by pinging the domain and then adding and removing the Profile. With the Profile ping failed, without the Profile ping was successful. The same domain is also used for our SSO extension so we could not use a Profile until now to set the proxy.

The workaround was a bash script which was set to run via a Jamf policy at check-in or Network Change. The script ran through every network connection available and entered the PAC URL for the Automatic Proxy Configuration URL box.

As this item was still user editable (we don’t lock Network prefs to users) it could be removed by the user so hence why it was run on Check-in or Network Change and therfore added back in in case the user had taken it out. The reason they take out is the Proxy service we use can be dreadfully slow but it’s there to protect the device so is a Security requirement.

The issue here is the policy can run 100’s of times a day on a single device and each time it runs its recoded to the Jamf database, so it’s not efficient.

Now this is fixed we have gone back to a simple Profile configured in Jamf with a Proxy payload. This is silently deployed to Macs as they upgrade to 11.4 and the current Policy is excluded, this is all done using scoping in jamf to smart groups plus we have a clean-up script that removes the entry from the Network prefs as Profile settings are not shown in GUI. The change is totally seamless and users don’t even realise it’s happening.

It’s great to have this working again but its issues like this and the time to resolve especially when its a regression from a previous OS that slow down the roll out of each macOS release in Enterprise environments. With this fix plus the SSO fixes Big Sur now feels Enterprise ready but 7 months after release and two weeks before WWDC when we will no doubt hear about macOS 12.

macOS Kerberos SSO authentication in Google Chrome

SSO on macOS for Safari is out of the box, no config required. As long as the Mac is getting a valid Kerberos ticket which can be checked in the terminal or via the Ticket Viewer app you are good to go.

Google Chrome however takes a little bit of config which can be set via a Profile for SSO to work.

The settings required are:
AuthNegotiateDelegateAllowlist
AuthServerAllowlist

Notice both these end Allowlist and not Whitelist. From Chrome 86 Allowlist was introduced and Whitelist was deprecated.

Deprecated
https://chromeenterprise.google/policies/#AuthNegotiateDelegateWhitelist
https://chromeenterprise.google/policies/#AuthServerWhitelist

Current
https://chromeenterprise.google/policies/#AuthNegotiateDelegateAllowlist
https://chromeenterprise.google/policies/#AuthServerAllowlist

You can check if these are in place by typing chrome://policy into the URL bar, this will show the policies set
Chrome Policy Settings

If not set these SSO will fail in Chrome.

To set in Jamf you could create a mobileconfig or plist locally, then create a new Profile with a Application & Custom Settings payload and use the Upload section but a better option is to use the in-built External Applications section of the Application & Custom Settings payload and select the Jamf Repository and choose a JSON schema.
Jamf Profile

Once saved this will show all the Google Chrome options as a GUI where you can select the items you wish to configure and enter the settings required.

For SSO pick the two items described and enter your domain or domains.
Chrome Settings Jamf Profile

These can be wildcarded and multiple domains separated with a comma

*mydomain1.net, *.mydomain2.com

Once in place, simply scope in the normal way and test out.

Unifi Controller Cloud Access Issue Resolved

I’m a big fan of Unifi kit but a while back I did a Cloudkey controller update and lost access to enable remote access.

All I was seeing was this:

When clicking on Enable Remote Access the error was instant, not enough time from clicking to trying to sign in so I knew something was up.

I also noticed that I was no longer getting update notifications for my Unifi Access Points or my Unifi USG.  After another firmware update to the Unifi Cloudkey (1.1.11) and controller update (5.12.72.x) I was still unable to get remote access to work.

The fix however is simple:

ssh into your cloudkey

Once in stop the unif service
service unifi stop

Then run the following to remove and update certs

rm /etc/ssl/certs/java/cacerts &> /dev/null; update-ca-certificates -f

Then start the service

service unifi start

And we are back 🙂
Remote access now enabled and also all my kit started reporting updates available.