“Apple is not Enterprise” – Why this is not true.

I often hear from managers and IT leaders that “Apple is not Enterprise focused because…” and then a number of variations. There seems to be something in common with the people saying this and that is what they think is Enterprise. Their Enterprise is usually based 10,20 or 40 years experience of a Windows centric environments.

Apple is certainly Enterprise focused. I work with some amazing Apple Enterprise Engineers, Developers and Account Managers all from their Enterprise Division. Plus, support from Apple Enterprise Support and AppleCare for Enterprise. All this along with Apple Seed programme allows me extra insight and direct named contacts to aid deploying devices in the Enterprise and keeping them running with superb help and support. If Apple were not Enterprise why would these areas exist.

If you want control, simple use Jamf Pro. Jamf and Apple have a long-standing relationship, Jamf have a history of being Day 0 ready for major macOS releases. The same is true of Cisco, there is a deep partnership. These 3rd parties and products are for the Enterprise, you don’t need to run Jamf at home. Why would Apple create and maintain these relationships if they were not Enterprise focused.

As said this opinion of Apple bot being Enterprise seems to come from the individuals understanding of what Enterprise is and that is mainly a Microsoft Windows centric view with devices using Active Directory having layers of additional security and user controls who are seemingly unwilling to depart from these thought processes.

Enterprise is in fact what you make it and it can be much better with Mac’s and Jamf Pro. The best Enterprise environments are where the user has choice, that way the user feels more confident and will be more comfortable with what they know and therefore more productive.

Mac’s can fit into your infrastructure with ease you just need to respect and work with its differences and not against them and not try and force them to work the way your Windows devices work, after all it’s a different platform, it requires different thinking, different support and management.

In the late 90’s and early 2000’s Apple had a Think Different campaign for their consumer products, that needs to come across to Enterprise IT leaders.

Apple tvOS 15 Homebridge Control

If you use Homebridge and have an Apple TV you may know since tvOS 15 on/off control stopped working with the Homebridge Apple TV Remote plugin, the plug fails to find your AppleTV and is not yet fixed.

However I have come come up with a workaround and now have tvOS 15 on/off control.

I run Homebridge on a Raspberry Pi and the first step is to install the latest version of https://pyatv.dev

Once installed I then paired my Apple TV using the command
atvremote -s APPLETVIPADDRESS --protocol companion pair

atvremote -s 192.168.1.100 --protocol companion pair
Enter PIN on screen: 4337
Pairing seems to have succeeded, yey!
You may now use these credentials: ac1c0e52f256dc5f7b47f5f1f4f1e2a40b3c5676f7d598ac686de8b2afc23a54:cba29ca821e92d98ffa8e1eeab5b18a26b2b6a431f5056b452021ee057fa4a6b:43463041354438422d384242362<SNIP>

I copied the long string of numbers and created 3 shell scripts, adding my IP address of the ATV and the long string of numbers to each:

appletv_on.sh
atvremote -s 192.168.1.100 --airplay-credentials ac1c0e52f256dc5f7b47f5f1f4f1e2a40b3c5676f7d598ac686de8b2afc23a54:cba29ca821e92d98ffa8e1eeab5b18a26b2b6a431f5056b452021ee057fa4a6b:43463041354438422d384242362<SNIP> turn_on

appletv_off.sh
atvremote -s 192.168.1.100 --airplay-credentials ac1c0e52f256dc5f7b47f5f1f4f1e2a40b3c5676f7d598ac686de8b2afc23a54:cba29ca821e92d98ffa8e1eeab5b18a26b2b6a431f5056b452021ee057fa4a6b:43463041354438422d384242362<SNIP> turn_off

appletv_state.sh
atvremote -s 192.168.1.100 --airplay-credentials ac1c0e52f256dc5f7b47f5f1f4f1e2a40b3c5676f7d598ac686de8b2afc23a54:cba29ca821e92d98ffa8e1eeab5b18a26b2b6a431f5056b452021ee057fa4a6b:43463041354438422d384242362<SNIP> power_state

I copied those 3 scripts to my Raspberry Pi at /var/lib/homebridge

I then installed homebridge-script2-ventrilo Homebridge plugin which is a simple plugin that can run the scripts and added the following config:

{
    "accessory": "Script2",
    "name": "ATV",
    "on": "/var/lib/homebridge/appletv_on.sh",
    "off": "/var/lib/homebridge/appletv_off.sh",
    "state": "/var/lib/homebridge/appletv_state.sh",
    "fileState": "/var/lib/homebridge/script1.flag",
    "on_value": "true"
}

