Common problems related to using third-party IDPs with Azure and Office365

  • [アーティクル]

Hello again Technet community!

Over the span of the last year or so, I've been assisting quite a few customers with integrating Azure and Office 365 services into on-premises environments. Many of these customers have adopted our unique hybrid topology, and are running a combination of our cloud services right alongside on premises based services. As many of you undoubtedly know, hybrid service implementations are heavily reliant on a rock solid identity strategy. While there are many solutions that customers can adopt for identity, this blog is going to focus heavily on customers that have chosen to adopt federation based strategies. Specifically, we're going to be focusing on identity strategies that revolve around utilizing third-party (non-ADFS) services and solutions for federated identity... services such as Tivoli, Siteminder, etc. This article will not focus on the implementation aspect of getting these service to play nice with your Office 365 and Azure environments, rather, we're going to focus on some nuances you may or may not encounter while working with these services.

 

So without further ado, lets jump right into the lessons learned!

 

Problem: I'm using a third-party IDP (non-ADFS) for federation, and I need to make a federation configuration change within my tenant. Every time I run the set-msoldomainfederationsettings cmdlet to update my configuration, I receive a "Invalid value for parameter" error. I know why syntax is correct! What's going on?!?

 

Error example

Set-MsolDomainFederationSettings : Invalid value for parameter. Parameter Name: <unknown>.

At line:1 char:1

+ Set-MsolDomainFederationSettings -DomainName "contoso.com" -ActiveLogOnUri "https:// ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : OperationStopped: (:) [Set-MsolDomainFederationSettings], MicrosoftOnlineException

    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyValidationException,Microsoft.Online.

   Administration.Automation.SetDomainFederationSettings

 

Solution: This particular error took a bit of digging as well as trial and error in a lab environment to figure out! The customer that was receiving this error was using a third-party federation solution that was configured to use SAML as the sign-in protocol. As it turns out, the set-msoldomainfederationsettings cmdlet only lets you modify the configuration of IDP's that are utilizing the WS-FED sign-in protocol, which is the default protocol used by ADFS when you initially configure the service.

So how does one update their tenant federation configuration when using a SAML based provider? The easiest way to work around the error is to revert the federated domain your working with back to a managed domain within Azure Active Directory, and the re-federate the namespace with the appropriate configuration settings. Here are the steps you would need to follow:

  • Revert your federated domain back to managed domain by running: Set-MsolDomainAuthentication -DomainName contoso.com -Authentication managed
  • Federate your domain again by running: Set-MsolDomainAuthentication.

To speed the process up, I recommend performing these steps via script. Here's an example of a script that will do the trick:

Set-MsolDomainAuthentication -DomainName contoso.com -Authentication managed

$domainName = “contoso.com”

$brandName = “Some name here!”

$logonUrl = "https://lab.contoso.com/acu/Office365"

$issuerIUri = "https://lab.contoso.com/acu/sps/Office365/saml20"

$logoffUri = "https://lab.contoso.com/acu/sps/Office365/saml20/slo"

$cert = "Your base64 cert string here!"

Set-MsolDomainAuthentication -DomainName $domainName -PassiveLogOnUri $logonUrl -ActiveLogOnUri $logonUrl -IssuerUri `

     $issuerIUri -SigningCertificate $cert -LogOffUri $logoffUri ` -Authentication "federated" -PreferredAuthenticationProtocol SAMLP `

      -FederationBrandName $brandName

If you script the process using your own script or the code mentioned above, the entire configuration change takes about two seconds. Please bear in mind that the configuration change can sometimes take up to ten minutes to go into effect on the back-end side of AAD... so please plan accordingly and do not perform configuration changes during the work day when you have active users!