Maximizing Security: Entra ID Sign-in Frequency Demystified

In this post, I will equip you with the tools to fortify high-risk actions and applications using Entra ID’s “every time” sign-in requirement. I will unravel how to implement this feature, ensuring your organization’s most sensitive activities are safeguarded without sacrificing user experience. Join in to demystify Entra ID Sign-in frequency!

Table Of Contents

The Background

Single Sign-On (SSO) has become the holy grail of convenience in our relentless pursuit of seamless user access. Picture this: You log into your Intune-managed device with your trusty Entra ID, and suddenly, a world of applications and resources is at your fingertips—all without the hassle of multiple logins. It is the epitome of efficiency and security… or is it?

While SSO offers unparalleled ease of use, there are moments when a little extra security is warranted. Enter the need for specific authentication measures tailored for high-stakes actions or critical applications. Because, let’s face it, not all access requests are created equal.

In the realm of cybersecurity, one size certainly doesn’t fit all. That’s where the beauty of Entra ID shines through. It has some secret sauces that allow us to maintain the seamless flow of SSO while adding an extra layer of protection exactly where we need it most.

So, buckle up as we journey into the heart of conditional access, where every login is a strategic move in safeguarding our digital assets.

Add Entra ID Sign-in Frequency To PIM Operations

Entra ID Privileged Identity Management (PIM) is a service that helps manage, control, and monitor access to important resources in an organization. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions. It also offers features like just-in-time privileged access, multifactor authentication for role activation, and access reviews to ensure users still need roles. This helps to enhance security and control within an organization. For some roles like Global Administrator, we might want to ensure Entra ID sign-in frequency is set to every time.

The Authentication Context As Part of Conditional Access

I’ll leverage the Authentication Context feature within Entra ID Conditional Access as the cornerstone of my targeted safeguarding. Think of authentication context as a tag or label you can use to activate additional security measures through conditional access.

I find Authentication Context under Protection – Conditional Access in the Microsoft Entra admin center.

Here, I can create a new Authentication context, and I have selected to create one named “Require Reauth”. I give this a description and select one of the 99 available IDs.

The Conditional Access Policy Looking For My Authentication Context

I will now create a Conditional Access policy that will act on the authentication context created. In my following example, I created a global policy targeting all users.

In Target resources (1), I selected the Authentication context I created earlier, “Require Reauth”. In Session (2), I used the Sign-in frequency “Every time”.

Be aware of the warning! Over-prompting can happen using this setting! A better alternative might be to require a stronger form of authentication! A separate authentication context for strong authentication is demonstrated further down in this blog.

Assign Authentication Context To PIM

I can now assign my authentication context to the Entra ID roles I want to ensure authenticates at every PIM activation. This is done in the Roles & Admins blade under Identity in the Microsoft Entra admin center. Search for the Global Administrator role, navigate to Settings, and Edit. This gives the option to configure the Authentication context.

You should also notify the option to set the maximum activation duration in hours. Reducing this can be wise for roles like Global Administrator. This will encourage administrators to take on less privileged roles daily, and you’ll effectively promote a mindset focused on least privileged access. Also, pay attention to the requirement for justifying the role activation.

Verify Entra ID Sign-in Frequency On PIM Operations

With this new setting enabled in the Tenant, it is time to test and verify the authentication context, triggering the conditional access policy and forcing the sign-in frequency. Navigating to aka.ms/pim and activating the Global Administrator role now forces me to re-authenticate.

Selecting Activate on the Global Administrator role leads me to authentication before I provide a reason to activate for a maximum of 2 hours. This way, I have raised the security for the Global Administrator role in my tenant. At the same time, I can entice my administrators to use other RBAC roles, such as Intune Administrator.

Add Entra ID Authentication Strength To SharePoint Sites

I can also protect SharePoint sites holding sensitive content by utilizing the authentication context and conditional access policies created above. I will rather demonstrate a strong authentication requirement for this example. The goal is to ensure specific authentication when accessing these sites, not just relying on the SSO feature given by the user signed in with its Entra ID credential to the Intune managed endpoint. A Sensitivity Label should target SharePoint sites holding sensitive content.

The Authentication Context As Part of Conditional Access

I will create a new authentication context for strong authentication requirements. This is done in the same way as seen above in this post.

This time, I created an authentication context named “Require Strong Auth”.

The Conditional Access Policy Looking For My Authentication Context

Next is configuring a Conditional Access Policy targeting the authentication context (1) and requiring an authentication strength (2).

This authentication strength defined in this example is the built-in “Phishing-resistant MFA”.

The Sensitivity Label Labeled By The Authentication Context Label

I can manage sensitivity labels in the Microsoft Purview compliance portal, which classifies and safeguards team content like SharePoint sites. I navigate the Microsoft Purview portal to Information Protection – Sensitivity labels. Here, I have made one demo label for Groups & Sites, which has been published:

