This pop-up started 02/06/23 and has been hit or miss with different users reporting it goes away and some stating it shows up every 30mins. What has changed for this to take place?
Question
New Popup "Jamf conditional access" wants to Use "Microsoftonline.com" to Sign-in
+6
+20Maybe try this thread to clear the prompts? Talk to your AD/Azure folks to see if any changes made.
+7From the screenshot, it looks like this is step 3 of user registration for conditional access, which you can read about in Jamf's documentation here.
It looks like an admin configured the conditional access integration, then pushed out a registration policy to trigger the process. From the fact that it repeatedly pops up on some machines, it sounds like it may have been misconfigured either on the JSS or within your Azure tenant. I know the required permission set for the enterprise app object in Azure are changing, so those permissions might need to be updated on your tenant.
+6I know there hasn't been any changes on our JAMF cloud instance. We currently do not have Device Compliance on. And we use the Cloud Connector with Azure for SSO/LDAP group mapping. We do have CA on for cloud apps. However out of 700 machines a grand total of 20 or so all got it at the pop-up yesterday.
We have deployed the Profiles after reading this Troubleshooting Microsoft Azure Login Using JamfAAD - Technical Articles | Jamf
JamfAAD Check-in to recheck for a valid Azure AD toke
JamfAAD to use WebView
Enabling Additional JamfAAD Logging
Awaiting JAMF response after sending logs. Hopefully this is an easy fix
+16It's a really clunky process.
Use the following to report the age of the AAD token:
token_epoch=$(defaults read com.jamf.management.jamfAAD | awk '/"last_aad_token_timestamp"/ { print $NF }' | tr -d '";' | cut -d . -f 1,10) ; token=$(date -r $token_epoch) ; echo $token(Even though JamfAAD had been renamed to Jamf Conditional Access, the domain is still the same as it was)
If the token is older than 3 days (I think?) the user will be prompted to sign in again.
Until MS (and Jamf?) improve the process and user experience, I am just unloading the LaunchAgent.
/bin/launchctl asuser "$LoggedInUID" /usr/bin/sudo -iu "$LoggedInUser" /bin/launchctl unload /Library/LaunchAgents/com.jamf.management.jamfAAD.agent.plist+6It's a really clunky process.
Use the following to report the age of the AAD token:
token_epoch=$(defaults read com.jamf.management.jamfAAD | awk '/"last_aad_token_timestamp"/ { print $NF }' | tr -d '";' | cut -d . -f 1,10) ; token=$(date -r $token_epoch) ; echo $token(Even though JamfAAD had been renamed to Jamf Conditional Access, the domain is still the same as it was)
If the token is older than 3 days (I think?) the user will be prompted to sign in again.
Until MS (and Jamf?) improve the process and user experience, I am just unloading the LaunchAgent.
/bin/launchctl asuser "$LoggedInUID" /usr/bin/sudo -iu "$LoggedInUser" /bin/launchctl unload /Library/LaunchAgents/com.jamf.management.jamfAAD.agent.plistHi @pete_c
We have the same prompt and we believe the reason is due to the device not having internet access immediately so the silent authentication fails and reverts to interactive mode hence the prompt to auth.
Obviously this is far from ideal and the user experience is not great, so my question is what is the impact of removing the launch agent in your previous post?
TIA.
+16Hi @pete_c
We have the same prompt and we believe the reason is due to the device not having internet access immediately so the silent authentication fails and reverts to interactive mode hence the prompt to auth.
Obviously this is far from ideal and the user experience is not great, so my question is what is the impact of removing the launch agent in your previous post?
TIA.
I believe it should prevent this pop-up from happening, but the entire process was so poor that we dropped the project and I haven't spent any further time on it.
+5Hi Everyone,
Has anyone been able to solve this problem somehow? Although I asked both Jamf and Microsoft about this, I could not get a satisfactory answer or solution. Especially the Microsoft side is having a hard time understanding the problem. Is the main source of this problem Jamf Pro? Is it wrong for me to ask the Microsoft side a question? If anyone has found a solution can you please help me? I had to suspend a huge project right now. This pop-up is very annoying.
+6I logged a ticket with support and we believe the reason we are getting prompted is because our devices use 802.1x to authenticate on the network and it takes a few seconds to connect once the device is logged in so silent auth fails and interactive mode kicks in and prompts the user.
I've asked whether its possible to delay the silent auth so the device has connectivity first.
Support email details below:
To give you some background information about the whole process and reference a blogpost created by one of my colleagues, what is happening after registration is the following:
"Once the initial registration is completed jamfAAD continues to run in the background and has to authenticate every 24 hours to Azure to confirm the Azure AD record is still intact and confirm the AAD Device ID. Why? Well, because it has to report it to JPRO as proof of the integrity of the registration, and the activity of the device.
This is why we have the WPJ key and cached credentials. jamfAAD actually authenticates silently to Azure and uses the items in the keychain to do so. As long as the WPJ key is ok, the Azure AD record is intact, the device is online (to contact Azure), the cached password is valid…. all is well. jamfAAD silently authenticates, gets the Device ID, reports it to JPRO, JPRO sends inventory data to Intune… everyone happy. (Quick note: JPRO only sends an inventory update to MEM when something changed..)
However, whenever this silent authentications fails, for whatever reason, jamfAAD will go into interactive mode and prompt the end user to authenticate again! This is 100% normal and expected behaviour. Furthermore, there are other situations where Azure may even instruct jamfAAD to go in interactive mode, such as an expired MFA lifetime."
I will be listing couple of reasons below why the users can be prompted by this pop-up:
- Device offline for more than 24h
- Azure AD password changed (hence cached credentials are invalid)
- End user created multiple Azure AD records by registering the device multiple times
- MFA is being triggered because of the MFA token lifetime expired
- Keychain issue (corrupted or user did not select always allow when registering…)
+5I logged a ticket with support and we believe the reason we are getting prompted is because our devices use 802.1x to authenticate on the network and it takes a few seconds to connect once the device is logged in so silent auth fails and interactive mode kicks in and prompts the user.
I've asked whether its possible to delay the silent auth so the device has connectivity first.
Support email details below:
To give you some background information about the whole process and reference a blogpost created by one of my colleagues, what is happening after registration is the following:
"Once the initial registration is completed jamfAAD continues to run in the background and has to authenticate every 24 hours to Azure to confirm the Azure AD record is still intact and confirm the AAD Device ID. Why? Well, because it has to report it to JPRO as proof of the integrity of the registration, and the activity of the device.
This is why we have the WPJ key and cached credentials. jamfAAD actually authenticates silently to Azure and uses the items in the keychain to do so. As long as the WPJ key is ok, the Azure AD record is intact, the device is online (to contact Azure), the cached password is valid…. all is well. jamfAAD silently authenticates, gets the Device ID, reports it to JPRO, JPRO sends inventory data to Intune… everyone happy. (Quick note: JPRO only sends an inventory update to MEM when something changed..)
However, whenever this silent authentications fails, for whatever reason, jamfAAD will go into interactive mode and prompt the end user to authenticate again! This is 100% normal and expected behaviour. Furthermore, there are other situations where Azure may even instruct jamfAAD to go in interactive mode, such as an expired MFA lifetime."
I will be listing couple of reasons below why the users can be prompted by this pop-up:
- Device offline for more than 24h
- Azure AD password changed (hence cached credentials are invalid)
- End user created multiple Azure AD records by registering the device multiple times
- MFA is being triggered because of the MFA token lifetime expired
- Keychain issue (corrupted or user did not select always allow when registering…)
Hi,
Honestly, what you're saying makes a lot of sense. Yes! As you said, 802.1x is used in our environment.
Frankly, the most uncertain and difficult experience I had with Jamf Pro was enrolling devices managed with Jamf Pro to Intune via Company Portal.
In order to analyze some issues correctly, it is necessary to know the working logic of the application well. Thank you for explaining that too.
I'm currently considering using Webkit to prevent these popups from popping up constantly. I hope it works.
+6Hi Everyone,
Has anyone been able to solve this problem somehow? Although I asked both Jamf and Microsoft about this, I could not get a satisfactory answer or solution. Especially the Microsoft side is having a hard time understanding the problem. Is the main source of this problem Jamf Pro? Is it wrong for me to ask the Microsoft side a question? If anyone has found a solution can you please help me? I had to suspend a huge project right now. This pop-up is very annoying.
Following theTroubleshooting Microsoft Azure Login Using JamfAAD - Technical Articles | Jamf We haven't seen this issues since. - My suggestion would be to implement these config Profiles. The ability to recheck- solves the timeout issue. Or switching networks.
+5Hi,
I solved this problem.
Thanks...
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.