Techdays Finland 2019 – Special

Your Bloggerz – fellows Matti and Markus were talking about Protecting User’s Identity with Azure AD Conditional Access in Techdays Finland 2019 on 1st of March 2019. In the session we promised to write also the session content and slides in readable form to this blog, so here it is.

Introduction to Phishing

Phishing is currently the most common form of identity breaches. Many companies have been affected by it during the last 6 months. Typical steps to identity breach with phishing are:

  • The authentic looking e-mail arrives to inbox
  • User clicks the link in it and will be forwarded to the authentic web page
  • User enters username and password which will end up to hackers hands

Phishing messages that we have seen, looks really close to authentic messages. Below there are two examples from e-mail that looks like encrypted message and e-mail that looks like authentic Teams notification.

After the hackers have been able to phish user’s credentials they will use those to log in to users mailbox (or other service). Hackers will monitor legit mail flow and check out the company address book for potential next victims.

Due to mail monitoring the hackers can create fake messages that looks really authentic and fail people to believe that they are indeed authentic and therefore causing issues with fake invoicing and spoofing.

Protecting the Identity

Identity protection is important because end user is always the weakest link of security. Eventually users will fall to recognize phishing messages and credentials will be breached by hackers. With identity protection in place we can prevent hackers from using the credentials that they get from end users. In this blog we will concentrate on two methods of identity protection provided by Azure AD

  • Multi Factor Authentication
  • Azure AD Conditional Access

You can also provide identity protection by restricting use of services based on users network location, but we advise you to leave that as the last option since nowadays you really should not need to worry about the network location.

Multi Factor Authentication

Multi Factor Authentication (MFA) is the 1st level of protecting identity. What we mean with MFA is that you have enabled MFA per user in Office 365 admin portal or you have configured Conditional Access policies so that every scenario goes through MFA challenge.

If we look Multi Factor Authentication from end users’ point of view as a flow chart it looks like this:

Of course the MFA itself does not have device or application type checks, but this flow chart demonstrates that whether the device is trusted or not and whether user is using client or browser, they will be facing MFA challenge and have the possibility to access services if they pass the challenge.

With that in mind lets go check lesson number 1:

Lesson 1

In this lesson we have a user who has a MFA enabled. User is accessing his or her mailbox with Outlook client from an unknown computer (that can be their home laptop or library computer or basically any computer).

User will be required to complete MFA challenge in order to access the mailbox. Takeout here is that Outlook works just like it has been working since forever. Outlook creates a local copy of the mailbox. Meaning that even though you require MFA to access the mailbox it allows a scenario where company emails are stored locally on a non-trusted device. This is probably an unwanted scenario for most cases and we usually get surprised looks when we tell this to people. Somehow MFA has fooled people to forget how Outlook is designed.

Now when we have your attention – lets go and check one possible solution

Conditional Access

Azure AD Conditional Access is more advanced way to protect identity. Conditional Access requires Azure AD Premium P1 license that comes as a part of Enterprise Mobility & Security (EMS) – bundle.

Conditional access policies consist of conditions and actions. By combining conditions and actions it is possible to create desired use scenarios for different devices and application types. Network location can also be used as a condition, but you should try to plan policies so that network location is irrelevant.

Conditional Access example scenario

We have a policy that trusted device will be allowed access to Office 365 services with browser and client. If the user is using non-trusted device they will be allowed to use browser through MFA challenge and client use will be blocked. This policy would not allow the scenario in Lesson 1 to happen.

The same can be presented with flow chart from end users point of view:

In this scenario the MFA challenge is only used if the device is not trusted and user is accessing with browser. User from trusted device will be allowed access without any MFA interfering. This will improve end user experience. Basically as long as users are using their company workstations or other trusted devices they dont even know these Conditional Access policies exist. Also in the above scenario if the users identity is stolen it will be difficult to access services without having the trusted device or knowing the MFA. At least in theory… we will come to that later.

Let´s compare MFA Enabled user to Conditional Access policy – enabled user to highlight the differences

Basically Conditional Access is more user friendly and provides better protection.

Lesson 2

The user is trying to access their mailbox with Outlook client from unknown computer, but Conditional Access policy prevents that. Great!

Just one thing… if the user is not your legit end user, but is a hacker

By disabling Modern Authentication from Outlook client or using any other legacy authentication method such as IMAP etc. the hacker will get access to mailbox. Obviously after the Outlook works as designed and creates the local copy of the mailbox on hackers computer.

Let´s update the flow chart accordingly

Does the legacy authentication bypass our Conditional Access rules? Yes. That is correct. It can also bypass your MFA requirement. So we need to block it. Our goal is to make the flow chart look like this

Blocking legacy authentication in real life is not as simple as in demos and theories. You need to consider a lot of aspects and plan the blocking carefully. Next topic of this Techdays 2019 – special will introduce you to legacy authentication block more closely.