In Home app I can now turn on and off the ATV 🙂

As I run the Alexa Homebridge plugin I told Alexa to discover devices, ATV was found and I added this to a routine “Watch Apple TV” which turns on the TV, AV Amp, switches HDMI input and now powers on the AppleTV 🙂

macOS 12 Monterey Hardware Not Supported – How to create a Jamf report

With WWDC just over a week old and macOS 12 Monterey available as developer beta Apple published a list of supported hardware that it will run on:

  • ‌iMac‌ – Late 2015 and later
  • ‌iMac‌ Pro – 2017 and later
  • ‌MacBook Air‌ – Early 2015 and later
  • MacBook Pro – Early 2015 and later
  • Mac Pro- Late 2013 and later
  • Mac mini- Late 2014 and later
  • MacBook – Early 2016 and later

As an Enterprise Jamf Admin I’m more interested on what hardware it won’t run on so those users with unsupported hardware can be informed and asked to purchase a new Mac, ideally a M1 powered Mac as there seems little point now purchasing a Intel Mac unless you need a big screen laptop or a Mac Pro.

To find out which enrolled devices are not supported is very easy to do in Jamf with use of a Smart Group and then for further information a Search Inventory item

Smart Group

  1. Create a new Smart Group and give a name like Monterey Hardware Not Supported
  2. From the Criteria section chose Model Identifier
  3. From the drop down select does not match regex
  4. In the field copy and paste the following text:
    (MacBookAir([7-9]|10)|MacPro[6-7]|MacBook(10|9)|Macmini[7-9]|MacPro[6-7]|iMacPro1|iMac(1[6-9]|2[0-1])),\d|MacBookPro(11,[4-5]|(1[2-7]),\d)Your Criteria will should look like this
  5. Save the Smart Group and view the list of Mac’s.If you have non-supported hardware it will be shown. For me I could see we have MacBook Airs and MacBook Pro’s and even an old iMac going back to 2012 and 2013. This corresponds with Apples Supported list. Double check a couple of your entries by viewing the device information.


Search Inventory
Now we have our Smart Group we can use this in a Search Inventory item so we can add and view further details about each device like owner details and output as a CSV. Again Jamf makes this simple.

  1. Create a new Search Inventory item and tick the Save this search box and give it a relevant name
  2. In the Criteria section click Add and click Choose for Computer Group
  3.  Leave the Operator as member of and in the Value field enter the name of our Smart Group which was Monterey Hardware Not Supported. You can part enter and click the 3 dots to show the groups with similar name.
  4. In the Display section choose each tab, Computer, Hardware etc and tick the options for information you want to show on-screen and in your CSV.

    For this I choose from each tab as below
    Computer:
    Computer Name
    Last Check-in
    Last Inventory UpdateHardware:
    Model
    Serial Number

    Operating System:
    Operating System Version

    User and Location:
    Email Address
    Full Name
    Username

  5. Save the report by clicking Save from the bottom right set of icons.
  6. View the report by clicking View in the bottom and you will see the Mac’s listed with details chosen.
    (I’ve blocked out some details in the screen shot for privacy reasons)
  7. To output to the list click Report in the bottom right.
  8. Then click Download Report.
    You can choose a few various format but we will leave as CSV.
  9. A CSV file will be downloaded to your computer.

Now open CSV  in Excel or Numbers you can then easily contact the users to ask them to replace their device so they are ready for macOS 12 Monterey.

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.

JSON Schemas in jamf

From around jamf 10.19 a new feature was added that is slowly gain more traction and that’s the ability to use JSON (JavaScript Object Notation) schemas in the Applications and Custom Settings payload. Over time jamf have updated and improved its functionality and ease of use. This article assumes you are on at least jamf 10.26.

So what does all that mean?
It means an app vendor, developer or anyone can create a schema that in turn can be used to create the Profile configuration directly in jamf rather than having to write XML or use other tools like ProfileCreator. This simplifies Profile creation and is a huge time saver.

So let’s give it a go….

Create a new Profile.
Name it and select a category just like creating any other Profile:

Once done scroll down and select the Applications and Custom Settings payload.

It will open up and show a few options:
Jamf Applications
External Applications
Upload

If you use other jamf applications such as jamf connect suite (Login, Sync Verify) you can set up the Profiles from here directly in jamf. For this article though we are going to use the External Applications option.

Select External Applications then click the +Add button on the right. The page will show as below with a Source dropdown:

