Like last week, this week is also about conditional access. This week is about the recently introduced session control of Persistent browser session (preview). It was already possible to configure the persistence of browser sessions by using the company branding configuration, but this new session control provides the administrator with a lot more granularity. In this post I’ll start with a short introduction about this new session control and the behavior that the session control controls. After that I’ll show the configuration steps, followed by the administrator experience.
Introduction
|
The “Stay signed in?” prompt can be controlled on tenant-level, by editing the company branding, or by using the Persistent browser session (preview) session control. The session control provides a lot more flexibility, as it enables the administrator to differentiate on persistent browser sessions, based on the location, the sign-in risk, the location, the client app and the device state conditions that are applicable to the sign-in of the end-user. That and of course based on the end-user itself. |
Configuration
Let’s continue by having a look at the configuration options. Let’s do that by looking at a simple scenario that is focused on the Persistent browser session access control. That scenario is to never have persisting browser sessions on any platform, for accessing any cloud app, on personal devices. The following seven steps walk through that scenario.
| 1 | Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or navigate to Azure Active Directory > Conditional access > Policies to open the Conditional Access – Policies blade; |
| 2 | On the Conditional Access – Policies blade, click New policy to open the New blade; |
| 3 |
Explanation: This configuration will make sure that this conditional access policy is applicable to all users. |
| 4 |
Explanation: This configuration will make sure that this conditional access policy is applicable to all cloud apps. This is also a required condition for the Persistent browser session (Preview) session control. |
| 5 |
On the New blade, there is no need to select the Conditions assignment; Explanation: This configuration will make sure that this conditional access policy is applicable to all platforms, locations, client apps and device states. That will also make sure that only personal devices are affected, as the “Stay signed in?” prompt is only shown on personal devices. |
| 6 |
Explanation: This configuration will make sure that this conditional access policy will never persist browser sessions for the assigned users, to the assigned cloud apps. Note: This Persistent browser session (preview) session control, will overwrite the “Stay signed in?” configuration in the company branding pane. |
| 7 | Open the New blade, select On with Enable policy and click Create; |
Note: Keep in mind that the Persistent browser session control is still in preview.
Administrator experience
Now let’s end this post by having a look at the administrator experience. I’m deliberately not showing the end-user experience, as the configuration of this post will suppress the “Stay signed in?” prompt that was shown at the beginning of this post. A successful configuration would mean that the end-user no longer receives the “Stay signed in?” prompt. From an administrator perspective, this can be simply verified by looking at the Sign-ins report that is available in Azure Active Directory. That report will show the conditional access result for the applied conditional access policies and their session controls.
More information
For more information regarding conditional access and persistent browser sessions, please refer to the following article
- Manage authentication sessions in Azure AD conditional access is now in public preview!: https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Manage-authentication-sessions-in-Azure-AD-conditional-access-is/ba-p/500983
- Configure authentication session management with conditional access: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime
Discover more from All about Microsoft Intune
Subscribe to get the latest posts sent to your email.
Does this also work for custom AAD apps (app registration/enterprise app) ? Or only SharePoint and Exchange Online?
Greets to you sir!
Hi RKast,
It applies to all registered apps.
Regards, Peter
Thanks for the reply Peter. Indeed i see now 🙂 i misread the app enforce restrictions part. Finaly the config token lifetime days are over and replaced by CA.
We try to check Persistent Browser Session and select all APPS but when we exclude some apps it’s not letting us save. Please let me know how to fix it.
Hi Paul,
I only know that all apps is a requirement (at least at this moment). If you need more details, you might want to check with Microsoft.
Regards, Peter
Thanks for the blog.
Note, that this policy does not provide the desired end user effect for users signing in with Chrome or Edge where they have the start-up option ‘Continue where you left off’ or ‘Open a specific page or set of pages’ – when the user closes and re-opens the browser, the session carries on from where they left off and the cookies are not cleared down.
It’s fine when the Chrome/Edge start-up option is ‘Open the New Tab page’; closing and re-opening in that scenario requires re-authentication.
As many people use the ‘Continue where you left off’ or ‘Open a specific page or set of pages’ option in Chrome/Edge, a way to help mitigate against that is introduce a session sign-in limit of X hours.
Thank you for sharing your experience Ben!
Hi Peter,
You want to only disable persistence on personal computers, but as you never select any conditions it should apply to all devices no ?
Hi Alex,
This example was only to show the capability and was intended for all devices.
Regards, Peter