Set-MsolDomainAuthentication. The multiple domains problem, and workaround

Background

If you have found this webpage, you are probably trying to federate multiple mail domains registered in Office 365 with a single Identity Provider, which just doesn’t work. You may have an error similar to below.

Set-MsolDomainAuthentication : Unable to complete this action. Try again later.
At line:1 char:1
+ Set-MsolDomainAuthentication -DomainName $dom -Authentication Federat …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Set-MsolDomainAuthentication], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.InternalServiceException,Microsoft.
Online.Administration.Automation.SetDomainAuthentication

fed_settings01

The problem

The problem here is that each mail domain you would like to federate has to federate with a unique Identity Provider URL. Let’s take a look at how that would look as a line of PowerShell.

The PassiveLogonUri, IssueUri, and LogoffUri have to be unique for each mail domain, even if all users exist in a single AzureAD domain or Identity Provider. This isn’t ideal and ultimately means you should create a new identity provider for each mail domain which leads to duplication of configuration and policies.

The workaround

What I am going to propose below is likely unsupported, follow at your own risk, you have been warned.

So we know the Identity Provider URL’s have to be unique per mail domain. What if we modify the URL so it ultimately points back to the same IDP but as far as Microsoft is concerned, it is a unique URL?

Let’s pass the URLs to a variable in PowerShell

Notice I have added some spaces to the end of the URL parameters.

fed_settings02

As far as the command Set-MsolDomainAuthentication is concerned, it thinks this is a unique URL. For each mail domain, add an additional space.

Then to apply the federation settings

Which means you will end up with something like this when you run Get-MsolDomain

fed_settings03

It works, but as I say, very likely unsupported.

You may also like...

10 Responses

  1. Kisuka says:

    Thank you for this article. I spent hours trying to figure this shit out.

  2. bleitner says:

    Hi Ian,

    thanks for this Article. We have a similar issue to verify a domain and you might have an idea how to solve. We want to use Keycloak as IDP and for the setup of Office365 we want to register and verify a domain, but failed. Here are the commands
    1. Create the Domain:
    >>New-MsolDomain -Name myDomain.com -Authentication Federated
    2. Create the TXT-Value
    >>Get-MsolDomainVerificationDns -DomainName myDomain.com -Mode DnsTxtRecord
    3. Update the DNS Zone with the created Value
    4. Validate the domain
    >>Confirm-MsolDomain -DomainName myDomain.com
    And this step always fails. We tried with different Domain but no luck. We get “Confirm-MsolDomain : Unable to complete this action. Try again later.” We tried again later but it doesn’t work.
    Do you have an idea? Thanks very much

    • Ian says:

      Hi,

      Thanks for the comment. I can only think of two possibilities here. The first being that any time I add a domain to an O365 tenancy it starts as a Managed domain, rather than Federated. Maybe try that first. There are some steps to do this in the O365 console, but the PoSH commands should stand if trying to create a managed domain rather than federated. https://docs.microsoft.com/en-us/microsoft-365/admin/setup/add-domain?view=o365-worldwide.

      Second, if you already have a federated domain, it will fail as you cannot have multiple federated domain names. This blog post details how I cheat to work around the limitation though. Chances are you have one Exchange online tenancy but multiple domains associated with the account. It is difficult to federate for more than one of those domains though.

      Hope that helps you out!

      Ian

      • bleitner says:

        ok, thanks for this. Maybe it is not clear for me if I need a managed or a federated Domain. 🙂 We want to authenticate against a keacloak server instead of authenticate directly on Office365. I have read some manuals and thought I would need a federated domain.
        It is not a problem to create and validate the domain directly on Admin Center. If I verify the domain there, it is available and shows up as managed. But then, I can’t use the commmand with the -Authentication Parameter “Federated”
        “Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated….”
        I can use the Paramameter “-Authentication Managed” instead. But is the result the same???

        Do you think we can setup SSO with Keycloak as IDP and Office365 as SP with a managed domain? Have you any experience in this or other thirdParty IPDs?
        Thanks so much!

        • Ian says:

          If Keycloak has a guide to integrating with O365 for SSO, then I don’t see why it cant act as the IDP. If it does support it, then it will generate a certificate to integrate with O365 for the SSO piece.

          Sorry, I can’t be much more help than that, I’m not sure how Keycloak works.

          The suggestion of using managed domain was just to register the domain with O365 before attempting to flip it to a federated domain, just to ensure that the domain registered correctly by using the TXT record verification. 🙂

  3. Stricnis says:

    Excellent, that’s ugly but clever and that works. I thought that I wouldn’t be able to login to O365 after the config, expecting an invalid Issuer error or something like this, but everything ran smoothly. Thanks! Any idea of the possible consequences behind in Azure AD? I don’t think that can be harmful as it is easy to cancel the federation but maybe have you some feedback on this?

  4. Sebastien says:

    It seems it is not working for Thales Safenet Trusted Access unfortunately.
    I am indeed able to federate my second domain, when including spaces at the end of the uri…

    when i try to authenticate as one of this domain users, i am redirected to the Safenet IDP Url, but…. “something went wrong” before the page appears.
    I checked 20 times the urls/uri, compared them to my working first federated domain… but no luck 🙁

    • Ian says:

      It was Thales Safenet Trusted Access this was configured with when I wrote the blog post but I, unfortunately, do not have access to those environments any longer to check if anything has changed.
      I know Thales changed their documentation for configuring the O365 MFA integration from the manual method described in this blog post (without any spaces of course) to using a PowerShell script to automate it. The only thing I could suggest is setting the first domain back to managed instead of federated and trying the second domain as the first federated domain to see if you run into the same issues. Other than that I can’t think of anything, sorry 🙁

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.