WAP on 2016 for Office 365 Part-2-3

This is the second in a series of three posts which will walk you through installing, configuring and connecting AD FS 2016 to Office 365.  In part one we installed the AD FS server on our corporate network, and tested that it was working.

In this second post we need to make the AD FS infrastructure available to the Internet in a secure fashion, so that Office 365 will be able to contact AD FS to authenticate user requests.  Previously this meant downloading and installing the AD FS 2.0 Proxy onto servers in the DMZ.  In AD FS 2012 R2 onwards, the AD FS proxy functionality is present in the Web Application Publishing (WAP) component of the Remote Access role.  There is no separate download required in modern versions of Windows.

In part three of this series, we will integrate the AD FS infrastructure with the Office 365 configuration.

The outcome achieved at the end of this post is the below solution.  Note that the AD FS servers are domain joined an located on the corporate network.  Windows 2012 R2 and newer contain the AD FS Proxy as part of the OS, specifically within the Remote Access role.  For the purposes of using AD FS for Office 365 we do not need to domain join the WAP servers.  They are able to provide AD FS proxy functionality as workgroup machines.

Planning And Prerequisites

Install And Configure AD FS Proxy OS

In this installation, the AD FS proxy server will be placed into the DMZ, and installed as a workgroup machine since the Wingtiptoys organisation does not possess a separate management forest in the DMZ.  Ensure the machine is built as per your standard build process, is secured and all Microsoft updates are installed.  Since AD FS and WAP are now a core part of the OS, they are serviced and maintained using Windows Updates.

Install  And Verify Certificate

As discussed in part one, you will need a certificate from a trusted third party.  Ensure that you check with the CA to ensure that you are able to install the certificate onto multiple servers as this is blocked in some license agreements.  This is something that you must check directly with the CA.

If you are allowed to install the certificate from the AD FS server, then this simplifies matters else you will require an additional certificate.  The name must match the AD FS namespace that you selected through the AD FS design process.  By using the exact same certificate this allows the following features to be enabled:

• ExtendedProtectionTokenCheck to be enabled on AD FS.  It is enabled by default.
• WAP can proxy AD FS requests that use Windows Integrated Authentication

Name Resolution

Since the AD FS proxy server[s] will be in  a network which may not have access to the internal DNS zone information, ensure that WAP is able to resolve the AD FS namespace to the internal AD FS infrastructure.  Typically this will point to the VIP of the internal AD FS load balanced endpoint.  A swift update to the local hosts file may suffice, just remember to add this to your build documentation.  In some cases you way need to set a DNS suffix in the system properties or in the IP configuration.

External DNS Record

Create external DNS record for the AD FS proxy server.  This A record will exist in the external DNS zone.  In the Wingtiptoys enterprise (cough, cough this lab) the internal DNS zone is held on AD integrated DNS zones.  The external zone is at a commercial ISP, so the external DNS record was created at the commercial ISP so it resolves to the external IP of the AD FS proxy infrastructure when I am at Starbucks.

As with the internal AD FS farm, there should be multiple WAP servers in the DMZ.  They should be load balanced, and the DNS record should resolve to the VIP.

Open Firewalls

Having the external DNS record point to the AD FS server’s external IP address will not allow traffic to flow unless the firewalls are configured to do so.  In enterprises the AD FS proxy server will be installed into a DMZ so there will be an internal and external firewall.  Both must be opened to allow inbound SSL traffic over TCP port 443.  In addition to this, the servers will also need access to the CA’s CRL distribution points on the Internet to verify certificate validity.

Exchange administrators should be used to this now as they have see Exchange updates take a long time to install on Exchange servers do not have access to crl.microsoft.com.  In the case of AD FS, the server should be able to hit the CRL of external CAs.  Each vendor has their own endpoints.

The AD FS server will require access to the Internet in order to complete the configuration of the solution (in the 3rd post of this series).  This may be an issue if your servers are behind a proxy solution.

Installing Web Application Proxy

First we will go through the graphical install process, then review the PowerShell commands to install the necessary role services and then to configure WAP.  There are two discrete tasks which are to be performed.  The Remote Access role with with the Web Application Proxy service must first be installed, and then it can be configured.

Let’s fire up the Add Roles Wizard from Server Manager!

As noted in the previous post, there is no longer a separate AD FS proxy role in Windows 2016.  The Remote Access feature provides VPN, Direct Access and Web Application Proxy (WAP) functionality.  It is the latter that we need to install.

Select Remote Access and let’s go find the droids we are looking for…

Unless you want to add any features, like telnet * for troubleshooting purposes later, click next.

The Remote Access role selection process starts.  Unlike in days of old when installing a feature would install all of the bits, and by extension potential vulnerabilities, Windows now wants to only install the bare minimum.  This is a paradigm shift compared to the early days of IIS where it would install everything and then you have to spend time stripping stuff back out.  Index extension attack anyone?

