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
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.
1 |
Set-MsolDomainAuthentication -DomainName "YourMailDOmain.com" -Authentication Federated -FederationBrandName "Federtaion Brand Name" -PassiveLogOnUri "https://your.idp.com/some/cool/saml/jazz" -IssuerUri "https://your.idp.com/some/cool/" -LogOffUri "https://your.idp.com/some/cool/saml/jazz" -PreferredAuthenticationProtocol SAMLP -SigningCertificate "Your Cert Data" |
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
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$dom = “YourMailDomain.com” $fedBrandName = "Federated Brand Name" $url = “https://your.idp.com/some/cool/saml/jazz " $uri = “https://your.idp.com/some/cool/saml ” $logouturl = “https://your.idp.com/some/cool/saml/jazz ” $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 “C:\Cert\IDPCert.crt” $certData = [system.convert]::tobase64string($cert.rawdata) |
Notice I have added some spaces to the end of the URL parameters.
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
1 |
Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated -FederationBrandName $fedBrandName -PassiveLogOnUri $url -IssuerUri $uri -LogOffUri $logoutUrl -PreferredAuthenticationProtocol SAMLP -SigningCertificate $certData |
Which means you will end up with something like this when you run Get-MsolDomain
It works, but as I say, very likely unsupported.
Thank you for this article. I spent hours trying to figure this shit out.
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
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
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!
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. 🙂
Ok, I’ll keep trying. Thanks very much for your help.
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?
Yeah, it was a bit of an ugly hack to make it work! I can’t think of any consequences unless it is passing the space as %20 (https://www.w3schools.com/tags/ref_urlencode.ASP) and then sees it as a malformed URL. The example I used in this blog was for a 3rd party IDP but it is the same for Azure AD. I know Microsoft’s recommendation has been to use ADFS to make this work properly, I see they even have a recently updated article covering this https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-multiple-domains.
It has been a little while since I have had to set this up but I have a nagging feeling at the back of my mind that there is some way to make this work properly with Azure AD and conditional access rules, but I could be completely wrong on that one 😀
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 🙁
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 🙁