Conditional access and persistent browser sessions

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

IMG_0029 1Now let’s start with a short introduction about the Persistent browser session (preview) session control. A persistent browser session allows the end-user to remain signed in after closing and reopening their browser window. The default configuration for browser session persistence, allows the end-user on a personal device to choose whether to persist the session by showing a “Stay signed in?” prompt after successful authentication.

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

KMSI-UserGroupsOn the New blade, provide a unique name and select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade,, on the Include tab, select All users and click Done to return to the New tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

4

KMSI-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select All cloud apps and click Done to return to the New blade;

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

KMSI-SessionControlOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Persistent browser session (preview), select Never persistent and click Select to return to the New blade;

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.

KMSI-SignIn

More information

For more information regarding conditional access and persistent browser sessions, please refer to the following article

4 thoughts on “Conditional access and persistent browser sessions”

  1. Does this also work for custom AAD apps (app registration/enterprise app) ? Or only SharePoint and Exchange Online?

    Greets to you sir!

  2. 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.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.