[MUSIC]
Jairo Cadena: Welcome back. In previous videos, we talked
about the different option you have to bring your applications
to Azure AD. Luis showed you how you can bring AD FS
apps to Azure AD via the AD FS application activity
report. In this video, I want to cover those apps that have
legacy authentication methods, like Kerberos, header based
authentication, and how you can protect them with Azure AD.
So, first of all, let me say this. Hybrid is the new normal. We
know that more and more SaaS applications, software as a
service applications, have come to the enterprise, but it is a
fact that 60-80% of applications organizations have today
are not there yet. These are applications that have legacy
methods of authentication, like Kerberos or header based
authentication. And although many of these organizations
have solid plans to modernize those applications and change
the authentication stack to talk to modern protocols, the
reality is that there’s a significant amount of applications
that are not there yet and that may not be there for long
period of time.
So, regardless of the number of applications, one need that
IT has is that they need to secure and manage these on-premises
applications while providing a great user experience.
So, many of you know about the Azure AD application
proxy; this is our native solution to allow remote access
to on-premises applications. Azure AD application proxies
have very convenient, very easy to use product that relies
on connectors on-premises to basically connect the outside
with the inside. By doing that, you can still protect these
applications with conditional access, identity protection,
and you can check sign-in logs and basically have all the
more benefits of having applications in Azure AD. So, in
addition to the Azure AD application proxy, we have partnered
with key application delivery controllers and networks like
F5, Zscaler, Citrix, Akamai, and the idea of these partnerships
is that we have integrations together where they can control
the traffic to the application while giving the authentication
traffic to Azure AD, effectively protecting these applications
behind these solutions with conditional access identity
protection, you name it.
So, something that I want to mention in addition to this is
that as we have talked about applications, we have talked
about a lot of on-premises. Right? And that’s true because
we come from an on-premises world. But what has happened is
that many of the organizations today have started lifting and
shifting these applications to the cloud, not only to Azure but
also to other clouds like Amazon, to Google cloud or private
public clouds of their choice. So, I want to say that all these
solutions that we have with the Azure AD application proxy
with these partners are really a true multi-cloud solution.
So now, you could have applications that go to let’s say
Amazon AWS cloud. Then you can put them behind an F5 BIG
IP or Azure AD application proxy and then you can control and
manage those applications with Azure AD.
So, let me actually jump in and show you how this works in
real-time. So, here I am in the Azure AD application gallery.
And if I type in search application one of the vendors with
whom we have integrated, you will be able to find the
application that belongs to that vendor. F5 is one of them.
Akamai is another one. You will find the Akamai enterprise
application access. Zscaler CPA is another one. The Zscaler
private access, this application is the one that you would
need. And then Citrix ADC, the application delivery controller,
is the one that you would use also publish applications on-
premises through the Citrix Netscaler.
Now, I have precreated an application. Let’s say it is my
expenses on-premises application that I intend to publish
via an F5 BIG IP. You can see the logo of the F5 application
and you can see the different options that I have to configure
that app. For example, who can access this application by
assigning users and groups to this app. Setting up single
sign-on is a key part of the configuration, so if I go to these
SAML settings, I will be able to identify what are the different
claims that the BIG IP will be expecting when users authenticate
to this app via Azure Active Directory. Now, on the left side,
I can go to conditional access and then I can create a new
policy that will dictate the access that is required for this
application. I can define users and groups. I can define
what different conditions do I require, like whether the
device is compliant or not, whether this access needs to
be made from specific trusted locations or not. Basically,
as if it was just Office 365 or any SaaS application, I will
be able to do with my on-premises application.
Now, let me show you what is the use and experience for
the end user. So if I go to my apps, my application portal,
this is what the user will see. It will see SaaS applications
like Box and others as well, but then it also will see the
expenses app that is an F5 application or maybe a Citrix
application, maybe an Akamai application, so let’s take a
look at this one in particular.
I see that Peoplesoft is basically an application that is behind
an F5 BIG IP APM. It’s an Oracle Peoplesoft instance that I
use for my HR activities, but it’s yet an on-prem application
protected with Azure AD available in my apps. If I click on that
icon, what happens, basically what it is is trying to
authenticate my user with Azure AD where I do that. But
then after that happens, Azure AD will issue a token to the
BIG IP on-premises to this on-premises appliance, and then
BIG IP will crack open the token, will authorize that user, and
will allow access to the Oracle Peoplesoft on-prem, which we
have here.
Well, that’s all for this series. We hope this gives you an
idea of how you can embark on your migration projects.
Please visit aka.ms/migrateapps for more information.
See you soon.
[MUSIC]