Problems configuring federation to SAML IdP

[Nick_Chadwick]

Hi.

I'm trying to configure our Entra domain to federate to our existing IdP, following the guidance found here and am having real problems when it comes to using the Microsoft Graph API in PowerShell.

After eventually working out what permissions I needed to request (more than what is stated in the doc), I ran the New-MgDomainFederationConfiguration cmdlet, and received the following error:

"FederatedIdpMfaBehavior cannot be empty"

This parameter is not mentioned in the doc either. So, then I added that parameter, and got the following:

"Domain already has Federation Configuration set."

But when I run Get-MgDomainFederationConfiguration, I get:

"Resource 'federationConfiguration' does not exist or one of its queried
reference-property objects are not present."

When I run Get-MgDomain, AuthenticationType shows as "Federated", but I still see a managed login when I check.

So I seem to be stuck with it seemingly half-configured, with no way to view or remove the configuration. Any ideas?

Thanks,

Nick

[#2]

Try querying the Graph API directly to get a raw view of the federation settings. Use a tool like Graph Explorer (https://developer.microsoft.com/en-us/graph/graph-explorer).
Check for the existence of an object under /domains/<yourdomain>/federationConfiguration. This might give more clues about the corrupted state.

[#3]

Hi

I stucked a similar probrem as you.
I used old "Set-MsolDomainAuthentication" command and got my domain back to be managed.

Below is an example.
Set-MsolDomainAuthentication -DomainName "my.custom.domain" -Authentication Managed

Hope this helps

[#4]

Thanks for that. Unfortunately it is too late for it to help in this case, as within a few days of making the original change, everyone in my organisation was unable to log in to Microsoft any more. I have since (for nearly 2 months!) been stuck in a hell of dealing with Microsoft support, which I can honestly say has been, and continues to be, an utter disgrace, and the worst customer experience I have experienced in my long career in IT. And still the situation is unresolved. No one in my company is able to access Office software or host Teams meetings, and I have everyone from the CEO down chasing me on a daily basis while I wait for another pointless call that will most likely get us no closer to a happy ending. And of course it's impossible to call them and get through to anyone who can help (I have personally sat on hold for 2+ hours on several occasions). If Microsoft wasn't such a huge company, they'd have gone out of business a long time ago, if this is how they look after their customers. Ho hum. Rant over, I guess.

[#5]

We had this problem too. But only with the second or further domains. The support couldn't help either and searched in completely the wrong direction.
I could solve it by changing the domain back to managed and federating it with New-MgDomainFederationConfiguration. It is important to note that the IssuerUri parameter must be individual for each domain. Otherwise the API will not understand that it is the same IDP (ADFS in our case) and will save a broken configuration. By the way, this also happens if other parameters are not 100% correct; a defective configuration is saved and blocks everything else. Error messages are usually not sufficiently informative.
If you have any questions, please feel free to get in touch.

[#6]

Would be very curious if there is a way to clear out that sort of bad configuration, running into the same issue in a newly migrated environment as well.

[#7]

@MAEssig 

I just experienced this problem today and found this thread which was very helpful, so for the record here is the command that I used to reset to Managed that appears to have worked:

Update-MgDomain -DomainId <domain> -AuthenticationType "Managed"

After this, I was able to successfully run my New-MgDomainFederationConfiguration command corrected with the inclusion of -federatedIdpMfaBehavior

Hope this is helpful for you or someone else in future.