Just to add to this & food for thought on the nuclear notification blocking approach vs. a focused blocking scheme. Beyond giving end-users a choice, there's an obvious benefit to allowing this new security mechanism to do its job. It's entirely possible for a standard user to install something (say DropBox from Self Service... or worse some random malware) that may only drop an agent into ~/Library/LaunchAgents. If this is the case, it won't be visible from your admin account Sys prefs > General > Login Items. Whether good or bad in your environment, something like this may go unchecked for some time, especially if there's no user warning.
I've noticed that when the Login Items are locked to the user via a config profile if they are an admin they are able to turn items off with an entry of their password upon selection. Seeing this on public beta #22A537b. This is just as bad as not locking the item off. Does anyone else see this and perhaps have a solution?
@jbutler47 This is not my experience. With the profile in place nothing can be toggled on/off, admin or not. If you can toggle ALL items as admin, I suspect your profile isn't properly signed. If it's just a few, you might need to check your xml formatting or maybe try an alternative RuleType for those items.
Upon enrollment with the ServiceManagement profile, I do not see all the individual prompts for all the Login Items that were loaded, which is great. However, there is just one, and perhaps an overall notification that states "Managed Login Items Added - Your organization added items that can run in the background. You can view these in Login Item Settings." This prompt has two options "Snooze for 1 Day" and "Snooze for 1 week". I guess you could take or leave this prompt, but I'd prefer to not have it show up at all at enrollment, seems more like nudging the user to check. I do see the benefit for the end user to be prompted by "Background Items Added" if something else comes into play later on (as mentioned in an earlier post in this thread). Has anyone had any luck with suppressing the "Managed Login Items Added" notification without turning it completely off in case something else is installed later on?
Well, this is cool. Got this from Jamf this morning about the upcoming 10.42 release:
Configuration Profiles for Managed Login Items
Jamf Pro now includes two predefined configuration profiles containing Managed Login Items payloads, installed by default on eligible computers in System Settings > Privacy & Security > Profiles. These configuration profiles prevent end users from disabling certain background services of apps installed by Jamf in System Settings > General Settings > Login Items > Allow in the Background.
Looks like 10.42 will take care of Jamf and App Installer related items for Login Items, but the release notes indicate that you may still need to create or upload a config profile for other apps/services. If I read that wrong, please correct me, but that is what it appears to say.
That looks correct, to me. Jamf App Installers and Jamf software products are allowed by default. Anything above and beyond that requires the use of a custom config for managed app installers (https://docs.jamf.com/technical-articles/Uploading_a_Configuration_Profile_for_Managed_Login_Items.h...)
It's strange why Apple will post that notification. The user can't do anything about it anyway.
It can be closed with this applescript:
tell application "System Events" try set _groups to groups of UI element 1 of scroll area 1 of group 1 of window "Notification Center" of application process "NotificationCenter" repeat with _group in _groups set temp to value of static text 1 of _group log temp if temp contains "Managed Login Items Added" then perform (first action of _group where description is "Close") end if end repeat end try end tell
Well, Apple is Apple, but users can do something if the items are not locked down...they can potentially turn them off/on unless admins lock them down. I'm not sure Apple will totally remove all notifications as they are user-centric.
I don't mind that one as I have all mine locked down and notifications are off for all...
Yes, it's just that as part of our enrollment process we install MS Teams (and a few other tools) and after we log user out (to activate FileVault) they login and land on desktop and this 1 weird notification sticks out.
It's not the end of the world, but it annoys me.
If the user at some later point installs some software and the notification is shown, I don't mind. It makes sense (maybe also for the user) that one action led to the other.
But in our enrollment scenario, this single notification stands out.
I have a similar situation. We have a LaunchDaemon that runs a shell script. I do have a Label in the plist. It is com.company.thingy. I used iMazing Profile Editor to create a config for all my other apps (I used sfltool dumpbtm to get the bundles for them) and they are all locked in but the launch daemon that shows up in Login Items as "sh" is not locked down. I have the entry in the profile as follows:
Label | com.company.thingy | generic comment
I can't figure out why it isn't locked down when the signed profile is installed. Is there something else I'm missing?