Click the dropdown and you will see Repository and Custom Schema options. If you select Repository you will see an Application Domain dropdown and within this schemas for Chrome, MAU, Office, Outlook.

For this article lets choose the Custom Schema from the Source dropdown:

You will see a Preference Domain box and the Custom Schema box.

If we want to set up a Profile for NoMAD we would first enter the plist file name. The plist contains the configuration and will be created on the devices we scope the Profile to.

In the Preference Domain box enter com.trusourcelabs.NoMAD.json

Note the name is case sensitive so enter exactly as shown.

 In the Custom Schema box we can now enter the JSON schema, lucky for us one has been created and you can find it here:
https://github.com/Jamf-Custom-Profile-Schemas/mscottblake-schemas/blob/master/com.trusourcelabs.NoMAD.json

Carefully copy and paste the XML from github into the Custom Schema field. I usually select the Raw view on github, then select all and copy.

It should now look like this:

Now scroll down past the Custom Schema field and you will see the JSON XML transformed into items configurable items right inside jamf.

Here you can see the Key’s you would set in XML as configurable items:

You may fine all the configuration items are shown but you can customise the list from the +Add/Remove Keys. Simply check or uncheck the items you require and click OK:

Go ahead and create your Profile by selecting the options you want and adding in the configuration required. The schema creator has helpfully added links to the NoMAD pages for each item so you can quickly see what the config item refers to. Remember to click Save regularly.

When you are ready to test the Profile scope to you test Mac and save again to push it to that device.

And that’s it. No more creating XML by hand, uploading, testing, editing and repeat. It can all be done in jamf.
This is just one example of a schema there are many other JSON schemas on github and Jamf Nation, here are a few I’ve found:

Talkingmoose’s substantial list:
https://github.com/talkingmoose/jamf-manifests

AgileBits 1Password
Apple Safari
Google Chrome and Keystone – although this is already built it as described above
Jamf Products
Microsoft Defender, Edge, OneDrive, Outlook
SAP
https://github.com/Jamf-Custom-Profile-Schemas/JSON-Schema-for-Jamf-Pro-Applications-and-Settings-MDM-Payload

Safari
NoMAD
Zoom
macOS Notifications
https://github.com/bpstuder/jamf_custom_schema

BBedit
Transmit
https://github.com/chrisgrande/jamf-profile-schemas

Managed Installs
https://github.com/joshua-d-miller/JAMF-JSON-Schema

MS Edge
https://blogs.windows.com/msedgedev/2020/02/20/edge-profiles-jamf-applications-custom-settings/

Cant find the schema you want?
I’ve not tried this but there is an app to help create the JSON schema, give it a go and if it works out publish it for other on github.
Schema Builder
https://github.com/BIG-RAT/Managed-App-Schema-Builder

Unbind from AD – The Silent Way

In my last post I detailed how NoMAD Login 1.4 can be used to silently convert a Mobile account to a Local account using the demobilize function. If the Mac is bound to AD the bind will still in place so after the demobilize is completed you may want to remove the bind as well.

Again, this can be done silently and is very simple using an MDM like jamf.

Create a new policy and name something like AD Unbind
Set the Trigger to be Check-in
Set the Execution Frequency to be Once per Computer
Add a Files & Processes payload
File and Processes

In the Execute command section add the following:
Execute Command

dsconfigad -force -remove -u test -p test

This will remove the bind, the -u (username) and -p (password) can be anything you want.
Scope the policy to your devices and save.

On next check-in the Bind will be gone. To test grab a Mac that is bound to AD, open the terminal and force a check-in with
sudo jamf policy

You will see the policy run and then if check System Preferences > Users and Groups and click the Login Options and you will where the Bind domain use to show with a green dot will now just show as below.

Bind Gone

That’s it.

Mobile to Local – The Silent Way

Apple is encouraging Enterprise Mac Admins to shift away from binding to Active Directory and Mobile accounts. If you have Mac’s with Mobile accounts they can be converted to Local and there are some great scripts to do this. The one from Rich Trouton is very good and there is also a Swift app by Leslie Helou. However, these require user interaction if you want a silent way to switch there is a very simple alternative option.

NoMAD Login 1.4+ allows silent Mobile to Local conversion using the demobilize function and it’s very simple to deploy via jamf MDM.

Head over to the NoMAD Login page on gitlab and have a quick read about NoMAD Login:
https://gitlab.com/orchardandgrove-oss/NoMADLogin-AD/-/wikis/home

