Well then, here we are in part three already! Previously we:
Installed ADFS 2012 R2 For Office 365 in part 1 Installed ADFS 2012 R2 Proxy For Office 365 in Part 2
Installed ADFS 2012 R2 For Office 365 in part 1
Installed ADFS 2012 R2 Proxy For Office 365 in Part 2
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 ADFS server is responsible for authenticating these requests.
Update 20-8-2014: Added comment for SupportMultipleDomain switch for the Convert-MSOLDomainToFederated cmdlet.
Before we discuss the integration of Office with the on-premises ADFS infrastructure, let’s just again be clear on the criticality of ensuring that ADFS is available when the Office 365 domain is set to use ADFS authentication. For whatever reason if the ADFS 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 ADFS please review the DirSync password synchronisation feature in the recent DirSync builds.
Apologies if I sound pessimistic, but I don’t want to obviate the requirement for ADFS redundancy!
On the topic of ADFS redundancy one option is to also host a portion of your ADFS 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:
This is an example of hosting ADFS 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 ADFS Azure documentation above and also the additional discussion points here.
Back to the business at hand – updating Office 365 so that it now uses your on-premises ADFS server!
We will run the below on a domain joined server on the corporate network. This has the Windows Azure Active Directory PowerShell Module and the Microsoft Online Sign-In Assistance (SIA) installed. Let’s launch the WAAD PowerShell module. For reference the remote ADFS server is Tail-CA-STS.TailspinToys.ca.
For other WAAD management tasks, take a peek at Manage Azure AD using Windows PowerShell page.
Using Connect-MsolService let’s connect to our WAAD instance. 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 – “Tailspintoys.ca”.
Before we can execute the Convert-MsolDomainToFederated cmdlet, we need to also a hook into the local ADFS server (not the ADFS proxy) so that we can configure it.
There is a word of warning here, as chances are that you will see this lovely screen that features copious red text.
Set-MsolADFSContext : The connection to <ServerName> Active Directory Federation Services 2.0 server failed due to invalid credentials.
Active Directory Federation Services 2.0 server failed due to invalid credentials" style='background-image: none; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border-width: 0px;' alt='Set-MsolADFSContext : The connection to Active Directory Federation Services 2.0 server failed due to invalid credentials' src='/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-91-09-metablogapi/image_5F00_thumb_5F00_62F9607B.png' border='0' />
This is caused by Remote PowerShell not being enabled on the remote ADFS server. This is an issue that is present on ADFS 2012 and ADFS 2012 R2 servers amongst others. Thankfully it is quite easy to fix, by running the below on the ADFS server:
Enable-PSRemoting
Once Remote PowerShell has been enabled, we can then connect to the ADFS 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 ADFS server, we use the Convert-MsolDomainToFederated cmdlet to convert the Office 365 domain from Managed to Federated.
Set-MsolADFSContext -Computer Tail-CA-STS.tailspintoys.ca Convert-MsolDomainToFederated -DomainName tailspintoys.ca
Set-MsolADFSContext -Computer Tail-CA-STS.tailspintoys.ca
Convert-MsolDomainToFederated -DomainName tailspintoys.ca
Update 20-8-2014: Andy pointed out in the comment that there is an area of concern to be noted here for customers that have multiple top level domains. Back with ADFS 2.0 customers with multiple top level UPNs had to deploy separate ADFS 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 domain is now 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 flappy birds!
To test that we are being authenticated to Office 365 OWA via ADFS, let’s see what happens now that the domain has been converted to federated.
Open IE, and navigate to https://outlook.com/tailspintoys.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 ADFS server, at this URL: https://adfs.tailspintoys.ca/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26rpsnv%3D3%26ct%3D1398824668%26rver%3D6.1.6206.0%26wp%3DMBI_KEY%26wreply%3Dhttps:%252F%252Fwww.outlook.com%252Fowa%252F%26id%3D260563%26whr%3Dtailspintoys.ca%26CBCXT%3Dout
We then sign in to the on-premises ADFS server:
ADFS authenticates us, assuming that the password is not fat-fingered, and this authorises Office 365 to let us access OWA:
The astute reader will notice that IE in-private mode has been 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. In the below example on a Server 2008 R2 SP1 server, when browsing to outlook.com/tailspintoys.ca the user experience is very different from the screenshots above.
The user will get logged on, but it can be disconcerting if you are expecting the sexy looking ADFS screen and you get an auth prompt instead…..
Chances are you will have 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
Using the IE developer tools, that are accessible by pressing F12 we can see the traffic flow that the browser has taken to reach the sites involved. 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?
As discussed in KB 2647048, there are situations that will require the Office 365 domain federation to be repaired.
For example, you may find yourself running this:
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 ADFS deployment.
KB 2647048 -- How to update or to repair the configuration of the Office 365 federated domain
The PFE Platform blog have some great ADFS content, amongst other things. Just don't propose to Charity via the comment system please!
How to Build Your ADFS Lab on Server 2012 Part 1 Introduction to Active Directory Federation Services (AD FS) AlternateLoginID Feature Upgrading ADFS to Server 2012 R2 FAQ on ADFS - Part 1
How to Build Your ADFS Lab on Server 2012 Part 1
Introduction to Active Directory Federation Services (AD FS) AlternateLoginID Feature
Upgrading ADFS to Server 2012 R2
FAQ on ADFS - Part 1
Finally the TechNet Wiki has the ADFS content section.
ADFS Content MAP
Cheers,
Rhoderick
If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!
If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!
US
Canada
For all other areas please use the US contact point.
Thanks a lotvery helpfull
Thanks for the Great post Rhod, Excellent walkthrough ... :)
I am really glad you wrote this article. I have to implement ADFS for office 365 in the next few months.GOOD JOB!
Thanks for the feedback guys! Brad - do let us know how you get on with the deployment!! I also have another post coming up that you will love - please subscribe to the RSS feed. I'll probably publish it on Monday.Cheers,Rhoderick
Great work one of the best worked articles I have ever read. One question is around firewall rules for the internal ADFS to the DMZ WAP is only port 443 required between the two servers? Is this bidirectional or one way only? Thank again
Good question Techno :) The firewall stuff is in here http://technet.microsoft.com/en-us/library/dn383648.aspx But does not state the direction. I'll see what I can locate.... Cheers, Rhoderick
Hi Rhoderick, my users were able to login to the Office 365 ADFS 2.0 with username (ABC)and password without using (FQDN) abc@xyz.com. However, when I upgraded my ADFS farm to Windows Server 2012 R2, the Office 365 ADFS 3.0 login page does not allow users to use username login (abc) rather it ask to enter abc@xyz.com or domain\username. How can i fix this issue ? Thanks Puneet
As far as the user experience, what happens if they already have the same password in outlook for Office 365 as AD? Immediately after federated, will they be prompted for their password through outlook? Or will outlook continue to login without prompt? This would happen if already using dir sync with password sync enabled and adding ADFS.
Outstanding how to article!!! Allows anyone with decent skills to install and understand.
thanks
Thank you! Very helpful blog! Tell me please if SSO should work during autoiscover (when outlook is adding profile), because this is only place where I am asked for password?
Mark and Andrej - Outlook is trying to do basic auth. So this will present the password prompt, which is the reason for the recommendation to save credentials else users get bored of the enter password game.... As long as the right creds are saved in there it should not prompt, but I'm just back from 3 weeks of holiday and brain is still warning up.... Cheers, Rhoderick
Puneet - Not something I've looked at since I always use the user@contoso.com for all auth purposes. Cheers, Rhoderick
Used this awesome guide a few times when installing ADFS/WAP, to ensure I don't miss anything - can I suggest that you point out the -SupportMultipleDomain parameter of the Convert-MSOLDomainToFederated cmdlet, as not specifying this when converting can be a pain to undo.
Good point - I'll add a wee note to that Andy! Cheers, Rhoderick