Preventing VPN Configuration for K12 Standard Users

Apple's security architecture for macOS security is letting down K12 technology managers. With the proliferation of all of the "free" VPN services and apps, Apple allows apps downloaded from the web to add VPN configurations to the System Preferences without administrative approval.


From a K12 perspective, there is no documentation or support for blocking this action for Standard (student users). Content filtering is required by CIPA https://www.fcc.gov/consumers/guides/childrens-internet-protection-act and most K12 institutions receive e-Rate funding that also requires us to enforce content filtering.


We can block searches for the VPN filesets to begin with, but there is no recourse once the app bundles are on the student device. Just by launching them, the profile is automatically added to System Preferences.


We've already looked through MDM solutions, and there is no clear solution with our MDM. We've tried to mark "require administrator to change network", and that has no effect on VPNs. MDMs and Chrome browser management profiles successfully prevent VPN extensions on the browser.


What's absolutely bizarre is Apple requires an admin to remove the system-wide VPN profiles. Why can't the reverse be enforced as policy? Why is there no option to prevent the profiles from being added in the first place?


Are there any other K12 institutions running into this problem. What efforts are being made to prevent these workarounds?

MacBook Air (M1, 2020)

Posted on Apr 13, 2024 5:43 AM

Reply
Question marked as Best reply

Posted on Apr 13, 2024 7:50 AM

Apple does provide a solution for this.


You do not detail which MDM you are using. However, this is available in most MDM through the UI. If it is not available in yours, you should be able to build a custom profile and block the manual add of configuration profiles. This should be set on your MDM as a standard enforcement, especially since you are an EDU. All profiles should be coming from the MDM. No exception.


We've already looked through MDM solutions, and there is no clear solution with our MDM. We've tried to mark "require administrator to change network", and that has no effect on VPNs. MDMs and Chrome browser management profiles successfully prevent VPN extensions on the browser.

What's absolutely bizarre is Apple requires an admin to remove the system-wide VPN profiles. Why can't the reverse be enforced as policy? Why is there no option to prevent the profiles from being added in the first place?



If you are in Jamf, the setting is in the Restrictions payload > Functionality tab = Allow configuration profile installation (macOS 13 or later, Supervised).



The details are "If 'false', prohibits the user from installing configuration profiles and certificates interactively. Requires a supervised device. Available in iOS 6 and later and macOS 13 and later."


If your MDM does not have this exposed in the UI, you can use a manual profiles like this:


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>allowUIConfigurationProfileInstallation</key>

<false/>

</dict>

</plist>


Set it to the preference domain of com.apple.applicationaccess. That should prevent user interactive addition of configuration profiles.


Hope this is helpful.


Reid


4 replies
Question marked as Best reply

Apr 13, 2024 7:50 AM in response to mercraes234

Apple does provide a solution for this.


You do not detail which MDM you are using. However, this is available in most MDM through the UI. If it is not available in yours, you should be able to build a custom profile and block the manual add of configuration profiles. This should be set on your MDM as a standard enforcement, especially since you are an EDU. All profiles should be coming from the MDM. No exception.


We've already looked through MDM solutions, and there is no clear solution with our MDM. We've tried to mark "require administrator to change network", and that has no effect on VPNs. MDMs and Chrome browser management profiles successfully prevent VPN extensions on the browser.

What's absolutely bizarre is Apple requires an admin to remove the system-wide VPN profiles. Why can't the reverse be enforced as policy? Why is there no option to prevent the profiles from being added in the first place?



If you are in Jamf, the setting is in the Restrictions payload > Functionality tab = Allow configuration profile installation (macOS 13 or later, Supervised).



The details are "If 'false', prohibits the user from installing configuration profiles and certificates interactively. Requires a supervised device. Available in iOS 6 and later and macOS 13 and later."


If your MDM does not have this exposed in the UI, you can use a manual profiles like this:


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>allowUIConfigurationProfileInstallation</key>

<false/>

</dict>

</plist>


Set it to the preference domain of com.apple.applicationaccess. That should prevent user interactive addition of configuration profiles.


Hope this is helpful.


Reid


Apr 15, 2024 3:16 PM in response to mercraes234

Jamf for EDU can be as low as $1.75/month/Mac if you come through a Jamf MSP partner. However, changing an MDM is not for the faint of heart. Best to do it through attrition as you refresh the fleet. However, in EDU, you can also do it in a Summer if you were to reset everything. Simple reassign the devices to a new MDM in ASM. Then wipe the devices, allowing Setup Assistant to prompt for automated enrollment. This will also allow you to enforce new features in the prestage, like recovery lock.


For WiFi, you will need a separate WiFi profile. The network payload should have proxy info. Again, the Jamf UI has this available in the standard Network payload, supporting both manual and automatic proxy config. Again, MDMs differ. The preference domain is com.apple.wifi.managed.


As for creating the profiles, there are the usual methods: Experience... knowing which preferences files to read the attributes from and using tools like defaults to create custom .plists. (defaults write preferenceDomain key type value) Read Apple's documentation. Take a look here for the Restrictions payloads. Review the entire document for all of Apple's supported payloads. That online documentation is extensive and worth reviewing to understand what Apple can and cannot manage. Please note, the use of custom profiles can expand management beyond what Apple publishes in the MDM guide. Know the difference between the requirements (require supervision, for example). And finally, if you want the fastest way of figuring this out, take a look at iMazing Editor, available in the Apple App Store. (You can even volume license it to assign to your team.). It will allow you to create custom profiles to control settings not in your MDM's UI. From the Payload menu, choose export as plist so you can derive the preference domain as well as see the key/value pairs in the preference file.


Hope this helps. You can fully manage your fleet by embracing and enforcing logical preference settings.





Apr 15, 2024 4:45 AM in response to mercraes234

Thanks for your quick attention. MDM is Filewave. Jamf has been too cost-prohibitive in their pricing.


Does this also lock the proxy configurations per WiFi SSID, if needed?


Your response shows a lot of knowledge of manual profiles and the XML markup that Apple uses... where did you learn about that and how can others learn if the MDM isn't providing the controls by GUI?


Preventing VPN Configuration for K12 Standard Users

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.