We only have about 25 admins out of over 800 users so the possiblity is very small. I watch the hell out of them and tighten the rope when they get out of line, which doesn't happen often. We can lock a machine as a last resort for compliance which we have only done once in over two years.
I just want to point out that a non-admin may still be able to disable certain LaunchAgents critical to management (at least in my testing), just be sure to test toggle all items in your environment if it's a concern to you.
Also, thanks @A-bomb for your notification suppression config! I've decided to double down and employ it along with our login & background item management profile.
What I posted disables all of the new login and background items added notifications in Ventura. I don’t see the point of having those in our environment. What others have posted here is for specific login or background items. Application path is not recommended and never worked for us. Only using bundle ID did. It can be kind of a pain in the ass to get the bundle ID but once you get it and use it, you can forget about it..
Agreed, Bundle IDs are a nuisance. This is how I derive mine. You can either derive it from the app's Info.plist, using the commands below (location may vary, but should be in the *.app contents):
/usr/libexec/PlistBuddy -c 'print CFBundleIdentifier' /Applications/<application>.app/Contents/Info.plist
or, sometimes in the codesign output, where you can also find the TeamIdentifier:
codesign -dr - /path/to/Application.app
(Commands in green, BundleIDs in yellow, TeamIdentifiers in red)
My current process order looks like this:
codesign -dr - /path/to/Application.app
/usr/libexec/PlistBuddy -c 'print CFBundleIdentifier' /Applications/FortiClient.app/Contents/Info.plist
5. Upload the configuration into Jamf
I just did some testing on my MBA M1 running macOS 13 b11. Approving Login/Background Items does not suppress the notifications. Two separate Configuration Profiles are needed to achieve both. I was able to repeat this a few times too. I haven't seen “your organization is managing login items” either.
I used "sudo sfltool dumpbtm" to find all the Labels and Executable path´s I needed to block
I found then issues of the non-blocked items. I missed some custom LaunchDaemons / Agents Labels
And I was able to shut down Jamf Connect as a standard user until I added a new Label with "com.jamf.connect" in the profile.
The same was done for "uninstall" and "install_monitor" so now my panel is locked for all items I need to lock.
I'm sorry, I'm having a hard time understanding - can you clarify how you got "uninstall" and "install_monitor" locked? Those are the last two that I've been having trouble with. I can't seem to find a way to put them into a profile. Did you just use the path to them? If so, is that considered a label, or something else? (I'm using iMazing Profile Editor). Thank you!
Sorry about the unclear answer here above :)
I solved it by adding two more items in the com.apple.servicemanagement payload
Even if Microsoft is added as a TeamID in my profile that does not lock down some of their LaunchDaemons / Agents
Add a Rule Type with value Label and Rule Value of com.microsoft.dlp.install_monitor
Add another Label with Rule Value of com.microsoft.fresno.uninstall
If you have other binaries still unlocked press the information-i next to the lock-switch and you can find the binary used and look for the LaunchDaemons / Agents using that binary (path to binary). When you found the correct Daemon or Agent copy the value for the key <key>Label</key> and put that in a new row in the profile.
Hope that is more clear otherwise just write again.
So been making good progress in preventing users from disabling login items but I got one that still tricky. Looks like in Ventura there is a "StartupScript.sh" located in the /Library/Application Support/JAMF/ManagementFrameworkScripts/ folder. Seems like a simple script to ensure everything is working. So would rather not have the user disable it as login item. Anyone have success in doing that?
Btw, iMazing Profile Editor rocks!
I've created the Service Management - Managed Login Items profile and uploaded to JAMF. On my test machine it works as far as locking the on/off sliders in login items, but the notifications still appear on every reboot. Am I missing something? I was under the impression that this profile would stop the notifications also?
There are a few options for notification suppression. A-Bomb's is great for discrete suppression of notifications on apps. You can take a more nuclear approach and block com.apple.btmnotifications, which is the object that manages login item notifications: Background Task Management Notifications. You can also use the Notifications Preference Control and adjust to taste. For example:
Note that I'm not targeting this against any devices unless it becomes an issue. Generally speaking, I want users to be notified to make a choice when a login item is added; we're also enforcing a large amount of organizational apps, so for anything beyond our approved software I want users to be able to make that choice.