Okta IDP login window not showing after 12.4 update?

[lopezzi]

Is anyone else using Okta for their IDP, not seeing the username/passwords field load after updating to 12.4 from 12.3.1? I am new to Jamf, so forgive me if I don't understand something at first, but I will do my best to provide whatever help/answers I can.  Here's what's going on:

I've had two Intel 2015 13" MBP that I have Jamf Connect installed on and running fine on Monterey 12.3.1.  After updating to 12.4, they both now just display our custom background we have set for JC, but that's it.  No username/password field.  No restart/shutdown buttons.  No Wifi/keyboard buttons at the top.  Literally just a background image and that's it.

On one of the machines, I ssh'd into it and ran the authchanger to reset back to default, rebooted and it displayed the normal macOS login screen as expected.  ssh'd agan and ran authchanger to put it back to JC, rebooted and then the login stuff came back.  My other machine, I haven't done anything to yet in hopes of finding a solution, so it's still on just a blank JC screen with our background and that's it.  I did pull a 

tail -r /private/tmp/jamf_login.log

on it to see what was happening but I couldn't really tell if there was a problem.  It didn't look like it to me, but maybe someone who knows more could take a look and see what they think?  This was right after a reboot:

Wed May 18 15:32:45 [com.jamf.connect.login] - Debug - LoginUI: Updating the network list view. 
Wed May 18 15:32:45 [com.jamf.connect.login] - Debug - LoginUI: Dispatching the new network list to the delegate 
Wed May 18 15:32:45 [com.jamf.connect.login] - Debug - LoginUI: Network list changed. 
Wed May 18 15:32:42 [com.jamf.connect.login] - Info - LoginUI: LoginUI mech run complete. 
Wed May 18 15:32:42 [com.jamf.connect.login] - Debug - LoginUI: Activating application. 
Wed May 18 15:32:42 [com.jamf.connect.login] - Info - LoginUI: Forcing login window activation at mech init. 
Wed May 18 15:32:42 [com.jamf.connect.login] - Debug - LoginUI: Starting network list refresh timer. 
Wed May 18 15:32:42 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: AllowNetworkSelection 
Wed May 18 15:32:42 [com.jamf.connect.login] - Info - LoginUI: Main container will clip: false 
Wed May 18 15:32:42 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: OIDCProvider 
Wed May 18 15:32:42 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: HelpURL 
Wed May 18 15:32:42 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: OIDCProvider 
Wed May 18 15:32:42 [com.jamf.connect.login] - Info - LoginUI: Setting custom logo. 
Wed May 18 15:32:42 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: LoginLogo 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - Common: Will present welcome message 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: LoginWindowMessage 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - AuthUI: Okta provider setup ended with success. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: AuthServer 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - AuthUI: Okta provider setup. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: OIDCProvider 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - LoginUI: Sentry has started. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - LoginUI: Debug starting SentrySDK. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - LoginUI: Configuring main login window. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - LoginUI: Setting observer for NSWindow notifications 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - LoginUI: Setting observer for screensaver 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - Common: Setting global progress bar visible: false 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - LoginUI: Running Login authorization UI. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - LoginUI: Autologin is disabled, deny local is true or not the first run. Running Login UI. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: DenyLocal 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - LoginUI: LoginUI starts. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - LoginSwiftMech: Initializing LoginUI mechanism. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - LoginSwiftMech: Allowing login 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - Common: Finishing Initialize mech. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - Common: Setting global progress bar visible: true 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - UI: <li-emoji id="lia_desktop-computer" title=":desktop_computer:"></li-emoji> New background window <NSWindow: 0x7f88537424b0> setup finished on screen <NSScreen: 0x7f8854021700> 0AA6E386-CE2C-5EE2-CC95-F2B67DCDF861 
Wed May 18 15:32:41 [com.jamf.connect.login] - Info - UI: BackgroundImage preferences found. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - AuthUI: Centering window to full extent. 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - AuthUI: window final frame (0.0, -428.0, 1280.0, 800.0) 
Wed May 18 15:32:41 [com.jamf.connect.login] - Debug - AuthUI: center point is (0.0, 0.0) 
Wed May 18 15:32:40 [com.jamf.connect.login] - Debug - Settings: Found managed preference in com.jamf.connect.login: BackgroundImage 
Wed May 18 15:32:39 [com.jamf.connect.login] - Info - Common: Starting Initialize mech. 
Wed May 18 15:32:38 [com.jamf.connect.login] - Info - LoginSwiftMech: Initializing Initialize mechanism.