Blocking Legacy Authentication

When planning and preparing for legacy authentication blocking you need to take in to account following

  • Android native mail application
  • Office 2010 – clients
  • Office 365 backend systems that use legacy authentication
  • Systems that authenticate against Azure AD

Blocking legacy authentication means that users will not be able to use their Android device native mail applications (as of March 2019). This means that prior to deploying the rules the Android users need to be transitioned to use mail application which uses Modern Authentication instead of the native mail application e.g. Outlook Mobile App. Same approach is also recommended and preferred for iOS users as well, but not mandatory.

Office 2010 – clients need to be upgraded to newer ones.

Office 365 backend systems such as Skype and Exchange Online need to be configured to allow Modern Authentication.

There are also separate systems that authenticate against Azure AD. You will also need to plan how to take care of those when deploying legacy authentication block. These can be for example:

  • IMAP, POP3 – email using systems or applications
  • Authenticated SMTP Relay
  • Service Accounts
  • 3rd Party Applications


Usually there needs to be some exceptions to legacy block rules in order for everything to work as they should.

User exceptions can be configured for service accounts and shared device accounts. They are not likely to be targets for phishing or at least there is no end user falling for those attempts. Therefore they are rather safe to be configured for exceptions if there are no other options.

With Citrix and Remote Desktop Services our recommendation is to register the Windows Servers as trusted devices in Azure AD. That way you can allow the use of services from them without compromising identity protection.

We advise to avoid using Network location exceptions as much as possible because they kind of mess the whole idea of device based conditional access. In most cases there are better solutions available so just try and dig for them. Also Network locations will mess up the logic of conditional access rules while trying to block legacy authentication from everywhere.

How to Disable Legacy Authentication

How do you do it then? There are a few ways that we will go through here

You can configure simple Conditional Access Policy to block legacy authentication. In most real life scenarios that is not the working solution for all scenarios. That is why you will need to plan some exceptions. The most typical scenario is that the Skype client on users computers is using legacy authentication to check for availability information from users Exchange Online Mailbox. This happens even though both Skype Online and Exchange Online backends have been configured to user Modern Authentication.

Usually we configure legacy authentication block with the exception of Skype and Exchange. Also we configure Exchange Online Authentication Policies to allow Legacy (basic) authentication to Exchange Web Services and disable Legacy Authentication for all the other Exchange Services. This has appeared to be the winning solution with our customers. Of course we can make a separate authentication policy for service accounts to allow necessary protocols for legacy usage.

It is also possible to block legacy authentication with ADFS Claim rules, but since ADFS is quietly disappearing we advise to deploy legacy authentication using the methods provided from Microsoft Online services.

Azure AD authentication in application development

To application developers we provided few finding from the field. For applications which requires an user authentication, we encourage you to leave authentication itself for Azure AD and for example federate the sign in towards it.

  • If you are using SAML federation for authentication, the federation can be made towards Azure AD
  • If you are planning a non-single sign on authentication, use Azure AD admin consent framework to connect to Azure AD

There is also a possibility to provide a federation claim of an assigned roles from Azure AD to your application which are based on security groups inside of Azure AD. This is a nice feature to handle also internal roles of your application.

Customer’s might have different kind of requirements for accessing your application based on their own identity protection architecture. That’s why it’s always a good to mention for customer that handle the authentication yourself or with your Azure AD partner – not in the application.


Above are quotes from some of our customers regarding the topic of Identity Protection. To summarize what we have replied to these assumptions / suggestions:

  • Its not enough to protect just some users. If hacker gets to any end users mailbox they will be able to use it for targeting and lateral movement. Always protect all end users identities
  • Tightening spam filtering is not long term solution and will probably cause more false positives than actually prevent Phishing messages that are getting more and more advanced.
  • Device based Conditional Access is very user friendly. When using trusted device the user does not even need to be aware that these policies exist. Users only face these policies when using devices that are not trusted
  • MFA is better than nothing, but as you have read in this blog it has its drawbacks so you should not think that it is sufficient nowadays. Also it is rather unfriendly to end users.
  • It´s good that you have modern clients and systems. However the hackers dont care about that. They will use legacy devices because they know that they have more success that way.

To conclude our message in one slide

Thank you for reading / attending and hopefully we´ll be seeing you down the road.

Matti Väliniemi & Markus Lintuala

Find all published slides from Tech Days 2019 community site.

Markus Lintuala

I've been working in IT since 2009 in different roles mostly with solution architecture, service development, training and consultancy side. With Azure I started to work in 2013 and with Microsoft 365 related products in 2011. I like to work often with the newest technologies by testing, giving feedback and share the knowledge to people around me. Currently I'm working much in Azure side with governances, security and solution architectures and in Microsoft 365 side with E5 security solutions with strong zero trust aspect.


Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.