Skip to main content

Hi,

This is more of a preventive post and a sort of a horror story on how Jamf Connect was accidentally pushed in our environment while it is still in testing phases with nobody from STAFF even expecting it... With new Jamf Pro JSS server - Jamf Connect can be updated/DEPLOYED directly from JSS global settings area, which we have learned the hard way. In my initial opinion this was only a maintenance/update feature, not an actual push to every mac and while afterwards I saw "for an initial deployment" in little grey letters - it should be in BIG RED LETTERS! 

 

If anybody runs into a similar problem:

1) Immediately switch Jamf Connect Version/Update Type to "None"

2) Create a smart group which will check for Application Title: "Jamf Connect.app"

3) Flush/Trigger Inventory Update policy on JSS to register all the macs which already received Jamf Connect ASAP

4) Create a policy with every available trigger so it gets to every mac ASAP scoped to the Jamf Connect app present smart group and here is the script I have used, which worked very well, the impact we are seeing is minimal to what it could have been:

 

 

#!/bin/bash

/usr/local/bin/authchanger -reset

sleep 2

rm /usr/local/bin/authchanger
rm /usr/local/lib/pam/pam_saml.so.2
rm -r /Library/Security/SecurityAgentPlugins/JamfConnectLogin.bundle

sleep 1

killall "Jamf Connect"
rm -r "/Applications/Jamf Connect.app"

sleep 1

rm -r /Library/Preferences/com.jamf.connect.login.plist
rm -r ~/Library/Preferences/com.jamf.connect.login.plist

 

 

5) In case the user will never log out/reboot - they won't see a thing, if they do and will get to the Jamf Connect login prompt, once the policy is pushed to their mac - the Jamf Connect login prompt will disappear and they should see the regular mac login screen, worse case scenario where Jamf Connect login is not going away - add their account to the idP so they can login/authenticate thru Jamf Connect and work, then work towards pushing this policy on their mac as even after you login via Jamf Connect and it's removed afterwards - at next reboot it should be gone and the user should be able to login as usual.

@akamenev47 Great post and almost had this happen to us!!  We thankfully had only pushed out the license key to all users on the computers and then discovered that somehow Jamf Connect went along with that using that setting.  We've now been advised by Jamf Support to really not use this unless you fully understand what it can do.  We've since gone back to a standard policy to launch and deploy Jamf Connect.  If we hadn't broken up our Jamf Connect Configuration Profiles as we had we'd have had 1,000+ machines get this and no notice to users about what it even was.

I really feel this part of Jamf Pro should be explained a lot more before support or others encourage folks to use it.  I know for Jamf Protect its amazing and the best way to get that product out but otherwise been warned to not use this for other apps.

Glad you mentioned this. Thanks!

This did happen to us as we had the auto-update linked to one of our JC config profiles and when the profile got changed to all computers from targeted groups it started deploying JC. We were in a hybrid state at the time where half the macs had JC from new zero touch deployments but the olde ones didn't. What we found however was many users got locked out of their macs with neither the existing local password or the IdP password working for some reason (Jamf Support couldn't explain it either). It was then difficult to separate who had just got it from who already had it for remedial actions. 

Could somebody please take a screenshot of the "configure jamf connect deployment and update settings for computers in scope" settings? I believe JAMF added a nice red-colored warning as we requested! :)

Reply


Terms & ConditionsCookie settings