Managing ALF Firewall via Jamf Profile

[meyre76]

I am migrating my workflow of managing the macOS ALF firewall from scripts/policies to Jamf MDM profiles. Found odd behavior that prevents users from making changes.

Even though I have explicitly set the new ALF profile to allow users to modify ALF if needed (Jamf Privacy & Security > Firewall settings change > Enable user changes to the firewall settings), the ability to manage ALF locally is greyed-out (disabled) on my test Macs - even though the user is a local admin(and can authenticate to unlock the Security & Privacy pane.
As soon as I remove the profile (un-scope the target Mac) the ability to modify ALF returns.

When I examine the raw XML plist (/Library/Managed Preferences/com.apple.security.firewall.plist) I dont see any key/value pairs related to restricting users from modifying ALF (assuming I'm looking in the correct location.)

When I look at the raw XML plist (/Library/Managed Preferences/com.apple.security.firewall.plist) I don't see any key/value pairs related to restricting users from modifying ALF (assuming I'm looking in the correct location.)

I don't see any trace of a com.apple.alf plist file (maybe it was replaced/deprecated?)

Any idea as to why users are prevented from making changes when the MDM profile explicitly allows it?

[boberito]

In macOS Monterey, if the application layer firewall is controlled by MDM, it is locked as it should be. This is different to how the behavior was in Big Sur and previous where if controlled by the MDM it could be overridden by an admin. This was no bueno as you think it was on but it could really have been turned off.

[dstranathan]

@boberito Can you share any Apple docs that state this new behavior in macOS 12 Monterey, please?

[boberito]

It was mentioned in the Appleseed beta notes during the beta period. I have no idea where you'd find it now.

[dstranathan]

I'm in a similar situation here too. I migrated my ALF management from a script/policy recently to an MDM profile (required for macOS 12 Monterey).

When the ALF profile is scoped to my Macs, users are no longer able to modify any ALF settings. Local admins can unlock the Security & Privacy pref pane as expected, BUT the ALF button to "Turn Off Firewall..." is grayed-out - and they cant modify and ALF rules, either.

There is an explicit Jamf MDM Profile setting named "Firewall settings change (If restricted, disables user changes to the firewall settings)” which is disabled so that users should be able to make changes. This setting translates to the key/value pair of “DontAllowFirewallUI” when looking at System Profiler and the Profiles pref pane. The value is correctly set to 0 (disabled). But ALF can not be modified contrary to the value.

To clarify: This is affecting macOS 12 Monterey, macOS 11 Big Sur, and macOS 10.15 Catalina. NOT just Monterey.

[boberito]

the dontAllowFireWallUI has existed since 10.10

https://developer.apple.com/documentation/devicemanagement/securitypreferences?language=objc

[dstranathan]

Is dontAllowFireWallUI the key/value pair you think is not working in macOS 12 Monterey?

Even if I create a stand-alone ad-hoc plist (domain = com.apple.preference.security) containing only the 'dontAllowFireWallUI' key/value pair and upload it to Jamf, the target Macs ignore this.

[dstranathan]

After escalating 2 times, Jamf support has confirmed this issue in case #CS0795725 and can reproduce this. They are currently determining if this is an Apple bug/change or a Jamf MDM issue.

[vagabon]

Did you ever hear anything further about this, @dstranathan 

[dstranathan]

@vagabon Yes, my Jamf Support case has bee escalated and the support techs have reproduced the same issues/limitations. They are reaching out to Apple on the matter to confirm if Apple's MDM settings have changed or if Jamf's implementation is incorrect/broken.

More news as it happens...

[dstranathan]

Updated info:

I have a case open still (CS0795725). According to Jamf, there is a known Jamf Pro PI (Product Issue #PI107278 "ALF profile targeting the wrong Apple pref domain”). This PI is not available to the public and I have no clue why not. I haven had this case open for 4+ months and never knew there was an existing PI (and neither did my technician...?)

Here is the suggested temp workaround that I am testing:

1 Disable any Jamf profiles/policies that are currently managing ALF (if any) on a specific IT test Mac.
2 Go to the IT test Mac and configure ALF via GUI pref pane manually.
3 Capture the XML settings you want from /Library/Preferences/com.apple.alf.plist. Use a text editor or a tool like PlistEdit Pro etc.
4 Upload those curated ALF settings to a custom Jamf profile and target the pref domain of com.apple.alf.
5 Scope to test Macs, etc.

I have been testing on existing Macs that already had ALF enabled (i.e.; not on newly purchased Macs that are getting deployed/enrolled 'clean' without any history of ALF management), so I don't know if the procedure above will actually enable ALF or not (meaning that the settings look correct to me once the profile is applied, but I haven't tested if this will actually activate ALF launch agent etc).

[smcmullan88]

Hi,

How did you manage to get the plist file to update? I keep getting an error on my profile when trying to update the domain com.apple.alf with the plist exported from the mac with the settings I want to deploy.  It seems like the profile I have created is fine but it can't update on the device resulting in an error.

Thanks

[jnoyes1]

So I tested this and it does work - enables firewall, etc and allows the user to modify the settings... however, the settings revert on login back to the plist. Does anyone have any options for that which would allow the user updates to stick after they're made?

[dcorona]

^I'm having the same issue, hopefully Jamf can get this working soon!