In our case we just want to install the Web Application Proxy role service, so select that and click next

Confirm the choice, and then install.

Once the necessary WAP role services are installed, we are then able to launch the Web Application Proxy Wizard to configure WAP.

The installation process will complete, click to close the wizard.

Configure Web Application Proxy

We need to configure the WAP proxy with the necessary information so that it knows it will be publishing our internal AD FS server and how to access AD FS.  Under administrative tools, open the Remote Access Management console.

Select the Web Application Proxy role which is listed on the left hand pane, and then the option to run the Web Application proxy configuration wizard will be displayed.

The wizard will then initiate the process to configure the Web Application Publishing service.

The screen below is where most configuration issues arise with this process.  What a lot of folks do is interpret the Federation service name as the display name of the AD FS server.  That will not get you very far unfortunately…

The federation service name field does NOT want you to enter the display name of the AD FS server farm.   The display name in the previous example was “Wingtiptoys STS”. and this can been checked by looking in the AD FS console on the AD FS server itself.

If you look closely at the AD FS properties, the federation service name is actually the FQDN of the service.  In our case this is sts.wingtipyoys.ca so let’s enter that along with administrator credentials on the AD FS server so we are able to access AD FS.

In the same way that we require a SSL certificate on the AD FS server, the same is true on the WAP as clients will establish SSL sessions to this machine.  WAP will then us a SSL session to the internal AD FS server on TCP 443.

Since the certificate was previously installed and verified as part of the preparatory work, we select it and move on.

Verify the details, and click configure.

The wizard starts to configure the AD FS proxy

And shortly thereafter completes!

Installing Web Application Proxy Using PowerShell

In the vein as the graphical installation, there are two discrete tasks which are to be performed.  The Remote Access role with with the Web Application Proxy service must first be installed, and then it can be configured.

Install Remote Access – Web Application Proxy

The below command will install the necessary OS components for the Remote Access role.

Configure Web Application Proxy Using PowerShell

Once the OS components have been installed, they must be configured.  Note that you require the correct certificate thumbprint, and the command will prompt for an account which has administrative permissions on the AD FS server.

 

Verifying AD FS Proxy Installation

At this time we should have a functional AD FS proxy server that is able to provide internet based users with access to our AD FS server’s authentication services.  But as always, we need to test!

To open up the Remote Access management console, use the Remote Access Management shortcut in administrative tools.

If you have immediately launched this after installing the AD FS proxy it may take a few seconds or a refresh to show up.  The other top tip is not to look for a published web app.  Remember that WAP can be used to publish various applications to the internet, but in this case we are just wanting to use the base AD FS proxy components.  No further configuration is required.

To check that the AD FS proxy is running, click onto the Operational Status in the left hand tree

Selecting the operational status, will then show how the AD FS proxy is currently running.  You can also jump to Perfmon or Event Viewer from this node.

Should the AD FS proxy have an issue the console will light up like a Christmas tree.  In this case I deliberately stopped the “Active Directory Federation Services” service on the AD FS proxy, please click to enlarge the image:

Even though the Windows service is name the same on both the AD FS server and the AD FS proxy, note that the executable path is different:

WAP

AD FS

Verify AD FS Proxy Configuration

In event viewer on the AD FS proxy, open up the application and services logs and check that the proxy is able to retrieve it’s configuration from the AD FS server.  This can be seen here, click to enlarge:

With the full EventID 245 details shown here:

Verify Federation Service Metadata

Using the same URL as before, open Internet Explorer and navigate to your AD FS server’s federation metadata URL.

This will be something like the below, just change the FQDN to match your environment.

https://adfs.tailspintoys.ca/federationmetadata/2007-06/federationmetadata.xml

https://sts.wingtiptoys.ca/federationmetadata/2007-06/federationmetadata.xml

The intent here is to ensure that we are able to get to the site externally.  If you are not able to see the AD FS text rendered in the browser, start with ensuring that the firewalls are not dropping traffic.

Verify AD FS Sign-In Page

Browse to the AD FS sign-in page and test that you are able to authenticate.

The URL will be similar to the below, again change the FQDN to match your organisation’s.

https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm

https://sts.wingtiptoys.ca/adfs/ls/idpinitiatedsignon.htm

You should see the below, and be prompted to sign in:

(Note that I did not full screen the window before grabbing capture else it would be too small)

Clicking the Sign In button will prompt for credentials:

If you successfully authenticate then you will be rewarded with this stellar screen:

And if are unable to type a password (like me doing demos) then you will get this less than stellar result:

In part three we will complete the configuration, and instruct Office 365 to leverage the shiny AD FS infrastructure to authenticate users.

Cheers,

