Conditional access and registering security information

Similar like last week, this week is also still about conditional access. This week is about the recently introduced user action of Register security information (Preview).  A lot has been posted about that recently and I had my post ready, but I wanted to wait for an official blog post before publishing my version. Just to make sure that I’m using the right reasons for using this feature. Also, it simply fits the line of my recent post. This user action can be used to add conditional action to Azure AD security services that require information of the end-user. In this post I’ll start with a short introduction about this new user action and the behavior that the user action controls. After that I’ll show the configuration steps, followed by the end-user experience.

Introduction

Let’s start with a short introduction about the Register security information (Preview) user action. This user action can be used to add conditional access to Azure AD security service that require information of the end-user. That enables the administrator to require the end-user to be in a trusted location to register for multi-factor authentication (MFA) or self-service password reset (SSPR). At this moment this user action responds to the following:

  • https://aka.ms/setupsecurityinfo – The new, still in preview, combined security information registration page for MFA and SSRP;
  • https://aka.ms/mfasetup – The MFA security information registration page. With preview features enables for end-user, this will redirect to the new combined page;
  • https://aka.ms/ssprsetup – The SSRP security information registration page. With preview features enables for end-user, this will redirect to the new combined page;

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 Register security information user action. That scenario is to only allow users to register their security information, when connecting from a trusted location. 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;
3a

RSI-UserGroups-IncludeOn 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 Exclude to open the Exclude tab;

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

3b

RSI-UserGroups-ExcludeOn the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

RSI-CloudAppsOrActionsOn the New blade, select the Cloud apps or actions assignment to open the Cloud apps or actions blade. On the Cloud apps or actions blade, select User actions, select Register security information (preview) and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is only applicable to user actions to register security information.

5a

RSI-Locations-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Locations to open the Locations blade. On the Locations blade, click Yes with Configure, on the Include tab, select Any locations and click Exclude to open the Exclude blade;

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

.

5b

RSI-Locations-ExcludeOn the Exclude tab, select All trusted locations and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude trusted locations. As this conditional access policy should only be applied to untrusted locations.

6

RSI-GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block access for any location that is not trusted by the IT organization.

.

7 Open the New blade, select On with Enable policy and click Create;

Note: Keep in mind that the Register security information user action is still in preview.

End-user experience

Now let’s end this post by having a look at the end-user experience. When the end-user is connecting from a non-trusted location, the end-user will be blocked from accessing any of the earlier mentioned URLs. In that case the end-user will receive the message “You cannot access this right now” as shown below.

RSI-EndUserExperience

I did notice a few hick-ups when using this feature in it’s early preview state:

  • When using the new combined security information registration page for MFA and SSRP, the URL will re-direct via the Microsoft App Access Panel. That can trigger other conditional access rules that are configured for cloud apps;
  • Often I could initially sign-in shortly before getting tossed out by conditional access;

More information

For more information regarding conditional access and sign-in frequency, please refer to the following article:

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