Currently, we could say that Legacy Authentication is one of the most compromising sign-in, luckily for us, older protocols have been replacing with modern authentication services, taking the advantage that MA supports MFA, while Legacy Authentication refers to all protocols that use Basic Authentication, and only requires one method of authentication.
So, it is important thar for security reasons we need to disable legacy authentication in our environments, why? Because enabling MFA isn’t effective if legacy protocols are not blocked. For example, the following options are considered legacy authentication protocols:
Authenticated SMTP – Used by POP and IMAP clients to send email messages.
Autodiscover – Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
Exchange ActiveSync (EAS) – Used to connect to mailboxes in Exchange Online.
Exchange Online PowerShell – Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect.
Exchange Web Services (EWS) – A programming interface that’s used by Outlook, Outlook for Mac, and third-party apps.
IMAP4 – Used by IMAP email clients.
MAPI over HTTP (MAPI/HTTP) – Used by Outlook 2010 and later.
Offline Address Book (OAB) – A copy of address list collections that are downloaded and used by Outlook.
Outlook Anywhere (RPC over HTTP) – Used by Outlook 2016 and earlier.
Outlook Service – Used by the Mail and Calendar app for Windows 10.
POP3 – Used by POP email clients.
Reporting Web Services – Used to retrieve report data in Exchange Online.
Other clients – Other protocols identified as utilizing legacy authentication
How can we monitor the usage of legacy authentication in Azure AD?
Thanks to Log Analytics, Insights and workbooks, we are able to monitor the use of those protocols, for instance:
And check the non-interactive sign-ins (be careful with ADConnect sync accounts):
But in this post, I want to talk about something related to it, in one of my projects, I have a CA policy that required one of the following selected controls: Require MFA or Require Hybrid AAD joined device
My device was Hybrid, so I was fullfilling one of the requirements, for example, when I was accessing with IE or Edge, the device info gets passed properly and MFA is bypassed for hybrid AAD machines.
But with Chrome, even having the Windows 10 Account extension pushed via GPO, I was able to see in the azure sign-in logs that device info is blank except for Browser and OS, so the AAD join status is not passed and MFA triggers. So it was very weird and it was causing me some problems…
So finally, after hours of troubleshooting, i finally figured out what was wrong. When you automatically install the extension, it doesn’t clear some cookies which Chrome will then try to use the old way of logging in. So in this case what you will need to do is access to chrome://settings/content/all and delete the cookies for login.microsoftonline.com
After doing that, everything was working perfectly, keep aware of that!!
Good news from Microsoft! Now we have a new feature that has been requested by many of my customers, which is to control access to portal.office.com.
You probably now that office portal is controlled by Conditional Access, but acessing to the portal itself you can gain a lot of information from this portal itself…
With this new feature, we can target multiple apps at once. Another major benefit is that when Microsoft adds another app to the Office 365 suite, it is automatically controlled by Conditional Access which is unfortunately currently not the case.
Currently the following Office 365 applications are included in the Office 365 (preview) client;
Microsoft Exchange Online Protection
Microsoft Office 365 Portal (including admin.microsoft.com)
Microsoft Teams Services
Microsoft To-Do WebApp
Office 365 Exchange Online
Office 365 Search Service
Office 365 SharePoint Online
Office 365 Yammer
Skype for Business Online
So, the advantages that we can find are:
Less Conditional Access rules needed to control access Office 365 services.
New Office 365 services are automatically controlled by Conditional Access
Portal access controlled: A scenario to test this could be to only allow access to the Office 365 apps from compliant devices. We will see that access to the Office Portal, where a lot of meta data is show is not allowed anymore from a non-managed or non-complaint device.
But also adding an Office 365 account an Office 365 ProPlus installation on a non-managed device can be blocked.
Implementing a Conditional Access scenario in Azure, involves that device Context claims are necessary for ADFS / Azure AD to determine if a device is recognized, managed, compliant, etc. We have to take into account that are used to recognize if its a known device or not.
During my experience registring Hybrid Azure AD Joined devices, I found that in Windows 7, a Workplace Joined machine is per user based and receives a device authentication certificate that is stored in the “Current User” certificate store.
In Windows 10, I found that Azure AD device registration is per machine, so we have detected blank fields in AzureAD (which is normal), I raised a support ticket and they confirm this behavior. In this case, the machine receives a device authentication certificate that is stored in the “Local Machine” certificate store.
During authentication, IE and Edge successfully use this certificate to complete device authentication. Chrome will not touch any certificates in the “Local Machine” certificate store. If using Chrome the device is not recognized, MFA fails, and the user is prompted for a secondary form of authentication.
This appears to be a known issue with alternative browsers without a suitable answer. Without device authentication occurring, a device can not be recognized for the purposes of bypassing MFA with conditional access policies.
Microsoft has provided a plug-in for Google Chrome, that allows it to perform device authentication when using MFA. However, there are a couple caveats to be aware of:
The plug-in only works for Chrome and only works with Windows 10 Creators Updates (1703) or newer.
The plugin only works for Azure AD conditional access policies.
ADFS device based conditional access policies will not work.
Relying party trusts in ADFS other than Office 365 will not be able to utilize the plugin due to the previous limitation.
Long story short, Windows 7 device authentication seems to work fine and recognized devices will support device based conditional access policies if you use Chrome. Windows 10 devices using Chrome have limited ability to support device based conditional access policies.