Rhoderick

=========================================================

Here we are in part three already!  Previously we completed the below two phases in the AD FS deployment.

How To Install AD FS 2016 For Office 365

How To Install AD FS 2016 For Office 365 – Part 2

This post assumes that the domain was previously added as a standard domain, also called managed, and the domain will require conversion. Now we want to change the Office 365 domain to be a federated domain.  As discussed in part 1, this means that all of the users who authenticate using this domain will become a federated identity and the on-premises AD FS and AD DS infrastructure is responsible for authenticating these requests.

Importance Of AD FS When Office 365 Relies Upon It

Before we discuss the integration of Office with the on-premises AD FS infrastructure, let’s just again be clear on the criticality of ensuring that AD FS is available when the Office 365 domain is set to use AD FS authentication.  For whatever reason if the AD FS infrastructure is unavailable, then Office 365 cannot complete the authentication process and thus users cannot get access to Office 365.  This will cause a service impacting outage that will require resolution from you, not Microsoft’s online services team.

For this reason, unless you really need to leverage AD FS please review the Azure AD Connect password hash synchronisation feature.

Apologies if I sound pessimistic, but I don’t want to obviate the requirement for AD FS redundancy!

AD FS in Azure

On the topic of AD FS redundancy one option is to also host a portion of your AD FS infrastructure in Azure.  This is a perfect solution if you do not have sufficient capacity in your current datacentre, or your datacentres are located in close proximity of each other and a major incident would take both of them down.

There is a whitepaper published for this exact scenario. Please check this link. The documentation covers three main scenarios to meet the situations discussed above:

• Scenario 1: All Office 365 SSO integration components deployed on-premises. This is the traditional approach; you deploy directory synchronization and Active Directory Federation Services (AD FS) by using on-premises servers.
• Scenario 2: All Office 365 SSO integration components deployed in Windows Azure. This is the new, cloud-only approach; you deploy directory synchronization and AD FS in Windows Azure. This eliminates the need to deploy on-premises servers.
• Scenario 3: Some Office 365 SSO integration components deployed in Windows Azure for disaster recovery. This is the mix of on-premises and cloud-deployed components; you deploy directory synchronization and AD FS, primarily on-premises and add redundant components in Windows Azure for disaster recovery.

 

This is an example of hosting AD FS in Azure for DR purposes:

 

 

AD FS is supported for deployment on Azure Virtual Machines, but there are AD FS best practices that require technologies beyond what AD FS offers itself, such as load balancing/high availability.  In addition to this please also consider the pricing for running this IAAS.  Read through the deployment caveats in the AD FS Azure documentation above and also the additional discussion points here.

Updating AD FS

Back to the business at hand – updating Office 365 so that it now uses your on-premises AD FS server! To do this we will need to leverage the Azure AD PowerShell cmdlets.

In the previous posts we reviewed the required pre-requisites.  One to circle back on was that the AD FS servers will require Internet access to complete the configuration with Office 365.  This will require outbound access on HTTP and HTTPS using ports TCP 80 and 443 respectively. If this is not open, then you will receive an error.

Note that at the time of writing there are two modules for administering Azure AD.  Currently the V1 and V2 modules are available, which are separate modules and installations from one another.  The V1 module is called MSOnline and the V2 is called AzureAD.

Azure Active Directory V2 General Availability Module overview information can be found here.  For detailed information on how to install and run this module from the PowerShell Gallery including prerequisites, please review this.

 

Currently not all of the V1 module commands are present in V2.  This gap will be closed over time.  While some tasks need to be accomplished using the V2 module, this post will use the V1 module.   The below is an example of the V2 module.  We can see the name of AzureAD and its version using the below cmdlets:

 

We can get the V1 module from Quick Tip: Is There A Shortcut URL To Download Azure AD PowerShell.  Select the Azure Active Directory Connection download page download, and scroll down to the bottom of the page.  Download and install the V1 MSI installation file.  At the time of writing this was version 1.1.166.0.

To run the Azure AD cmdlets we can launch the module by either:

• Using the automatically created shortcut
• Manually importing the MSOnline module into a regular PowerShell session

 

The shortcut to the Azure AD module can be found under administrative tools, and also on the desktop.  It should be listed as “Active Directory Module for Windows PowerShell”.

In order to manually import the Azure AD V1 module we can run the below in PowerShell:

Rather than having to type that, in this case we will run the shortcut to the Active Directory Module for Windows PowerShell on a domain joined server on the corporate network.  For reference this machine is DC-2.wingtiptoys.ca, and the primary AD FS server is ADFS-2016-1.wingtiptoys.ca.

Using Connect-MsolService let’s connect to our Azure AD instance.  Note that the user interface for providing credentials has changed in the later builds of the MSOnline module.  Provide a set of global admin credentials:

