@ddcdennisb and all, yes allowing PPPC to com.apple.loginwindow does solve the issue!
I confirm you also also need to have defined a PPPC for jamf and also whichever shell you are using /bin/sh or /bin/bash
Many thanks to all!
Ciao
Carlo

hi all

after testing more this morning... works flawlessly !!!

I think that WE ROCK !!!!!!

@jmercier Yes we do! Although I still have some error with policies at logout which disappear if I change the DP to http, that was a given since the workaroubd with com.apple.loginwindow is meant... at login!
Cheers
Carlo

@carlo.anselmi Thank you for this thread! Could you provide screenshots of the PPPC machine you are using for /bin/bash and /bin/sh.

Thanks,
Jared

@jared_f I can't provide the screenshot immediately, I think this was where I found the configuration profile I used (credits go to its author)
Shells and Python System Events whitelist
I will update the thread once I get the test client
Cheers
Carlo

@everyone on this thread! Does adding the com.apple.loginwindow also solve this for policies failing to run during logout? I've tried it but they still seem to fail with the same "operation not permitted" error :(

@allanp81 Yes, I ended up creating a PPPC profile for com.apple.loginwindow and also allowing /bin/cp and other shells as per this duscussion Logout policies still do not work though

I don't think it'll ever work as /bin/cp is not signed.

Just want to say thank you to @nate.barkei and everyone in the thread who tested and dug into this problem. The PPPC for loginwindow has resolved my issue as well. Really appreciate the work everyone did.

@allanp81 Yup, I still haven't got this to work for deployments in my environment on Macs running macOS Catalina and still stuck with using HTTPS in the meantime.

As others have said, you can get login triggers working, but not logout and it sounds like this is unlikely to happen if Jamf etc. haven't already figured it out.

Unfortunately for me, my environment uses custom triggers for deployments, not login or logout. As Jamf support have advised me, I'm out of luck with SMB until Jamf engineers figure out a working solution, hopefully soon.

@dng2000 my Notify Script runs all custom triggers. Adding the com.loginwindow pppc worked fine for me as I only have SMB shares internally.

@ddcdennisb Custom triggers work fine without anything special, as do at recurring check in etc. It's only startup/login/logout that have issues.

@allanp81 In my environment, custom triggers work fine during recurring check-ins but not during provisioning that runs a bash script that calls the custom event triggers by running the jamf binary. My environment still runs an in-house app that runs DEPNotify and executes a bash script that calls specific groups of custom event triggers based on the user's department determined by the acronym used in the prefix of the determined hostname. So it's still a problem for my environment if and when I have to switch back to SMB. The biggest impact for me is actually two of my Tomcat nodes are literally doubling as the primary and backup HTTPS DP which is not always a healthy load depending on how many machines are running my in-house provisioning app that caches a lot of pkg's in the process.

@dng2000 I run custom triggers during deployment and they seem to work fine so you should be able to be able to create a profile that allows this.

@allanp81 Several profiles with various methods have already been attempted without success in my environment. But calling the custom triggers straight from Terminal and calling the bash scripts directly from the command line in Terminal work like a charm. Just not through my MacDeploy.app bundle which means I got more to figure out within my custom-built app when I got time again to deal with that.

@dng2000 Ah, I see, didn't realise what you meant.

@allanp81 Curiously, does your environment use https://<url>:8443/enroll for new Mac enrollments or a custom-built App for your own ZTI barring the part on manually approving the MDM? :)

@dng2000 I use the quickadd package.

I'm using DEPnotify with a launch daemon that runs a Jamf policy with provisioning script. The script calls on other policies to deploy packages via custom triggers. Internally using SMB FSDP and just ran into the "CP operation not permitted" issue while working on Catalina and new 2020 MacBook Airs.

Creating a PPPC for /bin/bash and /bin/sh, with allow Network Volumes and All Files did the trick. I did not have to include Terminal, CP, or loginwindow for things to work.

@MrRoboto Did you have to check "Validate the Static Code Requirement" for your environment? I use DEPnotify too but via a custom-built in-house app called ITFS-MacDeploy that my former co-worker developed. I set this problem aside in my environment for the past 2 months and haven't got back to troubleshooting this for my existing environment.

@dng2000 No I did not... just /bin/bash and /bin/sh, with allow Network Volumes and All Files. I also allowed /bin/sh to AppleSystemEvents for my re-naming script to work, and allowed Terminal to NetworkVolumes for manually running policies when needed.

Do the following to whitelist stuff happening at logout:

Whitelist /System/Library/CoreServices/sessionlogoutd, using the identifier type path, with the code requirement identifier "com.apple.sessionlogoutd" and anchor apple

sessionlogoutd is the responsible binary that handles logout hooks, in the same way that loginwindow handles login hooks. Therefore, any logout hook script set here (including the Jamf logout policy process) will have access to anything that TCC allows, if the profile is set as per above.

In the example here, I'm allowing the logout process access to all files, network shares, and removable drives. Essentially to allow a Jamf Pro policy, fired at logout, to sync data to a network drive using rsync.

sudo jamf policy -event "install-vmwarehorizoneclient"

This might work in previous versions of macOS, but definitely DOES NOT work in Monterey.