"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

92 REPLIES 92

Baravis
New Contributor III

Sweet, thanks @A-bomb!  Did you build that yourself?  Or is it available in the Appleseed Downloads or some other place?

A-bomb
New Contributor III

I found it somewhere a long time ago. bill@talkingmoose.net built it. The credit is in the code. You can just copy the code above from the first { to the last }

Baravis
New Contributor III

Oh I see it there.  Well thanks, Bill.  I did copy it, and it's working great, thanks a million. :)

How are you deploying your com.apple.servicemanagement profile?  I'm thinking I can just use Applications & Custom Settings -> Upload

A-bomb
New Contributor III

I'm actually not using com.apple.servicemanagement at all. Just the one I posted.

Baravis
New Contributor III

Ah, gotcha!  You’re not concerned that users will just unmanage themselves by turning off the Jamf launch agent?

A-bomb
New Contributor III

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.

Baravis
New Contributor III

Oh cool.  Every org is just a bit different, hey?  Well, just wanted to check. :D  Thanks a ton for the content.

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.

A-bomb
New Contributor III

Thanks for the heads up. I admit not testing every one but will today. Glad you are having success with the suppression. I have been considering both as well. 

A-bomb
New Contributor III

Screenshot 2022-10-13 at 10.05.53 AM.pngScreenshot 2022-10-13 at 10.05.57 AM.pngOnly Jamf Software (2 items) can be toggled off without admin. Thank God. I am going to work on whitelisting those as detailed on this thread. Thanks again.

No problem!  Yeah, going out on a limb here, you might not want a standard user willy nilly disabling anything Jamf haha! 😉  fwiw, a couple I ran into were from Outset, Munki, and Zoom.

 

seido01
New Contributor

@A-bomb - Do you know whether it's possible to disable these notifications by application path rather that bundle ID?

A-bomb
New Contributor III

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

 

Baravis
New Contributor III

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

 

Example:

(Commands in green, BundleIDs in yellow, TeamIdentifiers in red)

Baravis_0-1665688635930.png

 

Thank you, this worked as I'd already added the custom Schema from here: https://www.alansiu.net/2021/01/13/managing-macos-notification-center-settings-using-a-jamf-profile/

allanp81
Valued Contributor

I was wondering the same, I don't think it does based on what the docs say.

Baravis
New Contributor III

My current process order looks like this: 

Profile Creation
  1. Create and install a Jamf self-signed certificate: https://docs.jamf.com/technical-articles/Creating_a_Signing_Certificate_Using_Jamf_[…]CA_to_Use_for_...
    1. Note: It's necessary to sign the configuration profile that you create because Jamf 10.41 does not yet have a a Policy item for com.apple.servicemanagement.  Uploading a signed configuration profile pushes out valid configuration items, but Jamf is basically just being used as a dumb push service at this point, because it can't interpret that item properly
  2. Download and install iMazing Profile Editor
  3. Upload sample configs into iMazing Profile Editor or craft your own using the Service Management - Managed Login Item
  4. iMazing Profile Editor config profile creation
        1. adjust the "General" tab with your organizational details (note: these will be static, as you are uploading a signed profile into Jamf; ie: you will not be able to alter config profile details after upload, so each time you make a change to this profile you do it in iMazing, and upload the signed profile to Jamf)
          1. Identifier (you can derive a unique one by creating a new profile in iMazing, use that in this and subsequent versions of this profile)
          2. Profile Signing: select the self-signed cert you created in step 1
        2. Set up "Service Management - Managed login items" configured domain
        3. Rule type and rule value for a given app can be referenced in the AppleSeed for IT documents (downloads, background configuration items), and derived using terminal.  I recommend using LabelPrefix (if available) for com.objects (e.g. com.jamf or com.jamfsoftware) and TeamIdentifier:

 

 

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'm scoping my configuration profile to all macOS Ventura machines.  If you scope to current machines it gets installed (if you were wanting to preload), however the profile won't reload its settings when the Ventura install completes and you won't see the benefits of the config.
 
Instead, consider installing the config between the time a device updates from macOS 11/12 to macOS 13, and when a user logs in.  To accomplish this, I created a policy that runs Inventory at startup on all devices.

A-bomb
New Contributor III

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

Baravis
New Contributor III

You're looking for my launch agent enforcement code, specifically?  I think it's under NDA, but if you're on Slack I can send you a copy?

 

 

A-bomb
New Contributor III

That would be sweet @A-bomb

A-bomb
New Contributor III

Look at this beauty. Thanks again for your help @Baravis Screenshot 2022-10-13 at 4.54.32 PM.pngScreenshot 2022-10-13 at 4.54.48 PM.png

auser
New Contributor III

Do you find that the notifications for these background items suppress also? 

Baravis
New Contributor III

I do find that, yes.  Supposedly I should be seeing a “your organization is managing login items” pop-up, also, but I’ve yet to see that either.

A-bomb
New Contributor III

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.

Baravis
New Contributor III

I’ll have to recheck my Apple Silicon test unit then, thanks for the heads up!

auser
New Contributor III

Hmmm. I thought that was how it functioned in the beginning. Maybe a bug in the beta. What are you deploying for the notifications? 

Baravis
New Contributor III

At present, nothing.  Notifications haven’t been popping up in my tests with the login item enforcement configuration profile in place.  I have to double check my tests, but I’ve been seeing 0 notifications on my Intel device.

A-bomb
New Contributor III

They weren't popping up but rather sitting in Notification Center. When I applied the allow profile we worked on yesterday they stayed in there but when I applied the notification mute I posted here they immediately disappeared.

Hello @A-bomb , 
How did you manage to get "uninstall" and "install_monitor" disabled. I also have "bash",  "killall" and "Jamf Connect" showing as toggable. All scripts and applications with TeamID´s are disabled on my test-system but still have some unix-binaries showing as toggable. 


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!

Hello, 
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.

(edit spelling)

Thank you so much for the quick and thorough reply!  I'm going to try your method first thing tomorrow morning when I'm back in the office. 

roiegat
Contributor III

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!

skeenan07
New Contributor III

Try adding com.jamfsoftware.startupItem as a label or com.jamfsoftware as a label prefix. 

That did the trick!  Thanks!

A-bomb
New Contributor III

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

PablitoGordito
New Contributor

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?

This thread has two things going on. Locking them like you are referring to and suppressing notifications like I posted about with screenshots and schema. Can you post your XML and domain here?

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: 

Baravis_0-1665682890779.png

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.