Monday, April 21, 2014

Setup of Web Application Proxy Server in Windows 2012 R2
When Microsoft discontinuedThreat
Management Gateway (which once was Proxy
and then ISA server)
I must admit I was disappointed; it was a relatively inexpensive authenticated reverse
proxy that worked with Exchange Server as well as many other complicated
products. In the interim we were told that Unified
Access Gateway would be the replacement, but that product isn't as
well suited to the task.

Several alternatives are out there, including: Kemp, F5, Nginx, and Squid
but either the price or the relative difficulty of setup isn't in line with
TMG. Fortunately starting in Windows 2012R2 Microsoft introduced Web
Application Proxy which largely fills the gap.

What is Web Application Proxy?

Web Application Proxy
(WAP from henceforth) is based on and replaces Active
Directory Federation Services Proxy 2.0. In addition to the ADFS Proxy
functionality it also introduces the ability to expose internal resources to
external users. These users can be pre-authenticated (and then impersonated
for SSO) against
your Active Directory infrastructure using ADFS prior to being allowed
access to resources.

Let's Go!

This article will cover the following:

WAP requirements

Set up

Forwarding a couple of sample applications

Troubleshooting

Software Requirements

Web application proxy is available on Windows Server 2012 R2 and higher,
and it requires
ADFS 3.0 to be available on the back end. For assistance in setting
up ADFS 3.0, see my article here.
If you would like to proxy authentication for non-claims aware
applications, I.E. Exchange OWA pre-2013 SP1 (SP1
Claims) or Kerberos/NTLM apps, you will need to have the WAP server
joined to your domain.

Additionally, you'll need the certificate (private and public key) from
your ADFS server and one certificate (again, private and public) for each
application you intend to proxy. These certificates must be trusted by
your clients, so generally external globally trusted (Digicert for
example) certificate authorities are preferred. The certificates need to
be installed under the "Personal" portion of the "Local Machine" store on
the machine you intend to use as your WAP proxy. If you only intend to
host internal resources to domain-joined computers connecting remotely you
can use an internal PKI provided your clients trust your issuing CA(s).
For information on how to setup an internal CA, see my article here.
If you need help exporting your public and private key from your ADFS
server and other services, see this
article. Note that if these certificates are marked as non-exportable you
will need new certificates for those services, so make sure you plan
accordingly.

Connectivity and Hardware/VM Requirements

Preferably, your WAP server should be placed in a De-Militarized
Zone with a firewall on either side of it. The machine
can operate with either one or two Network Interface
Cards, but for proper security I recommend two NICs; one
internal and one external. Other connectivity options will work, including
branching into your internal network on the inside interface, but I won't
be covering those scenarios in detail. For all connectivity options see
the following diagram:

As for the hardware you can use either real hardware or a VM assuming you
have a proper DMZ NIC setup on your Hyper-V/ESX/Xen/whatever host(s). WAP
is not a particularly demanding application and uses very little I/O. It
is also horizontally scalable with a network level load balancer (f5) so I
won't give direct guidance on specifications since it would likely have
little relevance to your configuration. As in most cases, performance
evaluation and configuration change is the way to go.

After deciding on your hardware and installing the OS, you'll need to
configure the NICs. We'll cover that in the next section...

Installation

Now that the hardware and OS are ready to go, let's configure the NICs:

Network Configuration

First open the "Network and Sharing Center" and click "Change Adapter
Settings". Re-name the NICs "External" and "Internal" according to how
they are connected to avoid confusion during set up and troubleshooting.

Give each NIC appropriate IP address settings. The subnet for each
will depend on your firewall/switch configuration. Some firewall
configurations may require communication stay on a single subnet but if
given a choice it is generally better to have them on different subnets.
(2 NICs) Leave the default gateway on the internal NIC blank. If your
WAP server is not domain joined because you intend on using only claims
auth or passthrough (not delegation) then leave your DNS servers blank
on the internal NIC as well and be sure to execute step 4.

If the WAP server needs to access resources (ADFS, DC, App) on a
subnet other than that the internal NIC is connected to, you will need
to add a static route to the server so it knows how to get to that
network. For example, if your WAP server is on 192.168.1.10/24, your
ADFS server is 192.168.2.5/24, and your gateway is 192.168.1.1, you
would issue the following command from an elevated command prompt: route
ADD 192.168.2.0 MASK 255.255.255.0 192.168.1.1 IF 192.168.1.10 -p .
For more information, see this
article.

<Only if you haven't specified DNS servers on the internal
NIC>To look up the ADFS server for claims verification you will need
to add each internal ADFS server address to your
%SYSTEMROOT%\system32\drivers\etc\hosts file. Do this now; if you need
further instructions see this
article.

Now we'll secure the external NIC. Open the properties of that NIC and
on the "Networking" tab unbind everything except for "QoS Packet
Scheduler" and the protocol you intend on using (IPv4 or IPv6).

