Setting up the First Web Application Proxy Servers (AD FS Proxy) in Windows Azure for Office365 Single Sign-On

The Web Application Proxy servers are the new way to publish AD FS to the internet. They replace the old AD FS proxy servers and are new to Windows Server 2012 R2. These servers should be deployed in a DMZ network and are non-domain joined.

Create a New Cloud Service

Because we are going to load balance one or more virtual machines, we need to create a Cloud Service to put them in. Think of it as a bucket to hold your virtual machines and to apply ACLs to secure the virtual machines. You will require one for the AD FS Servers and one for the Web Application Proxies (AD FS Proxy Servers)

 

Click New

Select Compute -> Cloud Service -> Custom Create

 

Enter a URL or Name for the Cloud Service. This name must be unique across the .cloudapp.net name space.

Select your Region or Affinity Group

Click OK

 

Create the Virtual Machine

 

Click New

Select Compute -> Virtual Machine -> From Gallery

 

Select Windows Server 2012 R2

Click Next arrow

 

Enter a virtual machine name, tier, size, username and password

Click Next arrow

 

Select the cloud service you created above

Verify Virtual Network

Create an Availability Set

Click Next arrow

 

Click the complete checkmark

 

Let the process configure the virtual machine. Once completed, log into the server and continue with the next steps.

 

 

Configure the Primary DNS Suffix

 

Open Server Manager

Click the Computer Name

 

Click Change

 

Click More…

 

Enter your public domain as the Primary DNS suffix of this computer

Click OK

 

Click OK

Reboot

 

Install Web Application Proxy Role

 

Open Server Manager

Click Manage

Click Add Roles and Features

 

Click Next

 

Click Next

 

Click Next

 

Select Remote Access

Click Next

 

Click Next

 

Click Next

 

Select Web Application Proxy

Click Next

 

Click Add Features

 

Click Next

 

Click Install

 

Installing

 

Click Close

 

Import the SSL Certificate

AD FS uses certificate to secure the connection from AD FS to Office365. For this reason, we need a valid SSL certificate. I choose to use GoDaddy, as I find they are a one stop shop for all my domain needs. It’s a personal choice, so use whoever you feel comfortable with. For the purposes of this BLOG post, I will use a multi-name certificate; I DON’T recommend this for a production environment. A couple reasons are that I like to keep things simple and if we have multiple names on the certificate, it starts to get complicated (not technically, but management of the certificate). Secondly, I don’t like to share certificates across services. This cuts down on the cross contamination from the support teams at larger companies. If you lump the AD FS services with the Exchange certificate, AD FS usually gets left in the dust and forgot about when it comes time to renew.

 

Open the Start Screen


Type MMC

 Click the MMC app


MMC opens


Click File

Click Add/Remove Snap-in

Select Certificates

Click Add>


Select Computer Account

Click Next


Select Local Computer

Click Finish


Click OK


Expand Certificates

Expand Personal

Right Click Certificates

Select Import


Select Local Machine

Click Next


Browse to the Exported Certificate

Click Next


Enter Password

Mark the key as exportable

Click Next


Place in the Personal certificate store

Click Next


Click Finish


Successful


 

 

Edit HOSTS File

Because we need to make contact back to the AD FS servers, we need to tell the WAP servers how to get to them. The simplest way of doing this (and not opening more FW ports) is to edit the local HOSTS file on the WAP server. Keep in mind that we don’t have connectivity or the ability to route to the internal IP address, so we need to route to the external IP of the Cloud Service that holds the AD FS servers.

 

Complete in Azure

 

Click Cloud Services

Click the Cloud Service for your AD FS Servers

Make note of the Public Virtual IP (VIP) Address

 

Complete on WAP Server

 

Right Click Notepad and Run as Administrator

Navigate to c:\windows\system32\drivers\etc

Switch view to All Files

Open HOSTS

Edit HOSTS file with the AD FS Farm Name and the external IP Address of the AD FS Cloud Service

Click File -> Save

Close Notepad

 

Setup Azure ACLs to Allow the WAP Servers to Communicate with the AD FS Servers

Since we are on separate networks (from the Internal Network) we also need to make sure that we have configured Azure ACLs to allow the WAP servers to communicate to the AD FS serves on the internal network. Please review this BLOG post to complete that task.

Securing the AD FS 3.0 servers and Configuring Azure ACLs for WAP Communications

 

Configure the Web Application Proxy Role

 

Open Server Manager

Click More… Configuration required for Web Application Proxy

 

Click Open the Web Application Proxy… under the Action column

 

Click Next

 

Enter the Federation Service Name

Enter Credentials for a local administrator on the AD FS servers

Click Next

 

Select the SSL certificate that you imported earlier

Click Next

 

Click Configure

 

Setting up the WAP server

 

Success

Click Close

 

At this point the WAP server is functioning. To test the WAP server, you can edit your local workstation hosts file to point at the external IP of the WAP cloud service. This will allow you to test the configuration without editing global DNS.

Continue on to the rest of the series where we will add a second WAP server and then load balance the two.

 

My BLOG Series

Deploying a Highly Available AD FS 3.0 Solution in Windows Azure for Single Sign-on with Office365

  1. Setting up the Primary AD FS 3.0 Server in Windows Azure for Office365 Single Sign-On
  2. Setting up the Secondary AD FS 3.0 Server in Windows Azure for Office365 Single Sign-On
    1. Configure the AD FS Servers in an Internal Load-Balanced Set in Windows Azure for Office365 Single Sign-On
    2. Configure the AD FS Servers with Azure Load Balanced Set in Windows Azure for Office365 Single Sign-On
  3. Securing the AD FS 3.0 servers and Configuring Azure ACLs for WAP Communications
  4. Setting up the First Web Application Proxy Servers (AD FS Proxy) in Windows Azure for Office365 Single Sign-On
  5. Setting up the Second Web Application Proxy Server (AD FS Proxy) in Windows Azure for Office365 Single Sign-On
  6. Configure Endpoints and Test the Web Application Proxy Servers (Load-Balanced Set in Windows Azure) for Office365 Single Sign-On

Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment or email me with what you would like to see.

Kelsey Epps Office365 MVP

Technical Consultant

Concepps Group

Email Me Follow me on Twitter Connect with me on LinkedIN

4 thoughts on “Setting up the First Web Application Proxy Servers (AD FS Proxy) in Windows Azure for Office365 Single Sign-On

  1. PJ

    Nice Post! I have one question. Since I see no publish rule how do you test prior to setting up a relying party and publishing via the WAP?

    Reply
    1. Kelsey EppsKelsey Epps Post author

      At the bottom it walks you through setting up ACLs on the ADFS server to allow only traffic from the WAP server. This can be tested with telnet, from the WAP server, to the ADFS server public IP

      Reply
  2. Bajouras

    I dont understand why you add the WAP server to the domain, doesn’t that go against the whole purpose of a WAP Proxy??? This way, the WAP server has read access to Domain Controller, DNS, etc.

    It should work fine with a WORKGROUP, editing the hosts file should be enough to point WAP to ADFS server.

    Reply

Leave a Reply