Is this happening to anyone else using Okta as their IDP?  Anything else I can check?

[andrew_nicholas]

Azure is our IDP and while we dont see this since we dont use the JC login window, we do use the EULA feature and are seeing an issue where devices fail to fully complete the update because they get stuck at a black screen with cursor. Scoping a policy to reset the authchanger or remove JC followed by a reboot brings things back to normal.

[lopezzi]

What is your trigger for running the policy?  And do you change the authchanger back to JC after you remove it?

[andrew_nicholas]

Just a run once policy with reoccurring checkin we can add affected devices too. Our automated polices reinstall JC shortly there after and reset to our current method using the 

/usr/local/bin/authchanger -reset -postAuth JamfConnectLogin:EULA

[lopezzi]

Ok thank you!  This seems to be the common theme is to either remove JC or run the authchanger anytime there is an update to the OS.  Would be nice if JC just didn't break lol.  Thanks for your suggestion, I may end up just doing something similar.  Appreciate the help!

[naschenbrenner]

To add on to this, we have a similar policy that runs in tandem with an extension attribute we have that checks what the login window is set to. We used to use NoMAD, but for your purposes you can leave it out.

The EA is:

#!/bin/bash


loginwindow=$(/Library/Security/SecurityAgentPlugins/JamfConnectLogin.bundle/Contents/MacOS/authchanger -print)

if echo "$loginwindow" | grep -q "JamfConnectLogin:LoginUI"
then
	status="Jamf Connect Login Window"
elif echo "$loginwindow" | grep -q "JamfConnectLogin:DeMobilize,privileged"
then
	status="Jamf Connect Demobilization Process"
elif echo "$loginwindow" | grep -q "NoMADLoginAD:CreateUser,privileged"
then
	status="NoMADLoginAD"
else
	status="macOS Login Window"
fi

echo "<result>$status</result>"

Our Policy is then used to reset the authchanger db for any computers in our smart group that echo "macOS Login Window". We have this Policy set to ongoing for each check-in and we run a recon as well at the end so the the EA gets updated.

[lopezzi]

I actually have this (or something very similar to this) set up as well so that if an OS update resets the login to the OS (like 12.3 did) then it will go into the smart group that auto changes it back to JC.  Seems to work well, but in this case, it's still set to JC so it never goes into the smart group.

[naschenbrenner]

Can you ssh to a computer that's affected and run

log show --style compact --predicate 'subsystem == "com.jamf.connect.login"' --debug > ~/Desktop/JamfConnect.log

 and post the output? 

[lopezzi]

Here's the output:

Timestamp               Ty Process[PID:TID]
2022-05-09 11:06:46.459 E  authorizationhosthelper.x86_64[1790:31ce] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.
2022-05-09 15:01:32.512 E  authorizationhosthelper.x86_64[961:28f3] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.
2022-05-10 10:34:36.535 E  authorizationhosthelper.x86_64[9757:3e604] [com.jamf.connect.login:KeychainAdd] Unable to create item. Error: Optional(The specified item already exists in the keychain.)
2022-05-10 10:34:36.548 E  authorizationhosthelper.x86_64[9757:3e604] [com.jamf.connect.login:KeychainAdd] Unable to create new keychain item. Error: Optional(The specified item already exists in the keychain.)
2022-05-18 11:32:34.590 E  authorizationhosthelper.x86_64[1041:18d4] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.
2022-05-18 15:32:02.024 E  SecurityAgentHelper-x86_64[382:99e] [com.jamf.connect.login:LoginUI] Couldn’t communicate with a helper application.