When editing this sensitivity label, I can use Microsoft Entra Conditional Access and choose to trigger conditional access actions using an authentication context.

Some prerequisites exist to activate sensitivity labels in your tenant for SharePoint Sites. Follow this Microsoft documentation describing the prerequisite to assign sensitivity labels to groups. You must also synchronize your sensitivity labels to Microsoft Entra ID as instructed in Microsoft documentation for sensitivity labels with Microsoft Teams, Microsoft 365 Groups, and SharePoint sites. I recommend checking my colleague MVP Nikki Chapple’s blog post on how to add sensitivity labels to your existing Microsoft 365 Groups, Teams, and SharePoint sites.

The changes may take up to 24 hours to sync through all portals.

When I check in on a site in the SharePoint admin center, I can now add the Sensitivity label found under Settings.

The SharePoint site is now labeled with this sensitivity label holding the authentication context.

Verify Entra ID Sign-in Frequency On SharePoint Sites

Now, it’s time to verify the functionality of this configuration from an end-user perspective. A regular user working from an Intune-managed endpoint will have direct access to SharePoint using Single-Sign-On. Clicking on an available site will give direct access to its content without being asked for authentication.

After clicking on a site holding the sensitivity label with the authentication context, I must re-authenticate, as seen in the following picture:

I have also demonstrated this functionality in the Festive Tech Calendar 2023, available on YouTube:

There, I also do a strong authentication requirement instead of requiring a sign-in frequency.

Add Entra ID Sign-in Frequency To Enterprise Applications

I’ve encountered situations where it was necessary to enforce specific authentication strengths or sign-in frequencies for Enterprise applications that aren’t included in the standard Conditional Access policies. To address this, I used Entra ID Custom Security Attributes. These attributes allow me to target enterprise applications effectively for the appropriate Conditional Access policies, either as inclusions or as exclusions.

RBACs To Administer Custom Security Attributes

You might think signing in with Global Administrator rights gives you all the rights necessary in the Tenant. That might not always be true, and working with Custom Security Attributes in such an example.

I must hold the “Attribute Definition Administrator” role to create Custom Security Attributes.

I must hold the “Attribute Assignment Administrator” role to assign Custom Security Attributes.

With these roles active, I am ready to configure the Custom Security Attributes.

Adding My Custom Security Attribute Set

With the “Attribute Definition Administrator” role active, I can continue to create attribute sets from the Entra Admin Portal – Protection – Custom security attributes.

The attribute set needs a name, a description, and a defined maximum number of attributes.

Adding Attributes To The Custom Security Attribute Set

Clicking into the defined Custom Security Attribute Set, I will find the option to add attributes.

I will now configure my attributes. Here, I will give it a name (1) and a description (2) before I select the data type (3). I will set it only to allow predefined values to be assigned (4) before specifying them (5).

Here, I have created two alternatives.

Be aware that you can’t delete these attributes once created!

Assign Custom Security Attributes To Enterprise Application

After activating the Entra ID role “Attribute Assignment Administrator”, I can navigate to the Enterprise Application blade , find and application and add an assignment under Custom Security Attributes.

I can now add assignments and select the value.

Remember to save before leaving this blade.

Conditional Access Policy For Custom Security Attributes

I have created a new conditional access policy targeting cloud apps using a filter to select apps based on the Custom Security Attributes.

The filter uses the custom security attributes to target apps before I set the required session configuration.

Verify Entra ID Sign-in Frequency On Enterprise Applications Using Custom Security Attributes

I tagged the Microsoft Graph Explorer enterprise application in the example above using my defined Custom Security Attributes. When testing this app using aka.ms/ge, I normally get signed in using single sign-on. With my new configuration, I need to re-authenticate.

Looking at the sign-in logs, I see the sign-in frequency applies.

Using this technique, I can granularly target or exclude my Enterprise Applications to specific security needs using Conditional Access.

Final Thoughts Entra ID Sign-in frequency

We are still celebrating the awesomeness of the macOS Platform SSO released by Microsoft at the beginning of May 2024. However, there might still be instances where additional security measures are needed, such as segmenting certain accesses. I hope this post has inspired you to explore ways to enhance security for the areas that need extra protection from the magic of single sign-on. I have discussed both the sign-in frequency option and the authentication strength option. Remember, security is essential – make sure to lock the doors!

External References

• Session controls in Conditional Access policy – Microsoft Entra ID | Microsoft Learn
• Conditional Access adaptive session lifetime policies – Microsoft Entra ID | Microsoft Learn
• Cloud apps, actions, and authentication context in Conditional Access policy – Microsoft Entra ID | Microsoft Learn
• What are custom security attributes in Microsoft Entra ID? – Microsoft Entra | Microsoft Learn
• Assign sensitivity labels to groups – Microsoft Entra ID | Microsoft Learn