"Login items added" in Ventura

PhillyPhoto
Contributor III

Please tell me we're going to be able to suppress these and a million notifications aren't the future for end users:

Screenshot 2022-07-26 at 20.47.17.png

103 REPLIES 103

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.

Can you post your code here? I can't get this to work.

jbutler47
Contributor

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?

 

A-bomb
New Contributor III

This solves it...

Baravis
My current process order looks like this:
Profile Creation

@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.

Baravis
New Contributor III

Concurring with @jonw here, I haven’t been receiving notifications.  In some cases I used both a team identifier and a label prefix.

jbutler47
Contributor

@jonw Thank you for reminding me to sign the profile. Works like a charm now. Going to test and verify again if the notifications appear during enrollment.  Let's just say that iMazing Profile Editor is a great help for this concern. 

 

jbutler47
Contributor

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? 

I find that @Baravis's solution with the image in this thread did a great job.  No notification popped up at all for the login items during the build.  

A-bomb
New Contributor III

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.

jbutler47
Contributor

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. 

 

Baravis
New Contributor III

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...)

Fluffy
Contributor III

For those less experienced in digging for Team Identifiers, Labels, etc., this page helped me out a lot:

https://hammen.medium.com/managing-login-items-for-macos-ventura-e78d627f88b6

michael_madsen
New Contributor III

Is anyone else ending up with this notification instead?

Screenshot 2022-12-12 at 20.32.55.png

Yep.  Just the one... 👍

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 get it.  I wish Apple would be user-centric, but when we're using Apple in the enterprise or EDU, let us manage them as we are tasked to do.  They still don't seem to get it, and likely never will.

They keep claiming Apple is Enterprise Centric, but alas, not so much.  

Shaun
New Contributor II

Is there any way whatsoever to block a notification like this for a .sh script? Presumably those don't have a Bundle ID (if they do I can't figure out how to find it) and this only applies to full blown .app applications?

sdagley
Honored Contributor III

@Shaun Make sure the LaunchDaemon calling your .sh script has a Label entry in the .plist, and use that name in a Label rule in your Service Management - Managed Login Items payload.

AVmcclint
Honored Contributor

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?

AVmcclint
Honored Contributor

Nevermind... I figured it out. I had text in the Team Identifier field. When I removed that extra text and re-applied the profile, it now works.