It's clear that today Microsoft is focused primarily on their cloud platform and and are pushing everywhere and anywhere possible. I was recently interrogated by a Microsoft account representative when I scoped out an on-premises approach for a single sign-on solution rather than pushing Azure AD instead.
Microsoft has introduced numerous security related features and capabilities into their cloud platform in the last several months and they are not quiet about their $1B+ annual investment into security, but they have been overlooking one significant gap: legacy authentication.
In the past with the classic Azure portal, this wasn't a problem as legacy authentication was the only type of authentication, but this changes with conditional access under the new Azure Resource Manager model.
Because conditional access is a feature within Azure AD, conditional access policies are evaluated as part of the authentication process, which results in the problem with legacy authentication.
Authentication in Office 365
Azure Active Directory is the identity provider for Office 365. As such, it is what authenticates all access to all Office 365 services as well as other integrated Microsoft cloud services.
There are two types of authentication in Office 365: legacy authentication and modern authentication.
Legacy authentication is the original form of authentication used in Office 365. Legacy authentication is HTTP Basic Authentication in which credentials in the form of a username and password combination are sent as clear text in the HTTP header, which is encrypted using transport layer security (HTTPS) to make it secure to use across the Internet.
This type of authentication occurs for the session being used to access a resource. For example, when trying to log into Exchange Online, the session is established with Exchange Online itself, which receives the credentials and performs a proxy authentication against Azure AD on behalf of the client.
Modern authentication is a claims-based form of authentication that intends to replace legacy authentication. This uses the Azure Active Directory Authentication Libraries (ADAL) and OAuth2.
Modern authentication is performed against Azure AD directly, which issues an access token back to the client that is used to access the specific resource or service.
For our purpose of comparison, the main thing we care about is that legacy authentication is performed against the service whereas modern authentication is performed against the identity provider.
Conditional Access Policy Evaluation
Conditional access policies, as mentioned above, are evaluated as part of the authentication process. Being part of Azure AD, these policies require the use of modern authentication. This is because modern authentication is performed against Azure AD directly regardless of what service or resource is trying to be accessed.
Microsoft has announced discontinued support for most legacy clients, but the challenge for them is that most mobile devices have native mail apps that are not modern authentication capable. Regardless of what Microsoft supports, what is most important is what still works with Microsoft cloud services. Just because Microsoft does not support Outlook 2010 with Exchange Online does not mean that Outlook 2010 is prevented from being used to connect to Exchange Online.
Because conditional access policies are only applied when modern authentication is used, legacy authentication can be used to circumvent all Azure Conditional Access policies.
Options to Prevent Legacy Authentication
At first, the simple approach would be to simple disable the ability to use legacy authentication. Unfortunately, this is only possible in SharePoint Online. Exchange Online and Skype for Business Online currently do not provide this ability.
For for services such as Teams and StaffHub, legacy authentication is not a concern even though they rely on the underlying core Office 365 services which still support legacy authentication. This is because clients for these services have been released post-ADAL release which means they all use modern authentication.
Exchange ActiveSync does have some controls that can be enabled through the combination of Exchange Online policies and Azure Conditional Access policies which does not necessarily prevent legacy authentication from being used, but can at least control access to data when using mobile devices.
In regards to Skype for Business Online, in my opinion legacy authentication use presents very little risk here. This is because legacy authentication may be able to be used to log into the service, but there is little data exposure through the Skype service itself. The same cannot be said about Exchange Online though as mailboxes typically contain large amounts of data, much of which may contain company intellectual property or sensitive conversations.
This means that Exchange Online is really the only significant concern. Because specific client versions cannot be blocked from accessing the Exchange Online service (outside of ActiveSync that is) this allows anyone to obtain an older version of Outlook (or even a non-updated version of Outlook 2013) to circumvent conditional access policies.
In the Azure classic model, conditional access was configured against the individual Exchange Online and SharePoint Online services. This allowed v1.0 conditional access policies to be applied when using legacy authentication clients, but because Microsoft has recently announced discontinued support for the classic model conditional access, v2.0 conditional access in the Azure resource manager model must be used.
Use Federation
When federated identities are used with Office 365 the identity provider is no longer Azure AD but the federation solution. This can be Active Directory Federation Services (AD FS) or any third-party SAML token service. When a domain is federated in Office 365, all authentication for users in the domain are redirected to the federation service for authentication instead of using Azure AD.
For example when using AD FS, client access policies can be created to provide far more granular control on authentication than in Azure Conditional Access. This includes being able to block legacy authentication specifically and require specific client versions for authentication to be allowed.
The authentication flow in the diagram above shows how AD FS can apply conditional access conditions even when legacy authentication is used to access Exchange Online. AD FS policy can detect the use of legacy authentication and deny the authentication attempt.
The obvious benefit to AD FS is this ability to prevent legacy authentication and have more controls to prevent anyone from circumventing your security, but there are some significant drawbacks as well.
For an AD FS environment, this typically consists of a highly available and highly resilient server infrastructure. With federated identities, if the federation service becomes unavailable then ALL authentication attempts for the federated domain will fail and prevent access to cloud resources. A poorly designed AD FS solution can result in an entire organization losing access to everything in Office 365 as well as any other cloud services leveraging federation.
Server redundancy is a must as well as site resiliency to prevent such outages, which can easily scale to a very complex and costly server and network infrastructure. Even the Microsoft recommended architecture for hosting AD FS in Azure virtual machines has increased significantly and may require very complicated cross-premises networking to work properly.
Use Azure MFA
Before diving too deep into Azure MFA we first need to understand a few things about the Azure MFA Service.
First, Trusted IPs are used synonymous as Named Locations in Azure Conditional Access. Trusted IPs tell the Azure MFA Service to require MFA only when connections are made from outside the corporate network.
Second is App Passwords. Older clients that cannot process the MFA challenge will fail authentication as they cannot prompt the user for the MFA requirements. This includes most legacy authentication clients. To address this, Microsoft enabled a feature call App Passwords, which are system-generated passwords that are used instead of a user password to bypass the MFA requirement for authentication. This allows older clients to still be used when Azure MFA was enabled, but I think it goes without saying that no one in the real world thought these were a good idea as it allows users to completely circumvent the MFA requirement.
There are two approaches to leverage Azure MFA. First, you can use Azure MFA within a conditional access policy to require an MFA challenge to be met when all conditions of the policy are applied. Because legacy authentication does not process conditional access policies, this approach does nothing to address our issue.
Instead, Per-User MFA must be used. This is enabling MFA on individual users within the Azure MFA Service. This makes MFA a requirement for all authentication requests unless the client is from one of the Trusted IPs defined in the service.
Because this applies to all authentication, this even applies to the proxy authentication performed by Exchange Online when legacy authentication is used.
For example, when Outlook 2010 sends credentials to Exchange Online using legacy authentication, Exchange Online will proxy authenticate to Azure AD. Azure AD will respond that an MFA challenge must be completed, which is passed back to Outlook 2010. Because Outlook 2010 cannot process this MFA challenge, the authentication fails. This applies to almost every non-web based client that uses legacy authentication (such as mobile device native mail apps).
One critical key here is that to ensure legacy authentication does not circumvent MFA, App Passwords must be disabled. By preventing users to create App Passwords, they cannot use these instead of their account password to bypass the MFA requirement.
The downside to this approach is that Per-User MFA will require MFA to be completed for ALL authentication requests outside the Trusted IPs. This would apply to mobile devices, even if the Outlook mobile app which is modern authentication capable is used. Because there is no granularity on conditions outside of location, this most likely will result in users being prompted for MFA when you do not want them to be.
Conclusion
As long as Microsoft allows legacy authentication to Office 365 it will remain the main hole in their security approach. Eventually we would expect legacy authentication to be fully deprecated and Microsoft cloud services using only modern authentication, but this may be far down the road.
From my conversations with Microsoft, there has been no indication that they intend to update the Azure conditional access capabilities to apply to legacy authentication or at least block the use of legacy authentication. SharePoint Online can disable the use of legacy authentication protocols, but Exchange Online cannot.
For organizations that can leverage Azure MFA on a per-user basis, this may be the simplest approach to preventing legacy authentication as long as granular conditions are required or end-user experience is not the top priority.
AD FS is the most flexible solution but also the most complicated. The necessary infrastructure requirements alone may deter companies from this approach, but the creation and maintenance of client access policies will also play a significant factor as well.
Given how the cloud service is configured today, if you are in Office 365 and want to fully control access to your data, you’ll need to choose one of these two evils.
**UPDATE** March 6, 2018
Microsoft has updated their road map internally to include functionality within Azure Conditional Access to block Legacy Authentication. This functionality is currently in a limited, private preview. Exact dates for when this feature will be generally available are not available, but direction from Microsoft indicates it will be "soon".
コメント