JAMF Connect gone after macOS 12.3 upgrade

Ran into this after the update

Thanks for this post!  I just had this issue with the most recent 12.3 update. Getting a policy set up with this command resolved the issue.

How did you do that? I have updated the configuration, and pushed out, but nothing has changed.

• Create a a new policy and scope it to the impacted devices 
• As mentioned above in the policy payload under ‘files and processes’ add the command /usr/local/bin/authchanger -reset -jamfconnect

I love this community 🥰

hello, i have tried the above and i got the following error: 
Result of command:
LLVM Profile Error: Failed to write file "default.profraw": Read-only file system

What can i do to fix it ?

Are you sure you made the policy like showing below?

I'm getting the same error on some machines: "LLVM Profile Error: Failed to write file "default.profraw": Read-only file system"

It is successful on some but not others.  Can't nail down why.  Same OS and same hardware on both. 

yes, but the error persists. 

It is a XCODE issue, and can you try to delete or reinstall it?

We do not have XCode installed at all, but still experience this error.

We do not have XCODE at all 

Anyone else have insight on this error?

Applied the policy but getting the "LLVM Profile Error: Failed to write file "default.profraw": Read-only file system" error

I experienced this error after the 12.3 update too and even after the tiny 12.3.1 update as well. If Jamf requires us to push a policy to every Mac after every update this could be problematic in my organization as there are scenarios in which some Macs could be "stranded" without any way for users to log into their Macs (specifically laptops).

If you have the policy cached on the device it could run regardless of connection.  What I am stumped on is how to even figure out if a machine needs this run against it and then how to scope a policy for it. 

That's what I mean - there are several potential gotchas here that take some babysitting. Plus the Mac has to be available to get the policy cached in the first place. 

Actually, I have had to run a couple of commands to fix this on my test Macs:

Run /usr/local/bin/authchanger -reset
Reboot
Run /usr/local/bin/authchanger -reset -JamfConnect

Running /usr/local/bin/authchanger -reset -JamfConnect doesn't fix anything. I have to blow out the authdb settings to defaults (which returns the Apple OEM login window UI) and THEN run it again to set it to Jamf Connect.

We are currently MS Azure/ADFS hybrid here.

We are currently testing JC - it's not in production yet. But this is one caveat that I am putting in the "Cons" column.

I have an attribute to see if the login window is the mac default or JAMF Connect.  I use this to make sure these things don't happen and then have a smart group that is on my dashboard.  To automate this just need to do an ongoing policy for that smart group. Once an inventory and policy are run then the next login the user will be back using the JAMF Connect login.  Of course, if you have exceptions you would want them excluded from that group.  
Here's the code I use: 

Hey that's pretty handy @tculkin  Thanks.

Just curious: Do you find that a reboot is required to pop the auth back to Jamf Connect or is it dynamic? I have notcied many times in my testing (as stated earlier) that I sometimes have to...

Run /usr/local/bin/authchanger -reset
Reboot
Run /usr/local/bin/authchanger -reset -JamfConnect

...otherwise the Mac has no login window UI whatsoever. Running /usr/local/bin/authchanger -reset -JamfConnect one time by itself doesnt work. And I have to perform this step after EVERY macOS update, regardlesss of the size or version. Example: macOS 11 to macOS 12 (obviously), but also updating from 12.2 to 12.3, and even updating from 12.3 to 12.3.1 all required me to reset the authdb before the Mac would allow anyone to login. Definitely not "robust" in my experience thus far.

That's strange. I have not had this issue.  I have policy that runs automatic on the group that doesn't have the JC Login.  That policy just has /usr/local/bin/authchanger -reset -JamfConnect and the maintince of updating Inventory.  I find the Inventory needs to be updated for them to fall out of that group.  Once they are in the group just means next time they reboot they will get the JAMF login, it doesn't mean they are logged in with JAMF.
I have another Smart group that lets me know if they logged in with through Okta or the local authentication.  This way I can tell if there is an issue with JAMF Conect. 

How did you create the smart group for the Okta login?

Thank you so much for this. I was testing updating my environment from 12.2.1 to 12.3.1. Of course I did my machine first and was not presented with Azure AD Log in this morning. I created the extension attributes as well as smart groups and the policy. Worked like a charm. Thank you again.

How are you creating the smart group for the kind of login a user does? Can you post a screenshot of the logic/config for the smart group? Also, what config profile?

Yes. I created the extension attribute then created 2 smart groups. "Jamf Connect Log In Window is False/True"

I am still in testing so I made a 3rd smart group that includes the test group AND falls in the Mac OS Log in false.

I want to avoid our Mac users encounter this event when they update their computer at any time. I was thinking of having the policy running all the time so in the event of a user updating their Mac they do not get this problem. What do you guys recommend for the "Trigger" and "Execution Frequency" for the Authchanger policy mentioned in the "Travelling Tech Guy" link below

https://travellingtechguy.blog/re-enable-jamf-connect-login-window-after-major-macos-upgrade-monterey/

Would you be able to show how you set up your Extension Attribute for this? Thanks!