Conditional Access is one of those great features in the Microsoft Security ecosystem that makes it possible for organisations to control the modern security perimeter efficiently.
If designed and implemented correctly, a business can reap the benefits of a powerful and granular access control solution, which can significantly increase security. On the other hand, an implementation that does not consider the specific use cases, user personas and day-to-day processes of a business can have the adverse effect of reducing productivity.
#OpenParenthesis
Since Conditional Access has been around for a while and lots of great minds have had the opportunity to enforce it in countless ways, an equal number of great resources exist, for example:
- Claus Jespersen’s field guidance.
- Daniel Chronlund’s ring based deployment.
- Kenneth Van Surksum’s demystified whitepaper.
- Alex Filipin’s Conditional Access as Code.
The resources and information are quite literally endless, and this can lead into an “Analysis Paralysis” situation. If there is a single take away from this small off-topic it is this:
“All roads (can) lead to Rome. It’s the experience of the journey matters.”
A common scenario: a company with no Azure AD managed devices
Given that most organisations have not reached the maturity level required to have their devices managed in Azure AD (see: Hybrid Azure AD Join or Azure AD Join). A common scenario exists where bring your own device (BYOD) or traditional Active-Directory-Only joined devices (see: Azure AD registered devices) are used to access Microsoft 365 resources such as Exchange Online, Teams, SharePoint and OneDrive, or other cloud applications registered with Azure AD as an identity provider (IdP).
Requirements and constraints
The following generic requirements and constraints have been uncovered under this scenario. The company:
- requires a model for users to connect to organisational resources from unmanaged devices.
- does not want to make huge sacrifices in user experience but they want to significantly increase their security posture.
- does not consider device enrolment for the foreseeable.
A landscape full of unmanaged devices creates quite an interesting challenge, but for the sake of simplicity and to avoid converting this article into a design document, let’s assume that the company agreed on a model. Within that model amongst other controls, they decide to use shorter sign-in frequencies for all users accessing their environment.
A precarious situation
Microsoft’s recommendation comes down to “don’t ask users to provide their credentials if the security posture of their sessions has not changed”. There is a well thought out reasoning behind that statement, as the power of habit can create a situation where the user unintentionally supplies those credentials to a malicious credential prompt.
On the other hand, allowing the default 90-days refresh token may allow for persistence tactics which could otherwise be avoided. There are certainly other mitigation methods which can further limit the potential of a user making an error though. Mitigation methods such as implementing Microsoft Defender for Business with a strict ASR (Attack Surface Reduction) ruleset, using Custom Indicators, sending signals to Microsoft Defender for Cloud Apps, and applying governance from there.
In any case a guidance is a guidance – not a mandate. Decisions need to take the specific company’s threat profile into account, and in my opinion, whilst of equal importance relying only on sociotechnical security tactics is not good enough
Let’s assume again for the sake of simplicity that, the company:
- decides that users will have to sign back in and go through MFA every 5 days.
- implements Single Sign On (SSO) for all their AD domain joined devices.
This is where things can get tricky (and manual)
If the AD joined device of the employee does not get Workplace Joined, the SSO (single sign-on) is not seamless. Therefore, instead of a single prompt for sign-in and MFA, the user will end up getting multiple prompts for each one of the applications they are trying to access every 5 days. As you may imagine this not great at all.
“The reason for that bad experience is linked to the PRT not being available on Azure AD registered devices, unless you perform that additional step to Workplace Join your device.”
As a rule of thumb this is how a workplace joined device would look like:
Epilogue
The new system will reduce the frequency of sign-in notifications for users. They will still receive the below message every five days, but instead of having to sign in for each application they are accessing, the first one that succeeds will prompt them to sign in with the message below:
One caveat from an admin perspective on the above is that, at the moment, there is no way to do this programmatically and the reply from Microsoft around this has been adamant on its intention – use Hybrid Azure AD Join.
Enhance the end user experience on Azure AD managed devices
The 848 Group is a Microsoft Gold Partner with a team of experts in functional design of secure modern workplace solutions built on Azure. We can provide your business with a future-proof security practice to support you. This means you can run your business with the confidence that your data is secure.