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
Exceptions
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.
Summary
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.
0 Comments