How To Install AD FS 2016 For Office 365 – Part 3
Here we are in part three already! Previously we completed the below two phases in the AD FS deployment.
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:
Get-MsolDomain -DomainName wingtiptoys.ca | FL
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
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.
The PFE Platform blog has some great AD FS content:
Finally the TechNet Wiki has the AD FS content section.