Frequent/Errant 'Reconnect to your Organization' Dialog

[LibertyDev18]

Describe the bug: When launching an app that has not been accessed in a couple of days the user is immediately presented with the "Checking you organization's data access requirements for this app" screen for about 30 seconds and is then presented with the "Reconnect to your Organization" dialog.

If the user taps 'Sign in' they will be bounced over to Authenticator and asked to enter their enterprise password for the account and access is restored.

If the user taps 'Close Application' the app is quit and launching again allows them to access the app as expected WITHOUT being prompted to enter enterprise credentials again.

We have an entire suite of apps that are still using Intune SDK 15.4.0 and these apps launch and refresh tokens as expected without being prompted to reconnect to the organization through interactive auth.

Being that tapping 'Close Application' seems to clear this, and that this behavior does not surface on the same device with 15.4.0 apps, leads us to believe that this is a bug and is significantly impacting the user experience of the app as users are following the dialog prompt to 'Sign in' and repeatadly having to interactively re-auth.

To Reproduce Steps to reproduce the behavior:

1. Successfully authenticate and manage app with Intune SDK 17.0.0
2. Put the app into the background for a couple days
3. Launch app
4. User is presented with dialog to "Reconnect to your Organization"

Expected behavior: Similar to how apps using Intune SDK 15.4.0, the app should be able to still successfully refresh access tokens after a couple of days of inactivity without forcing the user to manually reconnect to the organization by entering their enterprise credentials.

Smartphone (please complete the following information):

• Device: All iOS Devices (iPad & iPhone)
• OS: 15.7

Intune App SDK for iOS (please complete the following information):

• Intune SDK 17.0.0
• Native iOS development

Additional context: In a couple of cases when bringing the app to the foreground it looked like the "Reconnect to your Organization" dialog was already presented in the background which gave way to the "Checking your organization..." screen to then re-present the dialog to reconnect.

[Kyle-Reis]

Hi @LibertyDev18, what you are seeing is an intended change in the way that the offline grace period "block access" action policy is enforced, beginning in version 16.1.1 of the Intune SDK. For clarity, I'm referring to the 2nd policy setting in this list:

Prior to this change, policy enforcement was based solely on whether the device was internet connected, and the timer would only begin after the app was first launched while the device was not connected to the internet.

After the change, the "block access" policy now behaves consistently with the "wipe data" offline grace period policy:

When the app is brought to the foreground, the SDK checks when the last successful policy checkin occurred, and if the time elapsed exceeds the value provided for this policy setting, it will attempt a policy checkin. If that checkin fails for any reason, user is presented with options to try signing in to refresh their AAD tokens, remove the account, or to close the app. It sounds like some users may have launched their apps after not having used them for some time (perhaps over the weekend?) and were presented with these options due to the initial silent checkin attempt failing for some reason (maybe poor internet connectivity?). The reason that some users are allowed access on the 2nd launch after simply closing the application is because the policy checkin on the 2nd launch succeeded.

[LibertyDev18]

Hi @Kyle-Reis, thank you for the additional information. We understand the change and do think it makes sense to confirm a successful policy checkin. It appears that there might be some issues with the lifecycle management of these calls when being made in the background though.

Currently we have the grace period set to 12 hours. The checkin calls seem to be working if the app is just outside that 12 hour window but if the app remains in the background for a longer period of time (still trying to determine) it appears that the policy checkin call is potentially failing in the background (even on devices that have a good internet connection) and upon resuming the app is already in a potentially "hung" state. The app will sit on the "Checking you organization...' screen for about 30 seconds and then present the failure dialog.

It would seem like there needs to be additional handling of a policy checkin call where if it does fail in the background that a brand new attempt would be made on app resume to confirm instead of presenting a destructive/interactive prompt to the user on first failure (network blip, etc.). Or possibly allow us to specify an acceptable number of failed attempts over a specific period of time prior to blocking with the dialog.

So far we have been able to re-create this scenario on 8-10 test devices. This was done over a weekend so at this point we can only provide "a couple days" in the background causes the pretty consistent behavior but we are setting up more tests now (including setting a very low grace period to help in testing). Does the Intune SDK attempt these policy checkins in the background or are they always initiated on foregrounding of the app? This will help us understand the test cases to setup and whether or not the system is blocking these calls in the background after some period of time.

Thoughts? Specific tests that would be helpful to run from your perspective?

Thanks for time and help!

[Kyle-Reis]

Hi @LibertyDev18 - thanks for your feedback. We don't currently expose any policy settings for specifying an allowable number of failed checkins, because checkins can happen at different frequencies in different scenarios, and users might exceed that limit it a very short time period (like in a situation where the device is not able to connect to the internet). When making this change, we did have concerns over this exact scenario, where users might be prompted more frequently after not using the app over the weekend and having poor connectivity during their commute to the office, for example. But, we ultimately decided to proceed with the change since we think it actually does what the IT admins intended (define a maximum window of time that users can go without policy updates before they are blocked from using the application), and since organizations have the power to increase the timeout to a value that makes sense for them. If you think users in your organization might see the auth prompt too frequently because of cases like the above example, I would recommend increasing the time limit to a value which you think makes sense for your org (perhaps 3 days? Enough to allow user to go the weekend without using the app and have at least one failed policy checkin thereafter).

If you also think the silent policy check-ins are failing too frequently for users of your LOB app, even when they have a good internet connection, I'm happy to help investigate that as well. Could you collect Intune SDK logs for the app from users who experienced the failed check-ins? The Intune diagnostic console should allow you to upload logs directly to Microsoft. If you share the reference ID that is displayed in the console after uploading, I'll look into what might be causing the check-in failures.

[LibertyDev18]

Hi @Kyle-Reis, we'll try to get some logs captured to help determine what the failed check-in calls are a result of.

Just to confirm, is there any type of retry logic that is in place to address the temporary network glitch scenario? It would seem that a temporary network failure should never result in this type of enforcement or require this type of user interaction. If we set the grace period to 3 days and the user is driving through a tunnel on day 4...

Having some type of graceful handling of network failures but not blocking access would also align with other guidance on not blocking access when things like app management have not yet been confirmed etc.. It seems far too aggressive to trigger this dialog on a network failure.

We have a diverse app portfolio that consists of apps that are used during a variety of event based scenarios. Natural disaster events as an example. Apps may not be used every 'x' number of days so setting that number without proper error handling would most likely prove to be ineffective.

[Kyle-Reis]

Hi @LibertyDev18 - Currently the retry happens after the user authenticates. The purpose for the authentication is to remediate a check-in failure that might have occurred due to the cached AAD token being expired or having been removed from the MSAL cache. Unfortunately, we have no way of knowing when a failure to connect to the Intune service might be because the user is currently in an area with poor internet connectivity, or because the user may have intentionally disconnected or jailbroken the device to prevent policy refreshes (which this policy is specifically guarding against). Ultimately I think this comes down to a decision for organizations on how long of a period of time they are comfortable with users not receiving a policy update before they are blocked from accessing organizational data.

[LibertyDev18]

Hi @Kyle-Reis, based on the behavior we are seeing, it would seem like there should be no reason that the policy check-in calls are failing and if they were/are successful it would mitigate a large portion of the issue we're actively seeing. We'll focus on getting logs and get those sent over so we can focus on that part first.

Appreciate your help with this. I'll let you know when we have something to send over.