[MUSIC]
Adwoa Boateng-Kwakye: Welcome back to Azure AD
Architecture Deep Dive Series. I am Adwoa Boateng-Kwakye
and I’m a Program Manager on the Azure AD Engineering
team at Microsoft.
Adrian Paredes: And my name is Adrian Paredes and I’m also a
Program Manager in the Azure AD Engineering team at
Microsoft.
Adwoa: Our customers often ask, how does legacy authentication
work? Why is it so bad? And what key parts of the process do
they need to be aware of?
In this video, we will discuss the flow of legacy authentication
from start to finish using federation with Azure Active
Directory. Then we will cover legacy authentication flows
using managed authentication.
Adrian, can you walk us through how legacy authentication
works with federation?
Adrian: Sure. First, we start from the application on the
client machine, let’s say Outlook 2010 or an older version
of Outlook. For example, when you open your email, the
first thing it does is check with Office 365’s Exchange Online
service, using basic authentication to see if the session is
still active, as illustrated here in step 1.
Next, on step 2, the Exchange Online service then calls out
to Azure AD for the tenant configuration and to verify if it’s
federated or not using a process called home realm discovery
to fill in which domain you’re logged in with. Once it verifies
that you’re federated, Azure AD lets the Exchange Online
service know to go to a set endpoint previously defined in
Azure AD based on the original configuration of federation
with an authentication request, as illustrated here in step 3.
The federation server then contacts a domain controller to
verify the username and password calling Windows native
APIs for that user and sends it back to the Exchange Online
service. From there, the Exchange Online service sends the
SAML searching token to the Azure AD authentication service.
From here, Azure AD attempts to authorize a token from the
federation server and also evaluates conditional access
policies, which for legacy authentication only allows blocking.
Upon authorizing the user to access Azure AD protected
resources, such as Exchange Online, Azure AD issues a token
and returns to the Exchange Online backend service. And this
is strictly a server to server interaction. Now that Exchange
Online has a valid token for the user, it returns the specific
content to the user, in this case, the user’s email.
Adwoa, what happens if you don’t use federation but use
managed authentication instead with legacy auth? Could
you tell us how that works?
Adwoa: Absolutely. The managed authentication flow is very
similar to federated auth, but instead of the validation against
federation service, we take the username and password and
validate it directly in Azure AD, as we saw in the previous
videos.
We start with a user launching on Office 365 application. Again,
in this case, we use Outlook 2010 and Exchange Online.
The initial request goes to Exchange Online. Exchange
Online then calls Azure Active Directory for the tenant
configuration, which then verifies it’s managed. The user
is then prompted for their username and password through
basic authentication. Exchange then sends their credentials
to Azure AD for verification as illustrated here in step 3.
Like federated authentication, the user is then evaluated
against conditional access and identity protection policies for
authorization. Upon completion of authorization, Azure AD
then issues the token back to Exchange Online, which in
turn allows access to the email for the requesting user.
Adrian: I have a question, Adwoa. What exactly makes legacy
authentication bad?
Adwoa: Legacy authentication is bad because there’s no way
to protect this with MFA or anything else. It is also the
most used interface for attackers to break into environments
using password spray, breach replay, and other techniques.
As a result, Microsoft recommendation is to block legacy
authentication. Adrian, what is the best way to block it?
Adrian: It is critical to block legacy authentication, which you
can do via conditional access policies. But you also need to
block legacy authentication at the Office 365 service, in this
case, Exchange service to block the request is step 1, as this
is pre-authentication. This goes to federation as well as
managed authentication. In addition, federated servers can
also create policies that block legacy authentication.
Adwoa: Also, when you’re using legacy authentication,
please note that it is not capable of using true MFA. This
means if you set a conditional access policy to require
Azure MFA and the app is using legacy all, it will now be
able to process it the same way as if you were using a
modern auth application. Modern authentication is a
much better solution using either federation or seamless
single sign-on with password hash sync or passthrough
authentication, especially when you consider its security
improvements.
Adrian: Here are the key takeaways. First, it’s important to
understand that legacy authentication is simply not capable
of using MFA, as it cannot handle that level of complexity.
Despite any MFA policies you have, legacy auth will simply
ignore it.
Second, because the limitations of legacy authentication, this is
far and away the most targeted point by attackers, who
typically use password spray or breach replay attacks.
Next, you need to understand the impact of blocking legacy
auth in your environment. How many 2010 Office apps are
you using? But the bigger, more likely question is is how
much are you currently using Exchange active sync?
Finally, you need to block all legacy auth in your environment,
especially non-modern auth Exchange active sync.
This needs to be done with conditional access policy but also
blocking at the service level, such as Exchange Online service
using a multitude of tools such as client access rules to block
legacy auth to prevent it from trying to authenticate.
Remember, pre-authentication is at the service level while
post-authentication is done via conditional access.
Adwoa: That’s great, Adrian. Thanks for sharing that with us.
Thank you for watching this video. Be sure to check out our
other architecture videos at aka.ms/identityyoutube. Thank
you for joining us.
Adrian: Thank you.
[MUSIC]