Download NoMAD Login here:
https://files.nomad.menu/NoMAD-Login-AD.pkg

Once you have download the pkg add it to jamf in the usual way create a new Policy and add NoMAD-Login-AD.pkg to the Packages payload:
Jamf Policy

Add to the Policy a Files & Processes payload:
File and Processes

In the Execute Command section add the following:
Execute Command

authchanger -reset -demobilize;defaults write /Library/Preferences/menu.nomad.login.ad.plist DemobilizeUsers -bool true;sudo jamf recon

This command will instruct NoMAD Login to demobilize which is NoMAD Login speak for converting from Mobile to Local and for good measure run a jamf recon.

The policy can be scoped to your devices as you require and run with the options you require for example at Check-in. The policy only needs to run once. You could make it a Self Service item and instruct your users to run from Self Service when they require.

Once run the user will require to log our or reboot and at next login the account will switch from Mobile to Local. You could request this in your policy or force a reboot but as we want this to be silent simply wait for the user to perform the action. The first time they do login after the policy has run this the login may be a little slower.

You may also want to collect account information about which type of account is on the Mac. This can be done via a simple Extension Attribute script.

Create an EA script using the below:

#!/bin/sh
NETACCLIST=`dscl . list /Users OriginalNodeName | awk '{print $1}' 2>/dev/null`
if [ "$NETACCLIST" == "" ]; then
echo "<result>Local</result>"
else
echo "<result>Mobile</result>"
fi
exit 0

When a Mac next does a full jamf inventory update the account type will be collected and show:
Mobile or Local

If you have a mixed environment of Mobile and Local accounts set up the EA and let it run for a few days or weeks collecting device account type. Then create a Smart Group to show devices that have Mobile accounts and scope your Mobile to Local Policy to the smart group.

If the Mac is Bound to AD the demobilize will leave the bind in place. This can be removed when required by another simple policy which I’ve detailed in this post

Happy demobilizing.

Philips hue API & Twitch Stream

I recently added a Philips hue Lightstrip to my hue collection with a specific intent. My son has started a twitch channel (please follow) and I wanted way to know when he is online using the Lightstrip so not to enter the room he streams from as I’d be in the camera shot and at the age of 14 your dad in your stream is no a good thing, apparently.

I came up with the following idea. Lights are green when he is on the computer but go red when he streams. So how do you make this happen.

Firstly I checked out IFTT but its just not good enough, sure you can change the light the you start streaming but there is nothing to change back the you stop streaming.

The answer was an addition to my Home Assistant instance.

Once twitch is configured in HA a simple automation can monitor the status of stream and change the lights from green to red and then red to green.

Next thought was turning the lights on and off and to do this called for using the Hue API. This is fairly easy to construct once you have your API key. Hue have a really simple guide on how to do this and also find the ID of the lights on your network you want to control.

So once we have our API key and the ID of our lights we can make a Powershell script to run on the PC used for twitch streaming as below:

$apicontent= '{"on":true, "sat":254, "bri":254,"hue":25535}'
Invoke-WebRequest -Method put -Uri http://192.168.X.XX/api/YOURAPIKEY/lights/10/state -Body $apicontent -UseBasicParsing

The first line controls the lights, "on":true turns the light on following three parts set the lights temperature, brightness and colour, 25535 is green.

The second line does the web request and is were is you add your huebase station IP address, your api key and the light device ID, in this example it’s 10.

So now we can add this to our PC as .ps1 file I called mine hueon.ps1 and dropped it directly in C:/ root.
Next we need to create a batch file to call the powershell script as below:

@ECHO OFF
PowerShell.exe -Command "C:/hueon.ps1"

This can be saved anywhere you want I called mine hueon.bat and saved to my documents folder. If you run this your lights should come on. If they don’t check your the path is correct to the .ps1 and the API call is correct.

Now we need to call the batch file at logon to do that in the Windows search bar type run and then open gpedit.msc and go to:
User Configuration -> Windows Settings -> Scripts -> Logon -> Properties -> Add

Select you .bat file and you are done. When the PC logs in, the .bat will run the Powershell script and on come the lights.

If you want the lights to go off when you logout/shutdown your PC just repeat creating a .ps1 & .bat but change "on":true to "on":false in your API call and in gpedit.msc select logout and then you batch file.

So now we have:
PC boots and logs in lights come on and go green
If a twitch stream is started they go red
When the stream is stopped they go green
When the PC  is logged out or shutdown they go off

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.