We can see the current status of the domains within this tenant.  the Get-MsolDomain cmdlet will show the domains, and we are interested in the first domain – “Wingtiptoys.ca”.

Before we can execute the Convert-MsolDomainToFederated cmdlet, we need to also a hook into the local AD FS server (not the AD FS proxy) so that we can configure it.  It is possible to skip this step by installing and using the module on the primary AD FS server itself.

We connect to the AD FS server using the Set-MsolADFSContext cmdlet. Like the other MSOL cmdlets, this one is as unforgiving.  If you forget to explicitly use the required parameters the MSOL cmdlets typically do not prompt like the Exchange cmdlets do.  Because of this I have a habit of always specifying every option and not relying on PowerShell to prompt for required options that were missed.

Once we have connected to the AD FS server, we use the Convert-MsolDomainToFederated cmdlet to convert the Office 365 domain from Managed to Federated.

An area of concern should be noted here for customers that have multiple top level domains.  Back with early AD FS 2.0  builds customers with multiple top level UPNs had to deploy separate AD FS instances for each domain suffix.  A rollup was added to assist with this and the SupportMultipleDomain switch.   Please see here for more details if you have multiple sign-on domains.

 

Once converted, we check to see if the change applied:

Yes it did!  The wingtiptoys.ca domain is now of type Federated.

The full properties of the domain now look like so:

Please be aware that it can take up to two hours for domain authentication changes to apply.  Go drink a vat of coffee or play some crossy road!

Testing Access To Office 365 OWA

To test that we are being authenticated to Office 365 OWA via AD FS, let’s see what happens now that the domain has been converted to federated.

Open IE, and navigate to https://outlook.office365.com/wingtiptoys.ca  this is the neat shortcut that we can use to access OWA.  Change the domain name to match your own.

When we go to  the browser is redirected to our on-premises AD FS server, at the sts.wingtiptoys.ca URL.

We then sign in to the on-premises AD FS server.  AD FS passes the credentials to AD DS which authenticates us. Assuming that the password is not fat-fingered, and then AD FS verifies our claims (who we are) to Office 365 to let us access OWA:

The astute reader will notice that Edge in-private mode was used.  This keeps my testing separate from the other IE Instances running on my laptop.

One thing to note, when testing this connectivity please do so on a regular client machine that has the proper access to the Internet and where the browser is not totally locked down.  For example on a Server 2008 R2 SP1 server, when browsing to https://outlook.office365.com/wingtiptoys.ca the user experience is very different from the screenshots above.

For lab purposes, you can relax the browser hardening from the default level so that you can test Office 365 from a Windows Server.  Please review this post for the necessary steps.

 

 

Testing Office 365 SSO

Previously you may haved use the TestExchangeConnectivity.com site to test and troubleshoot on-premises issues.  The tool has been expanded as now we can also use it to test and diagnose Office 365 issues.

KB 2650717  How to diagnose single sign-on (SSO) logon issues in Office 365 by using Remote Connectivity Analyzer  discusses using the tool to validate SSO.

BONUS TIP – if you get tired of typing that long URL to get to the site, try http://exrca.com

 

Viewing the SSO Shuffle

Using the IE developer tools, that are accessible by pressing F12 we can see the traffic flow.  You will want to click to enlarge the below.

Note that we went to the following URLs.  Can you work out why there are three outlook.com ones at the top?

 

Repairing Office 365 Federated Domain

As discussed in KB 2647048, there are situations that will require the Office 365 domain federation to be repaired.

• 2523494 (You receive a certificate warning from AD FS when you try to sign in to Office 365, Windows Azure, or Windows Intune
• 2618887 Error when you try to configure a second federated domain in Office 365: “Federation service identifier specified in the AD FS server is already in use.”
• 2713898 “There was a problem accessing the site” error from AD FS when a federated user signs in to Office 365, Windows Azure, or Windows Intune
• 2647020 “Your organization could not sign you in to this service” error and “80041317” or “80043431” error code when a federated user tries to sign in to Office 365
• 2707348 “Metadata Exchange (MEX) document received from AD FS contains an unknown WS-Trust version” error after you run the MOSDAL Support Toolkit
• The Federation Service name in AD FS is changed. For more info, go to the following Microsoft website: AD FS 2.0: How to Change the Federation Service Name

 

Additional Reading

I love this KB as it links to so many other articles that are relevant and introduce many of the issues that can arise with an AD FS deployment.

KB 2647048 — How to update or to repair the configuration of the Office 365 federated domain

The PFE Platform blog has some great AD FS content:

Introduction to Active Directory Federation Services (AD FS) AlternateLoginID Feature

FAQ on AD FS – Part 1

Finally the TechNet Wiki has the AD FS content section.

AD FS Content MAP

Cheers,