How to Change PreferredAuthenticationProtocol to SAMLP for Office 365 SSO?

Question

Tuesday, June 4, 2013 11:19 AM | 1 vote

I am following the TechNet article, "Set up a trust between Shibboleth and Windows Azure AD", but the following command is not working:

Set-MsolDomainAuthentication –DomainName $dom -FederationBrandName $dom -Authentication Federated  -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -PreferredAuthenticationProtocol SAMLP

No errors are thrown, but when I run Get-MsolFederationProperty for the same domain, I am shown very explicitly that the authentication protocol has not changed from WsFed (the default) to SAMLP. The output I get is:

PreferredAuthenticationProtocol : WsFed

Does anyone know how to change the authentication protocol for my Office 365 instance from SAMLP? This is a link to the TechNet article: http://technet.microsoft.com/en-us/library/jj205457.aspx

All replies (16)

Wednesday, September 11, 2013 6:08 PM ✅Answered

Hello, Thomas,

I was able to "resolve" this issue. What worked for me was to change the Authentication to "Managed" and then back to "Federated".

# 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 $dom -Authentication Managed

# Next, change the domain's authentication mode back to Federated with Samlp selected as the preferred authentication protocol

Set-MsolDomainAuthentication –DomainName $dom -FederationBrandName $dom -Authentication Federated  -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -PreferredAuthenticationProtocol Samlp

Wednesday, September 25, 2013 9:26 AM ✅Answered | 1 vote

Hi Marty, I just resolves this issue. The cause is the url for ActiceLogOnUri is not https protocal. After I use https, I can execute this command successfully. 

Now I trying to do ECP federation. I may meet the issue you described "How to Set Up iPhone Mail Client for User in Federated Domain ." 

And you said " When I configured my identity provider to use a Standard SSL Certificate issued by Go Daddy, all of a sudden Microsoft Online started connecting to my identity provider." 

I wonder to know How do you get the Standard SSL Certificate issued by Go Daddy?

Tuesday, September 10, 2013 4:48 AM

Hi Marty,

I met the same issue. Have you resolved this issue? 

Thursday, September 12, 2013 5:03 AM

Hi Marty,

I tried what you said. But I got error when I set back to Federated. 

Set-MsolDomainAuthentication –DomainName $dom -FederationBrandName $dom -Authentication Federated  -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -PreferredAuthenticationProtocol SamlpSet-MsolDomainAuthentication : Invalid value for parameter.  Parameter Name: <u
nknown>.
所在位置 行:1 字符: 29
+ Set-MsolDomainAuthentication <<<<  –DomainName $dom -FederationBrandName $do
m -Authentication Federated  -PassiveLogOnUri $url -SigningCertificate $cert -I
ssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -PreferredAuthentic
ationProtocol Samlp
    + CategoryInfo          : OperationStopped: (:) [Set-MsolDomainAuthenticat
   ion], MicrosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Prope
   rtyValidationException,Microsoft.Online.Administration.Automation.SetDomai
  nAuthentication

Friday, September 13, 2013 11:53 AM

Hello, Thomas,

I do recall encountering the same error as the one you described. It was a very frustrating error because 1) it made no sense and 2) there was no useful information to guide you in troubleshooting.

Unfortunately the resolution to the error (for me) was to manually do the following:

  1. Begin building a running "federation parameter list" of the two most basic parameters for Set-MsolDomainAuthentication: -DomainName $dom -Authentication Federated
  2. Run Set-MsolDomainAuthentication with the -DomainName $dom -Authentication Managed parameters to reset the authentication method
  3. Run Set-MsolDomainAuthentication with your "federation parameter list" and verify that you don't get the Parameter Name: <unknown> error.
  4. Add one more federation parameter to your running "federation parameter list".
  5. Repeat steps 2-5 until you are able to identify and remove the parameter that Set-MsolDomainAuthentication is not liking.

Monday, September 16, 2013 2:52 AM

Hi Marty,

I tired your resolution and I found a weird thing:

"-PreferredAuthenticationProtocol SAMLP" and "-ActiveLogOnUri $ecpUrl" can not exist in command at same time.  It means "Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated -FederationBrandName $dom -IssuerUri $uri -LogOffUri $logouturl -ActiveLogOnUri $ecpUrl -PassiveLogOnUri $url -SigningCertificate $cert" and "Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated -FederationBrandName $dom -IssuerUri $uri -LogOffUri $logouturl -PassiveLogOnUri $url -SigningCertificate $cert -PreferredAuthenticationProtocol SAMLP" can be executed successfully.  If these two parameters exist at same time, it will meet "Parameter Name: <unknown> error."  

It seems these two parameter conflict with each other.  But I really need to set both these two parameter.  Do you have any idea or suggestion about it ?

Tuesday, September 17, 2013 8:04 AM

Hello, Thomas,

