Hello, Cloud Gurus, and welcome back
for this lesson where we're going to take a look
at providing access to legacy applications.
Before we begin though,
what exactly are these legacy applications
that I'm referring to?
Well, these are applications that typically run
on-premises or in a virtual machine
and require Active Directory Domain Services
for authentication.
Or, they might not have any authentication at all
and rely on someone being connected
to a trusted internal network.
And if you want to allow remote access
to these applications, you have a couple of options.
So let's take a look at what we're going
to cover first up in this 2-part lesson.
I'll introduce Web Application Proxy
and then we'll explore how Web Application Proxy works
and then we'll wrap up with a demo of Web Application Proxy.
Let's jump in.
So what is Web Application Proxy?
Well, Web Application Proxy is a remote access
service provided by Windows Server
and it's used to provide access to web applications
that are hosted on your corporate network
from devices outside of your corporate network.
And of course you can provide this type of remote access
to your internal applications using something like a VPN.
But Web Application Proxy does not require a VPN
and sometimes you'll want your users
to access internal applications
without needing to install additional software,
for example, if you want to allow your users
to bring their own device.
Web Application Proxy doesn't require any software installs
on the remote devices or configuration
of that remote access device.
And Web Application Proxy works
with Active Directory Federation Services
to authenticate and authorize users
when they attempt to access these internal applications.
ADFS also provides single sign-on
and some multifactor authentication
and authorization capabilities.
Now defense in depth is a cybersecurity approach
designed to protect data and applications.
Web Application Proxy,
when deployed according to best practices,
assists in providing defense in depth
by terminating connections from the internet
and reestablishing the connection
to the application on the internal network.
Web Application Proxy with ADFS also has the capability
to authenticate both users and devices.
Couple Web Application Proxy with ATFs
and both internal and external firewalls
for maximum protection.
So how does Web Application Proxy work?
Well, let's take a look at that now.
Let's say you have a web application
on your internal network that uses
Integrated Windows Authentication to authenticate users
from your Active Directory domain.
And normally, staff would use their
Active Directory credentials to access this application
from a trusted device on the internal network
that would authenticate against a domain controller
at log-on from a domain join device
and then access the web application.
And all of this would be transparent
to the user accessing the application.
And now your staff want to be able to access the application
from their own personal devices without having
to install additional software on their devices.
And because they're using personal devices,
you definitely do not want these devices
to have any additional access
to the internal corporate network.
To provide access to this application,
you can install Active Directory Federation Services
on your internal network
and a Web Application Proxy in your perimeter network.
And in a deployment that follows best practices,
your Web Application Proxy will be deployed
between a pair of firewalls,
an internal firewall and an external firewall.
Your users will attempt to access the application
using a fully qualified domain name
that can be resolved using DNS from outside your network.
And this DNS name will resolve to an IP address
that will direct users to your Web Application Proxy.
And this might be a forwarded port on the external firewall
or less commonly, a directly associated public IP address
on the Web Application Proxy server.
The Web Application Proxy will authenticate the user
using Active Directory Federation Services,
which will validate the user's credentials
against the domain controller
and may perform additional authentication
like validating a client certificate.
And once authenticated and authorized,
the Web Application Proxy provides access
to the application for the user terminating
and reestablishing the connection in the perimeter network,
so there is no direct connection
from the internet to your internal network.
Now I expect that in your role as a hybrid administrator,
I don't think it's likely you will deploy
a new Web Application Proxy setup like this.
In my opinion, it's far more likely
that you will need to support an existing deployment
and potentially migrate it or upgrade it.
So with that in mind, let's take a look at a demo
of an existing Web Application Proxy deployment
and the components that are involved.
In this demo, Barrier Reef Audio
has a time-tracking application
that staff use to log their time on particular tasks.
The time is then billed to clients,
so it's critical that staff can access the application
so the company can remain profitable.
And the time-keeper application
uses Integrated Windows Authentication
to provide single sign-on when it's accessed internally
using the Active Directory domain
and it's accessible using the URL,
timetracker.corp.barrierreefaudio.com.
and a request was made to allow access
to this application externally.
So staff can record time on site
without needing to establish a VPN connection
or log their time on a company device.
Staff should be able to access the application
using the external domain name,
timetracker.barrierreefaudio.com.
To support this capability,
they've deployed Active Directory Federation Services
internally and a Web Application Proxy
in the perimeter network.
In this demo, we will explore
the Web Application Proxy configuration
so you can familiarize yourself with how it's configured.
We'll also explore the ADFS configuration
as the Web Application Proxy depends on ADFS
for authorization and authentication.
And then we'll test the application both internally
and externally so you can see how it works.
Let's take a look.
All right, so here we are
on our Web Application Proxy server
deployed in our perimeter network.
Web Application Proxy is configured
using the Remote Access Management console
in Administrative Tools.
So we'll go ahead and launch Remote Access Management
and we can see that we're in Web Application Proxy
and we've navigated to Published Web Applications.
And we can see that we have a
Time Tracker application published here
and it has both the external URL
of timetracker.barrierreefaudio.com
and the backend internal URL
of timetracker.corp.barrierreefaudio.com.
Now let's quickly take a look at the process
of publishing a web application.
We'll go ahead and click Publish,
we'll go ahead and select Next,
and you can see here that you can configure
Active Directory Federation services
to pre-authenticate your users before they're allowed
to access the internal application.
And it's important to know
that Active Directory Federation Services pre-authentication
is required when you're using
Integrated Windows Authentication applications.
And this allows the Web Application Proxy
to use Kerberos delegation to grant access
to the backend web application.
We'll go ahead and click Next
and we'll go ahead and skip past the clients.
Now, the relying party is configured
in Active Directory Federation Services
and it contains the authorization
and authentication settings
for the published web application.
And the published web app trusts
Active Directory Federation Services
to handle the authentication.
So we'll go ahead and select our relying party
and we'll go ahead and click Next.
And then the final step to publish a web application is
to configure a name for the application,
an external URL, which needs to be resolvable
from outside of your internal network
and you'll need to provide an external certificate
to secure the traffic,
and you can enable HTTP to HTTPS redirection
to automatically redirect non-secure web traffic
to secure web traffic.
And then you just need to provide your backend server URL,
which is the internal URL for your web application.
And to support Kerberos delegation,
you need to provide a service principle name
for your backend server.
We've already configured our web application
to be published, so we'll go ahead and click Cancel.
Now that we have our Time Tracker application published
and Active Directory Federation Services
handling the authentication, let's jump across
to our Active Directory Federation Services server
and take a look at how
Active Directory Federation Services is configured.
All right, so here we are
on the Active Directory Federation Services server
on our internal network.
We'll go ahead and launch ADFS Management
and then we'll take a look at the Relying Party Trusts
and we can see, we have that Relying Party Trust configured
that we were using from our Web Application Proxy.
Let's take a look at the Access Control Policy
for this Relying Party Trust.
We'll select Edit Access Control Policy,
and you can see here that you are able to configure things
like allowing access for only a specific group
or configuring access using multifactor authentication.
All right, now that we have
the Web Application Proxy configured
and Active Directory Federation Services configured,
let's jump across to a client computer and test access.
All right, and here we are logged onto our client computer
and you can see we're logged on as a domain user, Alice.
Now let's go ahead and try and access
that Time Tracker application using the internal URL.
Go ahead and paste the internal URL into Edge.
And we can see that the web application
uses Integrated Windows Authentication
to provide an awesome authentication experience
and automatically provide access
to the web application using the domain user's credentials.
Now let's go ahead and try
and access the web application using the external URL.
And this would simulate us being
outside of the internal network.
We'll go ahead and access the external URL.
And because we are outside the network,
we're being asked to authenticate
by Active Directory Federation Services
before we can access the app.
Let's go ahead and log in as our test user, Alice,
and we can see that Active Directory Federation Services
provides a Kerberos ticket to the Web Application Proxy
and the Web Application Proxy uses Kerberos delegation
to access the web application as Alice.
Now, what this demo doesn't show is the complexity
in setting this sort of application up.
There are a number of configurations required in DNS,
including potentially split-brain DNS
that we spoke about earlier in the course
as the Active Directory Federation Services
fully qualified domain name
should be the same both internally and externally.
You'll also need a number of certificates
for your web servers,
Active Directory Federation Services,
and the Web Application Proxy.
And if you're using Integrated Windows Authentication,
you'll also need to configure Kerberos delegation
so your Web Application Proxy can delegate credentials
to the web app server.
So you can see all of those foundational building blocks
from earlier in the course coming together
with these sorts of solutions.
But because of this complexity,
if you're in a hybrid environment,
there is a newer and frankly better alternative
for new deployments, or if you want to migrate
from this sort of deployment and reduce the number
of servers that operations teams need to manage.
But we'll explore that in the next lesson.
So for now, let's wrap up with a bit of a summary
of what we're covered in this lesson.
All right, so what have we covered?
Web Application Proxy can be used to provide remote access
to on-premises web applications.
And Web Application Proxy requires
Active Directory Federation Services
as all Web Application Proxy configuration data is stored
in the Active Directory Federation Services configuration.
And Kerberos delegation is used to access web apps
that use Integrated Windows Authentication
using Web Application Proxy.
This means you'll need to domain-join
your Web Application Proxy servers
and this might cause some issues
when you're working with your internal security team.
All right, thanks for being with me in this lesson.
I hope you found it useful and I'll look forward
to seeing you in the next lesson for part two.