Saturday, August 29, 2015

Office 365 - Disable Federation (ADFS)

SSO (Single Sign On) for Office 365 is usually provided by Active Directory Federation Services (ADFS).

Note: see this blog post for a description of SSO:

Office 365 - Hybrid Migration - Part 1: ADFS configuration

However, we may opt for another SSO service such as those of third-party providers OneLogin or Okta (these are the two "big names" in the identity provider business). If we have not implemented ADFS, we would simply configure the third-party system as directed. If we do have ADFS in place, we have to disable federation in Office 365 before implementing the third-party solution. This process is sometimes called "defederation".

As for DirSync, we may retain it as a solution, or not, depending on our needs. I may address that aspect in another blog post. For now, I will concentrate on ADFS.

In the following paragraphs, I'll outline the procedure to disable federation with ADFS and thus allow use of a third-party tool.

First, we open the Windows Azure Active Directory Module for PowerShell:

We then import the MSOnline module which allows us to execute commands in our Cloud environment (Office 365):

Import-Module MSOnline

We then connect to the online service:


At this point, we have to enter Global Administrator credentials for the domain we want to manage.

This would be something like:

Password: **********

We then verify which domains are federated with the following cmdlet:


In my case, it is the domain that is federated:

Note: I added... | format-list name,status.auth* so all the output would be neatly aligned to the left. Otherwise, by default, authentication displays on the far right on the screen

We have to connect to the ADFS server from O365 at this time:

Set-MsolADFSContext -Computer ADFS-1

Note: ADFS-1 is the name of my ADFS server.

And now, we can convert the domain to standard (as opposed to federated):

Convert-MsolDomainToStandard -DomainName -SkipUserConversion:$true -PasswordFile C:\userpasswords.txt

Note: we can name the password text file to whatever we want. In my case, this file was not even created.

We should obtain a result like this (click to enlarge):

Apparently, we still need to execute one more cmdlet to set domain authentication to "managed" even though the preceding cmdlet seems to do this (note the output above):

Set-MsolDomainAuthentication -Authentication Managed -DomainName

Now users can logon to Office 365 / Exchange Online even if the ADFS server is unavailable. That is because they authenticate against Azure Active Directory to which their passwords have been synchronized via DirSync.

This is what the user will see:

When they start to enter their password, they will no longer be redirected to an ADFS server but will be able to continue to enter their credentials as shown above.

And despite the absence of an ADFS server (currently powered off), they can indeed access their email:


Of course, we no longer have SSO and users will have to enter their credentials every time they access their email (or other Office 365 services). If this is not acceptable, we either have to retain ADFS or implement a third-party service such as those offered by OneLogin or Okta.


  1. So, here's a question. My on-premises infrastructure has been completely decommissioned. This was intentional (school project build complete). However I did not dismantle the hybrid email config and ADFS relationship before we wiped out on-prem.

    Do you have any ideas how to convert O365 to a completely cloud-based identity and email model? I'd like to continue to use 365 on my own (with my own domain name), but obviously I can't use the on-prem Exchange or ADFS anymore.

  2. Hello! Thanks for the very helpful guide! I have a question. When you use -SkipUserConversion:$true, do the people use the same password with active directory? I'm planing to disable ADFS, but the biggest problem is the email password. I know if i set '$false', new password will be generated for temporary for people. I'd like to let people use the same password with AD what they're using.

  3. Sorry for the late response guys. So... if you are still there:

    MadMatt112: for ADFS, I would break the link as described above. For the hybrid aspect, wiping the on-premises first may complicate matters. To be honest, I have not examined such a scenario. I know, for example, that wiping the last Exchange server onsite without uninstalling Exchange first, will leave all kinds of references to Exchange in Active Directory. I suspect there's a number of references in O365 to your no longer existing on-premises environment but I'm not sure 1) to what extent they will cause problems and 2) what commands would remove them.

    I would suggest asking the question on the O365 forum:

    S Kim: Do the O365 users use the same password that they used when ADFS was still the link between on-site Active Directory and O365 (even after we disable ADFS)?

    Is that your question?

    I replaced ADFS with OneLogin almost immediately so I did not test your scenario. Unfortunately (as you may have determined yourself by now), it looks like a new password will have to be generated:

    Once again, I would suggest confirming on the O365 forum, since the members there will have encountered more diverse situations than what I have tested in my lab:

  4. This comment has been removed by the author.

  5. I have never "defederated" a domain before. I would like to know what possible roll-back options there are?