Governing when users receive authentication prompts when authenticating to Azure Active Directory (Azure AD) is depending on more than one setting, on which functionalities are in use and also in which scenario you authenticate (Browser, Modern clients or other). Reauthentication can take place by asking for a single factor, like password, FIDO, the password less option in the Microsoft Authenticator app or by using Multi Factor Authentication (MFA)
So you might understand that how reauthentication must be configured really depends per company and per scenario, so luckily Microsoft provides options which you can configure.
You want users to reauthenticate more often when they come from a non-managed or non-registered device
You want users to reauthenticate more often when using a certain cloud application which you make available via Azure AD single sign on
You might want some users in your organization to authenticate more often than others based on their risk profile
In this article I’m going to explain the different options available and where to configure what setting so that you can govern your own reauthentication settings.
Disclaimer: This post reflects the status of assigning groups to Azure AD roles as of October 21, 2020. Functionality may change, even right after this post has been published.
For Tuesday, October 27th we are proud to announce that Erik Loef, CTO and Microsoft MVP at Proxsys, and Kenneth van Surksum, Modern Workplace consultant at Insight24 will host a session about: “What is this Modern Authentication everyone is talking about, and why you should phase out Legacy authentication?”
With Microsoft Intune, there is a lot of focus on the Mobile Device Management (MDM) aspects of the product. This is logical because from a management perspective, if you manage a device using MDM, you can configure almost all settings remotely, something we as System Administrators have been doing for many years.
In many situations, just managing the Apps which you use to access your company data hosted in Office 365 is a more suitable solution, there are a couple of reasons for that.
Many companies who want to implement measures to protect their company data, already allow access to company data via email, apps but now want to manage that. End users, even the ones provided with a device owned by the company, use the device for personal usage as well.
Implementing a MDM solution for mobile devices, is far more complex and more intensive from a system management point of view, in many cases the MDM solution provides way more functionality than what’s really required (protect the company data)
Mobile Application Management (MAM) in some cases is a perfect way to let your end-users use their device the way they are used to, but also implement security measures which protect your company’s most valuable asset: The data.
In this article I will go into more detail of the MAM without enrollment (MAM-WE) functionality provided by Microsoft Intune/Microsoft Endpoint Manager.
Disclaimer: This post reflects the status of assigning groups to Azure AD roles as of October 10, 2020. Functionality may change, even right after this post has been published.
Continuous access evaluation allows for a quicker response by forcing an access token refresh in case of a certain events taking place. In this version of the preview the following events will be supported:
User Account is deleted or disabled
Password for a user is changed or reset
MFA is enabled for the user
Admin explicitly revokes all Refresh Tokens for a user
Elevated user risk detected by Azure AD Identity Protection
One of the scenario’s we can build with Conditional Access, is the scenario where we restrict access inside the web application itself. By doing so, you could for example limit the functionality of the web applications on non-managed devices, or when accessing the web application from a country where your company normally doesn’t operate. The web applications can be configured to behave differently if the user is applicable for a Conditional Access policy where App Enforced restrictions are configured.
Within the Office 365 suite of applications, the following web applications are supported for App Enforced Restrictions:
Outlook Web Access
SharePoint and OneDrive
In this post I will go into detail on how to setup these app enforced restriction and what the expected behavior will be from an end-user perspective.
In August last year, I published eight articles in a series on Conditional Access, and later when finished I decided to bundle those articles in a paper which I made available on the TechNet Gallery. In March this year, Microsoft decided to retire the TechNet Gallery, so I had to find another solution to host this paper and some of the additional workflows and spreadsheets I posted as well. For now I’ve decided to host these on GitHub since that is an easy accessible location as well.
The articles I wrote at that time, will remains as is, and I’ve decided to update the paper once in a while to reflect the current status of Conditional Access. Even though some of the information in the articles is outdated, I still think that they can be of value.
Below I’ve summarized the articles I published last year:
One of the advantages of Microsoft having many customers using its services is that Microsoft can leverage data from those customers and apply some real fancy Machine Learning on that data, coming from Azure AD, Microsoft Accounts and even Xbox services.
Based on all that data the Machine Learning capabilities are able to identify identity risks. Based on the risk, automatic investigation, remediation and sharing of that data with other solutions able to leverage it is possible. The outcome of risk is expressed as either High, Medium, Low or No Risk. This outcome can later be used to define policies.
By leveraging Azure AD Identity Protection you are able to use the signals provided by Microsoft and trigger “actions” – the signals can also be leveraged in your conditional access policies.
discussed the baseline policies in part
5 of my blogpost series “Conditional
Access Demystified“, while they provided a welcome addition, one of
the main disadvantages of the baseline policies in its current preview form was
that there was no option to exclude accounts from the policy, which was in
contradiction with the best practice for break glass accounts and therefore
made the policies not usable in some scenario’s.
In my blog article series on Conditional Access Demystied I mentioned that Conditional Access can be used to route sessions toward Microsoft Cloud App Security (MCAS). In this article I will go into more detail on what MCAS is, and how to setup Conditional Access App Control.
Disclaimer: This article discusses the full option MCAS product, there are some other flavors providing partial functionality like Office 365 Cloud App Security and Cloud App Discovery (CAD). For information about licensing, see the Microsoft Cloud App Security licensing datasheet.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.