Conditional access lessons learned and shared

Image: Azure AD Conditional Access graphic
By Tom Bestow on

Conditional Access used to implement Multi-factor authentication (MFA) is the strongest first step to preventing unauthorised access to systems, services, and data. Advice from all quarters is to, at the very least, enable MFA for all your users. This simple step can prevent 99.9% of all identity-based attacks. Consequently, Silversands recommends this for all of our customers.

However, in our experience deploying MFA and Conditional Access for various customers we have picked up a few ‘gotchas’.

When Conditional Access policy changes are applied

Conditional Access policies will only apply to a user after a successful sign in, Until that next sign in either no policy will be applied to sign in attempts or the previous policy may apply.

For example, if a policy requires MFA, and then a condition is added that accepts device compliance, the user may still be prompted for MFA on the next successful sign in.

When Conditional Access policies are applied

Currently Conditional Access and MFA will not kick in until after the initial authentication. The flow is as follows:

Provide username -> Provide Password -> process Conditional Access Policies -> if required, prompt for MFA -> complete sign in

Therefore, under scenarios such as password spray attack or denial of service identity attack, Conditional Access will not prevent an account from becoming locked out due to successive invalid logon attempts.

To combat this the only real option is to take the next step and move towards full passwordless authentication (in preview at the time of writing), along with other mitigations such as disabling all legacy authentication. This is because automated attacks against Modern Authentication protocols are more difficult than against legacy authentication endpoints (more on legacy authentication later…)

Other platforms

The main policies available provide the option for controlling access on Windows, Android, iOS, and macOS. Configuring policies for all these specific operating systems is all well and good. But what happens with other OSs?
If someone accesses your services using Linux, or an OS which has been configured to mask its identity, none of these policies will apply!

Image: Conditional access window

The upshot of this is that decisions need to be made around whether the use of additional platforms is permitted by the organisation? Consequently, additional policies configured to manage or deny that access may need to be implemented.

The outlier

Similarly, a key area we have noted is spotting the gaps in the policies, the scenarios that don’t match, where no policy will end up applying.

It is all too easy to craft policies which work wonderfully for those who are playing by the anticipated scenarios. But everything is left wide open for the others.

Making assumptions based upon only what the organisation sees as the authorised approach, the platforms provided and managed by the organisation can potentially leave the true breadth of variables your users employ to perform their work as unmanaged or invisible.

It is just as important to review the access, failed and especially successful, after deployment of Conditional Access to account for genuine changes in user behaviour and for any probing access by unauthorised persons.

Legacy authentication is still a massive hole

Blocking legacy authentication is long overdue.

Legacy authentication continues to be the most common account breach hole we see in organisations. It is typically used as the primary ingress method into services where it has remained enabled. As a result specific users or services can perform actions such as accessing mailboxes using out of date protocols.

Legacy authentication is almost always the first port of call for credential validation. Attackers know they have obtained valid logon credentials for active user accounts. This allows them to establish the initial foothold for persistent presence within an organisation.

Whilst it would be ideal to blanket block legacy authentication, as noted above, there are still the odd use cases where it is required. For example. scenarios such as photocopiers, payroll systems and third party integrations. However through reporting and monitoring it is possible to build the scenarios to lock legacy authentication down to only be permitted for specific accounts (or groups), from specific locations, and no further.

Takeaways

The biggest takeaway from all of this is that Conditional Access is not something to be set and forgotten. Anticipate that scenarios envisaged at day one will grow and develop over time. Just as the use and growth of the organisation changes and grows over time. The Azure AD toolset provides all the information required to adapt, manage, and grow intelligently.

Time to act

If you would like to discuss the critical nature of enabling MFA and driving your organisation towards a secure working environment without restricting productivity, Silversands can assist.

Simply complete the form below to speak to one of our consultants.

And join one of our regular workshops and webinars providing the latest updates and expert advice about Microsoft 365, Cloud and Hybrid IT, security, compliance and partner tools. We also post regular blogs so please do follow us.

Contact us

  • This field is for validation purposes and should be left unchanged.

We have the expertise and the experience to provide specialist solutions and drive your business forward

Get in touch