If using IPv4, drill into the properties of that protocol and select
"Disable NetBIOS over TCP/IP" under the "WINS" tab. Also ensure you
disable "Register this connection's address in DNS" on the "DNS" tab.

On your external firewall, open the ports for the services you wish to
forward. (443 would be common)

On your internal firewall, open ports necessary for AD/other
communication. Here
is an excellent guide.

On "Add Roles and Features Wizard", select the "Remote Access" role
and click "Next".

You do not need to select any features; click "Next" on the "Select
features" page.

Read the dialog presented on the "Remote Access" screen and click
"Next".

Leave "Include management tools" checked and click "Add Features".

On the "Select role services" page select "Web Application Proxy" and
click "Next".

When presented with the confirmation screen, click "Install".

WAP Configuration

Prerequisite Note: For this step you will need the
public and private key for your internal ADFS server(s) installed to the
"Personal" section of the "Local Computer" store on your WAP server. For
more information, refer to "Software Requirements" above.

After installation, server manager will notify you that configuration
is required. Click the notification flag and select "Open the Web
Application Proxy Wizard".

On the "Welcome" screen of the "Web Application Proxy Wizard" click
"Next".

On the "Federation Server" screen, enter the external
fully qualified domain name of your federation service. This needs to be
registered in external DNS (i.e. resolvable from the internet).
For more information, see my article linked under "Software
Requirements". Insert the username/password of a domain administrator
account to properly register this as a proxy server. This account will not
be used after this point, so a service account is not necessary. Click
"Next".

Select the ADFS certificate you installed earlier from the dropdown
and click "Next".

You'll be presented with the configuration details. If you intend on
setting up another WAP server for load balancing copy the powershell
command down for later use. Click "Configure" to continue.

You should see the message "Web Application Proxy was configured
successfully".

Setup Verification

To verify basic functionality:

On the WAP server, open up Tools->Remote Access Management Console

On the left-hand navigation pane, select "Operations Status"

The status of the WAP server will be relayed in the middle pane. Do
not be surprised to see the server listed twice, once for the FQDN and
once for netbios. This is normal.

Now that we've completed the ADFS/WAP setup, let's walk through the setup
of a non-claims aware application using Kerberos/NTLM delegation. A
popular example would be Exchange Outlook Web Access; I'll be using
version 2010 SP3.

Prerequisite Note: For this step you will need the
public and private key for the services you wish to host (Exchange OWA in
this case) installed to the "Personal" section of the "Local Computer"
store on your WAP server. Requests destined for your back-end service are
decrypted and re-encrypted at the WAP server. For more information, refer
to "Software Requirements" above.

Trust Setup

First, we must set up the new trust on the ADFS server. On your back-end
ADFS server (not the WAP server) do the following:

Open the AD FS management tool and click the "Trust Relationships"
folder on the left hand navigation pane.

In the right hand action pane, click "Add Non-Claims-Aware Relaying
Party Trust".

A wizard will pop up; click "Start" on the welcome screen.

Give this rule a (human) meaningful name, i.e." <Servername>
Exchange OWA" along with a description if desired and click "Next".

Now we'll add the non-claims aware relaying trust party identifier
(which in this case is simply a URL). Enter the external fully qualified
domain name of the server complete with url path ending in a trailing
forward slash, i.e. https://mail.company.com/owa/ and click "Next".
Note: WAP identifiers must end in a trailing slash even though the MSFT
example doesn't look that way.

On the next screen, "Configure Multi-Factor Authentication Now?", you
can set up multi-factor authentication should you desire. I will not be
configuring multi-factor for this demonstration, but note you can always
set it up later if desired. Leave "I do not want to configure..."
selected and click "Next".

Review your configuration on the "Ready to Add Trust" screen and click
"Next".

The "Finish" screen will have a checkbox starting with "Open the Edit
Authorization Rules dialog..." that is checked by default. Leave it
checked because we will want to specify who is allowed access through to
the back-end via this rule right away. Click "Finish".

A dialog box titled "Edit Claim Rules for <Rule Name>" will come
up allowing us to define who should be allowed access via this rule.
Click "Add Rule'.

You will be asked to select a rule template. What you select here will
depend on what is reasonable for your environment. You should create (a)
rule(s) that correspond with the least access required possible as
anyone getting past this point will be able to attempt to authenticate
directly against the target internal resource. You may, for example,
want to use a specific Active Directory group with only the users that
need access to this resources. For the purposes of testing and this
article, however, I will be using a simple "Permit All Users" rule. This
will allow anyone in AD through and is suitable for testing or in
addition to other rules. Select the rule template and click "Next".

So long as you do not want any additional rules, click "OK" to close
the Edit Claim Rules dialog box.

Back-end Service Configuration