Would you try this command as-is, keeping the parameters in order?

Set-MsolDomainAuthentication –DomainName $dom -FederationBrandName $dom -Authentication Federated  -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -PreferredAuthenticationProtocol SAMLP

Thursday, September 26, 2013 1:22 PM

Hello, Thomas, thanks for sharing the feedback on how you resolved the error! Regarding the SSL certificate, you can purchase one from Go Daddy or purchase it from another SSL certificate provider that you normally use.

It looks like I can't post links right now, so I suggest you go to Bing or Google and search for "go daddy ssl certificate". That should take you to the Go Daddy website.

Friday, September 27, 2013 1:53 AM

Hi Marty, 

Thanks for your info about ssl cert.  

And I have another question, maybe a stupid question:

For rich clients like iphone and Outlook client SSO scenario,  it will use the ActiceLogOnUri  to receive the Authrequest, is it right?  I want to know:

1, Is it need the ActiceLogOnUri to be the url can be accessed by public network? Inside some enterprise, the network is normally internal,  and user can only use Browser to access some internet site with proxy. The internal server cannot be accessed from public network. So if want to implement this scenario,  is it necessary to make the server hosted the IDP can be accessed from public network? in other word, Is it need the ActiceLogOnUri to be the url can be accessed by public network?

2. Do you know which side will send the authrequest to  ActiceLogOnUri ,  rich client or Office 365?

Friday, September 27, 2013 7:09 PM

Hello, Thomas,

Great questions!

  1. Rich clients like iPhone Mail and Outlook will use the ActiveLogOnUri, not the PassiveLogOnUri
  2. I believe the ActiveLogOnUri needs to be publicly accessible, and the reason for that is my last point below. You may be able to talk to Microsoft to see whether alternatives are available, if you can reach a reasonable person at Microsoft Support.
  3. Microsoft Office 365 will send the HTTP request to the ActiveLogOnUri, not the rich client

Sunday, September 29, 2013 12:56 AM

Hi Marty,

Thanks very much for your info.

I have some other question :

1. In Rich clients integration scenario, is the authenticate method  Http Basic auth ? 

2. Do you have any captured packet  of the HTTP request send by Office 365?   In our case, we need the get the info from the Http header, according that, we use different ldap to do authentication. 

Monday, September 30, 2013 2:31 AM

Hello, Thomas,

HTTP Basic Authentication was the only method available when I last implemented this SSO scheme ~Jun, 2013.

Incidentally, I actually do have two sample packets that I captured as part of a problem I encountered with launching SSO for a production domain. They're stored in an Excel spreadsheet showing two (2) sets of request-response packets between Office 365 and Shibboleth IdP.

Build the following link to download the logs: "http://" + "sdrv.ms/1aDgXEv"

  • Each column shows one request-response pair
  • The top part shows the HTTP request generated by Microsoft Office 365 to the Shibboleth IdP server
  • The bottom part shows the HTTP response generated by Shibboleth IdP to Office 365
  • The 1st (left) column shows a bug where Microsoft generates an incorrect request
  • The 2nd (right) column shows a correct request generated by Microsoft that results in successful SSO

Tuesday, October 15, 2013 3:10 AM

Hi Marty,

As I have been busy these days,  just forgot to say a big "Thanks" to you.  You are a good friend. Really thanks and appreciate all your help for me.  And please forgive my late thanks.    

Thursday, October 17, 2013 7:29 AM

HI Marty,

Now I try to use Outlook client to connect my email account but failed. On IDP side , we can see SOAP request from Office 365 and IDP generated SOAP Response. We checked the saml  info in the respones and seems no thing is wrong.  

Do you have any info about it?

Tuesday, February 9, 2016 8:46 PM

Hi Marty,

I'm seeing the same issue as the other gentleman on the forum..  The PS I'm using is;

$dom = "officxxxxxxxxxxours.net"
$url = "https://identity-internalxxxxxxxxxxxxxxxxxxxxsaml-idp"
$ecp = "https://identity-internalxxxxxxxxxxxxxxxxmetaAlias/pearson/saml-id"
$entity = "https://identity-internalxxxxxxxxxxxx:443/auth"
$logout = "https://identity-internalxxxxxxxxxxx/IDPSloRedirect/metaAlias/pearson/saml-idp"
$cert = "MIIDATCC...........5O1BL2dM87s="

Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $entity -ActiveLogOnUri $ecp -LogOffUri $logout -PreferredAuthenticationProtocol SAMLP

I get the same error as the others. I've tried setting the authentication to Managed, then running the PS again.  Nothing seems to work.Can you help?

Exchange Architecture

Friday, May 5, 2017 4:33 AM

Matthew

Remove -ActiveLogOnUri parameter or change the -PreferredAuthenticationProtocol attribute to "WSFED".

Marcelo.

  • Last updated on