My org used to use Windows Defender AntiVirus on our macs (we trialled it for a short time but eventually moved to Jamf Protect instead). A System Extension configuration profile was required to deploy WDAV onto our devices. When we moved on from WDAV, we de-scoped the configuration profile from devices, but the network profile remains on our older devices.
This hasn't been a problem until recently. We're now trialling Jamf Network Threat Protection, but the configuration profile to deploy NTP conflicts with the WDAV network profile/sysext. This has been confirmed by Jamf Support (conflicts with DNS settings), as well as proven on my own device - With the com.microsoft.wdav network profile enrolled, my device is not manageable/visible in Jamf NTP/Radar. Once I manually removed the wdav profile and re-pushed the Jamf NTP config profile to my device, it was now manageable/visible in the NTP portal.
I now want to force-remove the com.microsoft.wdav profile from our devices, but I'm unsure how this can be done. I'm finding other posts that force-removing system extensions from devices is not possible. Is this still the case? Is there a workaround?
Thanks in advance!
In my experience with Cisco. When removing a network extension the user must enter credentials to actually remove it. If that step is skipped (ie the user closes the box out) the app related to the extension is removed, and the extension is orphaned. It can be removed with SIP disabled though, supposedly apple is planning on removing the SIP requirement at some point so this can be managed from CLI.
Yes - if you look at Richard Trouton's blog here https://derflounder.wordpress.com/2020/09/01/uninstalling-macos-system-extensions/ you will see that this has been an issue for at least two years. When you execute the command it still gives the message:
systemextensionsctl uninstall UBF8T346G9 com.microsoft.wdav.epsext
At this time, this tool cannot be used if System Integrity Protection is enabled.
This limitation will be removed in the near future.
Please remember to re-enable System Integrity Protection!
Yep. I was trying to think of the message but could not remember it and was too lazy to reproduce lol. Its been like that since Catalina. So, this limitation that will be removed in the near future has been around for 4 OS releases unless it gets pulled in Ventura which I doubt. Sounds like time for more feedback requests.
I made a feedback. If anyone wants to use my template here it is. This is not related to Ventura, its a left over thing from Catalina. However, Apple is paying attention to Ventura right now, so why not point at Ventura. Update as needed :).
Subject: systemextensionsctl uninstall without disabling SIP
Which are are you seeing issues with: Security
What type of feedback are you reporting: Suggestion
What does this Security issue you are seeing involve? Something else not on this list.
Are you able to reproduce this issue? Yes
This feedback is about a change in default behavior for macOS Ventura that, if left unmanaged, will impact our ability to upgrade existing Macs and deploy new ones.
SCOPE OF IMPACT:
* ### Macs eligible (or likely) to upgrade to Ventura;
* ### Macs refreshed annually;
* ### Macs across the entire organization;
* ### computers across all operating systems.
PROBLEM: systemextensionsctl uninstall requires SIP to be disabled which prevents programmatic removal or hands off troubleshooting of system extensions
ISSUES & CONCERNS:
- Requires a user to be walked through disabling SIP on their device
- Lowers macOS’s Security for basic application troubleshooting
- More clicks to troubleshoot system extensions leads to more helpdesk calls
- EFI and recovery passwords limiting access to recovery lead to more devices needing to be reprovisioned to troubleshoot system extensions
WHY THIS MATTERS:
(company name here) Leverages EFI and Recovery lock passwords to prevent users from accessing macOS recovery. These passwords are not known to the end user. This requires devices to be shipped into a central location for support staff to perform simple troubleshooting which should be able to be performed remotely. In many cases devices must be needlessly reprovisioned via MDM command to simply remove an orphaned or corrupted system extension. This leads to a poor user experience, and unnecessary device reprovisioning.
The default behavior when running systemextensionsctl uninstall is to present a message that states this limitation will be removed in the very near future. This was 3 years ago.
### Further details on why this matters###
- Application names here
REQUESTS &/OR SUGGESTIONS:
- Update the systemextensionsctl uninstall command to no longer require SIP to be disabled to run.
- provide an alternative solution for managed devices that can force remove system extension that are no longer needed, or broken and cannot be removed by the application that installed the System Extension.