Now we need to configure our back-end service to accept the
authentication coming from the WAP server. In our case we will need to
change the authentication mechanism allowed by Exchange from forms
based to integrated authentication.Your steps here will differ depending
on what service you are offering up.

Open the Exchange management console and Click on "Server
Configuration"->"Client Access"

For each server in your Exchange farm, click the "Outlook Web App"
tab, then right click "owa (Default Web Site)" and click "properties".

Select the "Authentication" tab and click "Use one or more standard
authentication methods:" then select only "Integrated Windows
authentication".

Click "OK" on the warning.

Repeat steps 2 and 3 for the "ecp (Default Web Site)" under "Exchange
Control Panel" on each server.

Using an elevated command prompt or PowerShell, execute "iisreset
-noforce" to restart IIS. (This should be done in a maintenance
window)

Configure Delegation

Now we'll configure the WAP server AD computer object so that it can pass
authentication to your back-end server(s). Note the SPNs referenced to not
need to be manually registered at a domain level.

With domain administrator privileges, open the Active Directory
Administrative Center. (Active Directory Users and Computers if you
prefer)

Navigate to and open the properties of the WAP server computer object.

Click or scroll down to the "Delegation" section of the object.

Select "Trust this computer for delegation to specified servers only"
and "Use any authentication protocol" (since we'll be using NTLM here;
select Kerberos only for applications that support it) then click
"Add..."

When presented with the "Add Services" dialog, click "Add Users or
Computers...".

Type the name of the back-end Exchange server(s) and click "Check
Names" and then "OK"

Scroll to the http/SERVERNAME.domain.ext (since we're serving up the
HTTP protocol; change if your app differs) and select it, then click
"OK". Note: If using Active Directory Administrative
Center you need to add the FQDN
name and the NETBIOS name; if using Active Directory Users
Computers you need only add the FQDN and both will be added.

Configure Application Publishing on WAP Server

Finally we'll configure WAP publishing for this application.

On the WAP server, open the Remote Access Management Console (can be
found in admin tools or tools from Server Manager)

In the left hand navigation plane, select "Configuration"->"Web
Application Proxy"

For "Relying Party", select the trust rule we created earlier under
the "Trust Setup" section above and click "Next".

Now the meat of the settings; on the "Publishing Settings" step enter
a meaningful name for this connection (i.e. Exchange 2010 OWA), the
external URL it will be accessed by (i.e.
https://mail.company.com/owa/), select the external certificate for that
service (see "Software Requirements" above), the internal URL
(preferably should match the external but doesn't have to in all cases),
and the server SPN that we specified on the step above, then click
"Next".

You will be shown the confirmation screen with the appropriate
PowerShell command line for the options you have configured. Should you
want to repeat a similar publishing step, copy and retain this command
line for use later. Click "Publish".

The results screen will display the publishing status. Assuming all is
well, click "Close" to close the wizard.

Example B: RDP Proxy (No Pre-auth/Passthrough)

Passthrough applications are substantially easier (and less secure)
because they do not require any set up in ADFS and do not subject the user
connection attempt to any authentication before passing it on. This isn't
to say the back-end service won't require authentication, however, but it
is still less secure since you are opening your back-end service up to
processing logon requests directly from the internet.

Publish RDP Proxy on WAP Server

In this example I will publish RDP proxy direct to the internet proxied
through the WAP server. This allows me to serve up this application on the
same IP address and port as other services assuming the hostname requested
is unique. Again, this section assumes the public and private keys
associated with the URL you intend to use installed in the WAP server's
"personal" store. In my example I use a hostname of "rdp.company.com"

On the WAP server, open the Remote Access Management Console (can be
found in admin tools or tools from Server Manager)

In the left hand navigation plane, select "Configuration"->"Web
Application Proxy"

On the right hand action pane, click "Publish"

A wizard will come up. Click "Next" on the welcome screen.

When prompted for preauthentication type, select "Pass-through" and
click "Next".

On the "Publishing Settings" step enter a meaningful name for this
connection (i.e. RDProxy), the external URL it will be accessed by (i.e.
https://rdp.company.com/), select the external certificate for that
service (see "Software Requirements" above), and the internal URL
(preferably should match the external but doesn't have to in all cases).
Click "Next".

You will be given a summary of the publishing rule about to be created
and a Powershell command of it's equivalent. If you are satisfied with
the details click "Publish".

Troubleshooting

Something not working? Check out the following locations:

Event Logs

Other

Should you need to enable debug logging, there is an excellent article here
demonstrating how to do so. One word of caution, however; should you edit
the C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config
referenced therein I recommend backing it up first. If not formatted
correctly WAP will start up successfully with the values listed in the file,
but when it comes time to rotate the ADFS Proxy Trust certificate (an
automatic action that happens once every 3 weeks) the configuration of the
new cert will fail. In that case you would see an Event ID 422 logged to AD
FS/Admin stating "Unable to retrieve proxy configuration data from the
Federation Service.".