What is Legacy Authentication?
It’s that time again (the day ends in a Y) to revisit the ever present need to kill off legacy authentication wherever it has seeped into your organisation.
Working with many organisations, especially coming into a new client or prospect, it is still extremely common to find sign-in logs brimming with successful legacy authentication sessions. The longer this continues, the scarier it gets.
Legacy Authentication is most commonly seen use for reasons that include:
- Not updating client computers to current Office or ProPlus
- Only installing Windows “Security” updates on clients
- Native mobile (iOS/Android) mail/calendar/contacts clients
- Misconfigured clients (Windows/iOS/Android)
- Legacy third party service where the vendor hasn’t updated the authentication code in a decade
Just to be clear – none of the above is a supportable or sustainable reason for allowing legacy authentication.
The closest to a valid reason is the native mobile client apps, at least the contacts element. There is still something left to be desired with the integration of native contacts apps and secured clients like the Outlook client, resulting in Outlook contacts not showing when receiving a call for example.
However, all modern native clients do support modern authentication, so whilst they do not support the control and management of the data (email, contacts, calendar), they do at least support access in a securely authenticated manner.
Any organisations still running legacy OS versions of iOS (prior to iOS 11) or native Android mail apps are choosing to keep the whole organisation exposed to the most common identity/account intrusion method to save replacing these devices or changing apps. Having seen many organisations breached for exactly this reason, the risk is real, and it genuinely is a matter of when, not if.
Why is Legacy Authentication a problem?
Legacy Authentication is a very simplistic authentication, preventing any intelligence from being applied to individual sign ins to consider risk or scenarios of sign in and how to respond to that sign in.
- It only provides the user credentials
- Authentication is sent to the service being authenticated
A legacy authentication session in Azure AD looks like this
Whereas a Modern Authentication sign in provides much greater depth of information on the session
This difference makes it very easy to automate authentication attempts against service endpoints for password spray or credential stuffing attacks. If you cannot guarantee that all of your users are using unique passwords for work and not re-using one they use elsewhere for ease of use, then you can pretty much guarantee an account breach will happen.
With Modern Authentication you can implement Conditional Access and other controls to intelligently block access on breached accounts and consider the sign in risk.
How can we kill this off in our environment?
As nice as it would be to just throw the kill switch on Legacy Authentication, there may be some third party services using it, along with the risk and user pushback likely to wash over the service desk like a tsunami of irritation and indignation when all the misconfigured iPhones (especially those used by VIPs) are suddenly blocked from accessing email, calendar, contacts etc.
The first step is to identify who and what is using Legacy Authentication, and figure out if these are sign ins which are genuine user access, or indicators of compromised user account credentials.
The next step is to identify whether the genuine access is a service or similar which cannot currently support Modern Authentication (ear mark that for modernisation and/or chase up the vendor to remediate) or user access that can be remediated through client configuration.
The last step is to block legacy authentication through service configuration and Conditional Access, creating specific and tightly configured exceptions for any services which cannot immediately be moved to Modern Authentication.
Identify Legacy Authentication
Azure AD Sign in logs are the first stop here, adding the columns to the view to include information such as
- Client app
- Source IP
- MFA Result
Filtering the view to any client described as “Other..”
The first thing most people notice when doing this is just how many failed attempts there are using “Other” clients from all over the world, with China and Russia being common among the sources.
Hopefully these will be all failed sign in attempts, any showing as success are strong indicators of compromised accounts.
Beyond this simple view of the legacy authentication use and sign in attempts Microsoft provides integration with Azure AD sign in logs and PowerBI.
PowerBI provides a much nicer visual representation of where sign ins are originating, and the methods being used. This can be very useful for monitoring remediation of legacy authentication, as well as producing report materials for internal consumption.
Genuine use cases
Filtering out the failed attempts and compromised accounts we should hopefully be left with just users (or service accounts) accessing services.
This forms the basis for the next step, identifying services.
Once the legacy authentication is filtered to service accounts we can then look at the nature of the access of these.
This is also an opportune moment to spin off a separate stream to chase down the app owners for these services, or contact the vendors, to see whether they can be updated to use service principals, OATH tokens, or other modernised authentication and access methods.
Where possible switch these apps to use modern authentication methods ASAP.
If the apps aren’t immediately able to switch to Modern Authentication, we need to gather information so that we can open the smallest hole possible for Legacy Authentication use.
The limited information available for legacy authentication includes the Source IP, Account Name, and the service being accessed.
The aim here would be to filter a Conditional Access policy to only allow the defined account to use legacy authentication from the known source IP addresses, and only to the service that it needs.
In the majority of cases these apps will either originate from an organisations own datacenter on-premises internet IP, or from the vendors IP (or hosting provider), which is typically less than a handful of IPs or a single small subnet of internet IP addresses.
Creating a Conditional Access “Known Location” with the name of the app or vendor is useful here.
Once created we can configure our Conditional Access Policies along the lines of
- Users – app service account
- Application – Exchange online (all other apps to be covered by other policies requiring modern authentication)
- Application – Other Clients (select no other client types)
- Location – everywhere except a named location created for the source IP locations
- Grant – Block access
There are a few other ways to achieve this depending on the complexity of the requirements, this also assumes a general block of legacy auth policy (mentioned later).
Once genuine use cases have been identified, a selection of those will be where users can be moved to modern authentication capable alternatives.
This is where the seemingly simple quest of eradicating legacy authentication starts to reveal itself as being part of the overall modernisation of access and user experience.
The output from this report identifying genuine users, performing genuine access but still winding up using legacy authentication provides a launch pad for client modernisation.
Users with old office clients will need to be managed and migrated to using up to date applications, preferably current level Office 365 ProPlus. This may spur forward the adoption of MDM such as Intune to manage the endpoints.
Mobile devices authenticating with legacy authentication are likely using either native mail and calendar applications or are misconfigured. Whichever scenario it is for the mobile client, the result is that the access is insecure and there is no control or guarantees of security of the company data on those devices.
The best user experience and only real way to manage data controls long term is to move mobile users to the Office mobile apps, such as Outlook and Teams, again bringing in the likely need to standardise configuration through MDM such as Intune.
Block legacy authentication wherever possible!
Microsoft has now even added a baseline policy to all tenancies to block legacy authentication through Conditional Access, which at the time of writing is still in preview.
You can also configure custom policies to block “other clients” from specified services if a granular rollout is required. If your organisation can disable legacy authentication for Exchange online fully, this can be performed using an Exchange Online authentication Policy. Creating a new authentication policy by default blocks legacy authentication.
With the policy created, it can then be assigned as the default for the whole organisation.
Once this is all completed, you should be able to validate that legacy authentication is now blocked as everything except the service accounts should present failure.
How can Silversands help?
Evidently this can be far deeper than highlighted in this blog article, and is still critical to any organisations access security. Silversands can assist at all levels of these activities, bringing experience and practice to bear to provide the best possible experience for your organisation through these subtly complex activities to enable your users to access the modern workplace in a secure and confident manner.
You can also join one of our regular workshops, seminars or webinars, providing the latest updates and expert advice about Microsoft 365, Cloud and Hybrid IT, User Adoption and the Power Platform. We also post regular blogs so please do follow us.
Please do use the form below to get in touch with any questions or queries.