Set-MsolDomainAuthentication PreferredAuthenticationProtocol = "SAMLP", Get-MSolDomainFederationSettings shows as WsFed.

Question

Hello,

I am trying to establish a single sign on (SSO) experience for my Google Workspace (GW) users who need to occasionally use Word, PowerPoint and Excel by federating GW as Identity Provider with a newly created tenant at Microsoft (MS) as Service Provider.
I was able to create a SAML web app at GW and used PowerShell to confer the information to MS.
The federation between them is successful in that my user data has migrated from GW to MS.
Standard Business licenses for the apps were purchased and assigned to users in the MS admin dashboard.

However, SSO experience doesn't work when my users try to logon to office.com with their GW credentials.
GW is expecting a SAML conversation but is receiving a WS-FED protocol from MS when I use a SAML tracer extension and review the results.
My notes show that I issued a Set-MsolDomainAuthentication command with PreferredAuthenticationProtocol = "SAMLP" that was received without complaint.
They also show that when I checked the results with a Get-MSolDomainFederationSettings the protocol shows as WsFed.

I would go to the trouble of undoing and redoing the authentication with MS, but it is a sign of Madness to repeat the same process and expect a different result.

What could I do differently here to get SAMLP to stick?

- Ed -  

Answer 1

Not getting any response after a few days here, so I am going to try the method outlined in this article with an admin trying to update from wsfed to saml:

https://social.msdn.microsoft.com/Forums/en-US/861eba73-8a16-4de2-a4ce-b9e0533faa36/how-to-change-preferredauthenticationprotocol-to-samlp-for-office-365-sso?forum=onlineservicesexchange

I'll keep myself posted with how that turns out.

Answer 2

Copy all of the federation parameters we used before into PowerShell. One thing I note that this guy did differently is he would type in SAMLP without quotes and did not use a variable name, and added the parameters in a slightly different order, so I will follow that lead, just to do something different.

First, change the domain's authentication mode to Managed, so that the preferred authentication protocol can be changed from WsFed to Samlp

Set-MsolDomainAuthentication –DomainName $DomainName -Authentication Managed  

Check the result

Get-MSolDomainFederationSettings -DomainName orl-inc.com | Format-List *  

Yields no response (I interpret this as all parameters being deleted)

Next, change the domain's authentication mode back to Federated with SAMLP typed in without quotes, using all of the previously used parameters:

Set-MsolDomainAuthentication –DomainName $DomainName -FederationBrandName $FederationBrandName -Authentication Federated -PassiveLogOnUri $PassiveLogOnUri -SigningCertificate $SigningCertificate -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -LogOffUri $LogOffUri -PreferredAuthenticationProtocol SAMLP  

Check the result

Get-MSolDomainFederationSettings -DomainName orl-inc.com | Format-List *  
  
ExtensionData                          : System.Runtime.Serialization.ExtensionDataObject  
ActiveLogOnUri                         : https://accounts.google.com/o/saml2/idp?idpid=XXXXXXX  
DefaultInteractiveAuthenticationMethod :  
FederationBrandName                    : Google Workspace  
IssuerUri                              : https://accounts.google.com/o/saml2?idpid=XXXXXXXXX  
LogOffUri                              : https://accounts.google.com/logout  
MetadataExchangeUri                    :  
NextSigningCertificate                 :  
OpenIdConnectDiscoveryEndpoint         :  
PassiveLogOnUri                        : https://accounts.google.com/o/saml2/idp?idpid=XXXXXXXXX  
PasswordChangeUri                      :  
PasswordResetUri                       :  
PreferredAuthenticationProtocol        : Samlp  
PromptLoginBehavior                    :  
SigningCertificate                     : MIIDdDCCAlygAwIBAgIGAXGoCdejMA0GCSqGSIb3DQEBCwUAM                                           
MuMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MQ8wDQYDVQQDEwZHb29nbGUxGDAWBgNVB  
                                                      etc ...                                          
Reb5Y8/Rk6PXf0ZkQO2RwZMAui7K14e0hNDYBYSflPeTKfOaVsAEzWz/qsSOn0WZ7FUv/vW5OIcPlT  
SigningCertificateUpdateStatus         :  
SupportsMfa                            :  

Success?

Yes!

SAMLP sticks and SSO is now working!

Hope this is helpful for someone else in the future...