I'm guessing the "Couldn't communicate with a helper application" may have something to do with it. 

[lopezzi]

So I posted the output, but looks like the system removed it cause it thought it was spam?  I'll try again.  If it removes it again, I guess I'll have to try something different?

[naschenbrenner]

Are you trying to add the whole file? You could just copy and paste it I suppose

[lopezzi]

No, I'm just trying to post the output code in a code block.  No idea why it keeps thinkging it's spam.  I'll try again.  Maybe not in a code block?

[lopezzi]

Here's the output from the command again.  Hopefully the system doesn't mark it as spam again.

Timestamp               Ty Process[PID:TID]
2022-05-09 11:06:46.459 E  authorizationhosthelper.x86_64[1790:31ce] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.
2022-05-09 15:01:32.512 E  authorizationhosthelper.x86_64[961:28f3] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.
2022-05-10 10:34:36.535 E  authorizationhosthelper.x86_64[9757:3e604] [com.jamf.connect.login:KeychainAdd] Unable to create item. Error: Optional(The specified item already exists in the keychain.)
2022-05-10 10:34:36.548 E  authorizationhosthelper.x86_64[9757:3e604] [com.jamf.connect.login:KeychainAdd] Unable to create new keychain item. Error: Optional(The specified item already exists in the keychain.)
2022-05-18 11:32:34.590 E  authorizationhosthelper.x86_64[1041:18d4] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.
2022-05-18 15:32:02.024 E  SecurityAgentHelper-x86_64[382:99e] [com.jamf.connect.login:LoginUI] Couldn’t communicate with a helper application.

I'm guessing that last line, "Couldn't communicate with a helper application" could be the culpruit? 

[lopezzi]

2022-05-09 11:06:46.459 E  authorizationhosthelper.x86_64[1790:31ce] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.

2022-05-09 15:01:32.512 E  authorizationhosthelper.x86_64[961:28f3] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.

2022-05-10 10:34:36.535 E  authorizationhosthelper.x86_64[9757:3e604] [com.jamf.connect.login:KeychainAdd] Unable to create item. Error: Optional(The specified item already exists in the keychain.)

2022-05-10 10:34:36.548 E  authorizationhosthelper.x86_64[9757:3e604] [com.jamf.connect.login:KeychainAdd] Unable to create new keychain item. Error: Optional(The specified item already exists in the keychain.)

2022-05-18 11:32:34.590 E  authorizationhosthelper.x86_64[1041:18d4] [com.jamf.connect.login:KeychainAdd] Tried to get the login name but couldn't find it.

2022-05-18 15:32:02.024 E  SecurityAgentHelper-x86_64[382:99e] [com.jamf.connect.login:LoginUI] Couldn’t communicate with a helper application.

I'm guessing that last line may be the culpruit?

[lopezzi]

Ugh, it will not accept me posting the output, whether it's in a code block or not, it keeps removing it.  I took a pic of the output, maybe that will help?

I'm guessing the last line could be the culpruit?

[naschenbrenner]

I'd imagine so, however I haven't ever seen that error before. Hopefully resting authchanger can help, otherwise you may need to completely remove Jamf Connect, reset the authchanger db to the macOS login screen and go through the installation process again.

[lopezzi]

Yeah ok, thanks for your help.  I did just do an authchanger reset to the OS window, rebooted, then authchanger reset back to JC and it seems to work, but still curious why it breaks in the first place.  At least we have a workaround in the meantime.  Maybe I can submit a ticket to Jamf and see what they say.  Again, appreciate all the help!

[naschenbrenner]

No problem, welcome to Jamf Admin life :P