Office 365 Multi-Domain

Matt Brennan brennanma at
Tue Jul 28 02:51:17 UTC 2020

Thanks for the reply Scott. I was already running 4.0.1. I was able to use
some of the previous posts I mentioned, along with your guidance above, to
implement a responderIdLookupStrategy that works. It was far simpler than
it looked and I feel stupid for even asking now.

Of course I agree with your assessment that this is a defect;
unfortunately, Microsoft seems to disagree. I generally find that 95% of
the time I tell an SP they've done something incorrectly, they tell me I
don't know what I'm talking about. I send them copies of standards, they
refer me to other "industry standard" implementations that are incorrect.
Anyway, I'm preaching to the choir.

Thanks again

P.S. In case anyone else finds this thread later and wants to know what I

-- in relying-party.xml:
  <util:map id="microsoftOnlineRespondersIdMap">
    <entry key="default" value="%{idp.entityID}" />
    <entry key="" value="%{idp.entityID}/" />

  <bean id="microsoftOnlineResponderIdScript"
parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript"
          //Get the requested domain
          requestedResponder =
            responderId =
          } else {
            responderId =

    <bean parent="RelyingPartyByName"
      <property name="responderIdLookupStrategy">
        <ref bean="microsoftOnlineResponderIdScript" />

-- In Powershell:
$dom = "”
$brand = ""
$url = "
$ecpUrl = ""
$uri = ""
$logouturl = ""
$cert = "<cert-data>"

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

On Mon, Jul 27, 2020 at 1:52 PM Cantor, Scott <cantor.2 at> wrote:

> On 7/27/20, 1:13 PM, "users on behalf of Matt Brennan" <
> users-bounces at on behalf of brennanma at> wrote:
> >    TL;DR: Is there a guide somewhere on how to do this properly?
> Well, step one is filing a bug, because this is ridiculous.
> That aside, the way to do it is:
> 1. Upgrade, because it's not supported In V3.
> 2. A responderIdLookupStrategy, in some form. I can't give you a script
> because I have no idea on what basis the value would be derived, but the
> script should NOT need to do a ton of work. It certainly does not need to
> resolve attributes or anything like that.
> 3. Configuring the context-check interceptor to signal back the event
> "UpdateSecurityParameters" when this needs to happen. This will cause the
> system to re-derive various settings, including the entityID, to update the
> outgoing message.
> #3 is not (well) documented, it was implemented [1] at SWITCH's request as
> a supported way to get all the internals to update without having to mess
> around with them and break abstraction. It's mentioned very briefly in [2].
> I'll try and put a mention of it in the context-check topic.
> -- Scott
> [1]
> [2]
> --
> For Consortium Member technical support, see
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list