Hello folks,
Answering a few questions here. Thank you for the feedback. DanielFraubaum and Zerqent your ask for more control here is understood and appreciated. We are somewhat limited in our options, but we will take an action to discuss internally what might be possible here to provide you with more control.
1) We are investigating the VDI behavior discussed earlier and will have an update in a couple weeks. In the interim time, the expected behavior is that for persistent sessions, users will see this notice.
2) Arnaud - I'll get that for you shortly.
3) Daniel - Unfortunately, no. The nature of the interrupt is triggered in a "just in time" manner.
4) Zerquent #1 - This is stored locally per user per device on the client in the token that is issued during the auth process. This means that we do have have the technical means to track this on the user object.
5) Zerquent #2 - Once the user accepts the notice for one of the failing apps, the rest will begin to work again, and that state will persist unless the device is not used for a 90 day period. I understand though that in the interim time the experience is painful. In general, apps should show a notice to users to resolve the interrupt.
6) Zerquent #3 - The retry period is going to vary per app. There would be scenarios where if a bunch of apps have hit the same interrupt at the same time, that they may recover at different rates. But once the token includes the appropriate state that the interrupt has been accepted, these apps will start working again. Based on your response in #2 and #3, if there are specific cases of a breakage you would like us to investigate, please send us a note at sso-info@microsoft.com and we will be happy to assist.
7) Zerquent #4 - We did evaluate such a design, but unfortunately found this would not work in many cases due to credential caching that happens during most login events.