{"id":1516,"date":"2024-09-27T19:03:10","date_gmt":"2024-09-28T00:03:10","guid":{"rendered":"https:\/\/www.brunerd.com\/blog\/?p=1516"},"modified":"2024-10-10T10:14:35","modified_gmt":"2024-10-10T15:14:35","slug":"getting-ahead-of-private-wi-fi-address-changes-in-macos-sequoia","status":"publish","type":"post","link":"https:\/\/www.brunerd.com\/blog\/2024\/09\/27\/getting-ahead-of-private-wi-fi-address-changes-in-macos-sequoia\/","title":{"rendered":"Getting Ahead of Private Wi-Fi Address Changes in macOS Sequoia"},"content":{"rendered":"\n

It’s been a busy 2 weeks since Apple released macOS Sequoia<\/a>! One of the new features is private Wi-Fi addresses<\/a> aka “MAC address<\/a> randomization”. While this all well-and-good and can “improve your privacy”, it has been causing headaches for folks in the environments where random MAC address are not<\/em> a good thing.<\/p>\n\n\n\n

Now, Apple did<\/em> think about this somewhat as evidenced by: About private Wi-Fi addresses and enterprise networks<\/a> and Wi-Fi MDM settings for Apple devices<\/a> but they didn’t really do a complete “dress rehearsal” of what would happen: You can’t<\/em> deploy an MDM WiFi profile<\/a> with the DisableAssociationMACRandomization<\/code> key until<\/em> the Mac is already upgraded<\/strong> to macOS Sequoia and once upgraded to Sequoia the MAC randomizes and that could break your connectivity to get the new config profile! It’s a real “chicken and egg problem” \ud83d\udc23 that is laid out in great detail here<\/a>.<\/p>\n\n\n\n

Seeing the angst created, the contortions required, and overall FML vibes this was causing I did some investigations to see what could be done and guess what? You can pre-populate the PrivateMACAddressModeUserSetting<\/code> value to off<\/code><\/strong> in the wifi.network.ssid.<SSID><\/code> dictionary of \/Library\/Preferences\/com.apple.wifi.known-networks.plist<\/code> before <\/em>a Mac upgrades to Sequoia! \ud83c\udf89 Note: When you set this via script (versus GUI), the change does not take effect until reboot, the MAC stays randomized and the UI does not reflect this. This doesn’t matter if it’s for an upgrade to Sequoia but just letting you know if you try it on Macs already on Sequoia, it won’t take effect until a reboot. If there’s some clever kill -HUP<\/code> that can be sent let me know. I tried killall cfprefsd<\/code> but that wasn’t enough.<\/s> Update<\/strong>: Thanks to boberito in the MacAdmins Slack, he figured out that killing cfprefsd<\/code> and airportd<\/code> would update the UI and power cycling the Wi-Fi would cause this change to take effect! I’ve added an option<\/em> to the script to do this, set restartWiFi_HC=\"1\"<\/code> to restart Wi-Fi, just be aware you better make sure your Wi-Fi reconnects!<\/p>\n\n\n\n

If that’s all<\/em> you need to know, then god-speed and good luck to you! If you’d like a Jamf script and extension attribute read on…<\/p>\n\n\n\n

You can use the script setPrivateMACAddressMode<\/a> to set the mode of one or more SSIDs on a target Mac. As it is, the SSID must have been previously connected to so the wifi.network.ssid.<SSID><\/code> gets filled out. I tried writing the value to an un-populated dictionary and Wi-Fi just wigged out (like nothing in the SSID list kinda weirdness!). Keep that caveat in mind. If you can figure out a minimum viable set of keys that are needed then good for you but for this script, it’ll just skip the SSID if it’s not in alrready in com.apple.wifi.known-networks<\/code>. This script can be used with Jamf and its policy script parameters or<\/em> if you are on another MDM, just hard-code the SSIDs, I’ve made allowances for that.<\/p>\n\n\n\n

Next, this is a Jamf extension attribute OS-Private MAC Address Mode<\/a> it will report the mode and the SSID (example: off|My Cool Wifi<\/code>). You can have it report all<\/strong> known networks or just hardcode the value for specific SSID(s). It can be useful when used in a Smart Group. You could deploy a Major Update deferral config profile to block Sequoia then make a Smart Group for exclusion<\/em> using OS-Private MAC Address Mode<\/a> ‘is like<\/strong>‘ off<\/code> or ‘matches regex<\/strong>‘ ^off\\|<\/code>for more precise matching . When someone becomes a member the Smart Group it excludes them from the Major Update deferral config profile and can then upgrade to Sequoia.<\/p>\n\n\n\n

Lastly, if you don’t have Jamf but want to see what the values are getPrivateMACAddressMode<\/a> will spit out a a human readable list of SSIDs and modes (off<\/code>, static<\/code>, rotating<\/code>, and NOT_SET<\/code>)<\/p>\n\n\n\n

I usually try to put more pictures and illustrations in my posts but every moment I spend not publishing this, the more weekends that are possibly ruined by thinking about the suck that is macOS Sequoia Private Wi-Fi addresses in managed environments. I think this pic will sum things up! \ud83d\ude04<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

UPDATES: A couple things to keep in mind: 1) If you deploy Config Profiles with Wi-Fi payloads, then it will blow away everything about the SSID com.apple.wifi.known-networks<\/code> every time<\/em> the config profile is redeployed! 2) That means if you do deploy a Wi-Fi config profile with the Sequoia-only DisableAssociationMACRandomization<\/a><\/code> key it will blow away the manually set key PrivateMACAddressModeUserSetting<\/code> in com.apple.wifi.known-networks<\/code>. The EA OS-Private MAC Address Mode<\/a> currently does not<\/em> attempt to resolve if an SSID has a corresponding config profile profile with the DisableAssociationMACRandomization<\/a><\/code> key set, so it will be blank. 3) As of 15.0.1 a user can still change<\/em> the setting even when deployed via MDM, contrary to Apple’s stated behavior: “This value is only locked when MDM installs the profile<\/strong>. If the profile is manually installed, the system sets the value but the user can change it”. 3b) Actually I found that if you killall airportd<\/code> before rebooting, it’ll lock the value \u2013 until reboot<\/em>. 4) Apple also draws user attention to setting with a caution icon \u26a0\ufe0f in the Wi-Fi dropdown rather than a “check” icon like they use for managed Login Items in System Settings (the whole thing is an inconsistent mess)<\/p>\n\n\n\n

Update 2: Steven Xu over in the Jamf Nation forums<\/a> found that setting the PrivateMACAddressModeSystemSetting<\/strong><\/code> key to 1<\/strong><\/code> (integer, not boolean) within \/Library\/Preferences\/SystemConfiguration\/com.apple.airport.preferences.plist<\/code> will disable<\/strong> Private MAC Addresses by default. Newly joined networks or networks where the PrivateMACAddressModeUserSetting<\/code> key for an SSID is off<\/code> or not<\/em> already set to static<\/code> or rotating<\/code> will use their actual MAC address. I’ve added support for setting this key in setPrivateMACAddressMode<\/a> and it too will not take effect in Sequoia+ until either a reboot or setting the variable to restartWiFi_HC=\"1\"<\/code>. Just keep in mind, perhaps you want<\/em> your users to have Private MAC addresses by default when joining new and unknown networks? Why should the free Wi-Fi at the food court or coffee shop get your real MAC address anyway!? The getPrivateMACAddressMode<\/a> script and extensions attribute OS-Private MAC Address Mode<\/a> have been updated to report on (disable)PrivateMACAddressModeSystemSetting<\/code> also.<\/p>\n\n\n\n

Code in this post:<\/p>\n\n\n\n