Share via

Problems when implementing Office 365 active logon via SAML ECP

Anonymous
2016-03-29T07:05:30+00:00

Hello,

We have prepared a custom SAML-based IDP that allows to perform a single sign on to Office 365 federated domain. The process works correctly. One of the requirements is to allow Outlook desktop and mobile users to access their mailboxes. Since we have no on-premises AD, we decided to use SAML ECP. Unfortunately we are having some problems. The current solution is tested by adding a new account in Outlook 2013 or by using Microsoft Connectivity Analyzer Tool. The active logon URI has been configured using Set-MsolDomainAuthentication commandlet. Here's what we are receiving after trying to add an Outlook account:

POST https://activelogon HTTP/1.1

Host: activelogon

Connection: keep-alive

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Accept-Encoding: gzip, deflate, sdch

Accept-Language: en-US,en;q=0.8,nb;q=0.6,da;q=0.4

Content-Length: 429

<S:Envelope xmlns:S="schemas.xmlsoap.org/.../"&gt;&lt;S:Body&gt;&lt;samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_0f50b585-f152-4ce2-87de-df3bf7142b8a" IssueInstant="2015-12-21T10:12:00.2150299Z" Version="2.0" AssertionConsumerServiceIndex="2"><saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer></samlp:AuthnRequest></S:Body></S:Envelope>

And our response:

HTTP/1.1 200 OK

Cache-Control: private

Content-Type: text/xml

Vary: Accept-Encoding

Server: Microsoft-IIS/8.5

X-AspNet-Version: 4.0.30319

X-Powered-By: ASP.NET

X-UA-Compatible: IE=edge

Date: Mon, 21 Dec 2015 14:36:25 GMT

Content-Length: 3592

<S:Envelope xmlns:S="schemas.xmlsoap.org/.../"&gt;

    <S:Header>

        <ecp:Response xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" AssertionConsumerServiceURL="login.microsoftonline.com/login.srf" S:actor="schemas.xmlsoap.org/.../next" S:mustUnderstand="1" />

    </S:Header>

    <S:Body>

        <samlp:Response ID="_2b846971-6220-4619-ae61-d1207ab6e14e" Version="2.0" IssueInstant="2015-12-21T14:36:25.5072766Z" Destination="login.microsoftonline.com/login.srf" InResponseTo="_0f50b585-f152-4ce2-87de-df3bf7142b8a" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

            <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">5ab</Issuer>

            <samlp:Status>

                <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status>

            <Assertion ID="_1fa8d667-f5c3-4a40-85af-b644736fae04" IssueInstant="2015-12-21T14:36:25.511Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">

                <Issuer>5ab</Issuer>

                <Signature xmlns="www.w3.org/.../xmldsig

                    <SignedInfo>

                        <CanonicalizationMethod Algorithm="www.w3.org/.../xml-exc-c14n />

                        <SignatureMethod Algorithm="www.w3.org/.../xmldsig />

                        <Reference URI="#_1fa8d667-f5c3-4a40-85af-b644736fae04">

                            <Transforms>

                                <Transform Algorithm="www.w3.org/.../xmldsig />

                                <Transform Algorithm="www.w3.org/.../xml-exc-c14n />

                            </Transforms>

                            <DigestMethod Algorithm="www.w3.org/.../xmldsig />

                            <DigestValue>Tjk+FC9HmuB+H+LYXK1aMpcjklM=</DigestValue>

                        </Reference>

                    </SignedInfo>

                    <SignatureValue>sign</SignatureValue>

                    <KeyInfo>

                        <X509Data>

                            <X509Certificate>cert</X509Certificate>

                        </X509Data>

                    </KeyInfo>

                </Signature>

                <Subject>

                    <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">3c204eee-86d2-11e5-b84f-020000000100</NameID>

                    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

                        <SubjectConfirmationData InResponseTo="_0f50b585-f152-4ce2-87de-df3bf7142b8a" NotOnOrAfter="2015-12-21T14:41:25.512Z" Recipient="login.microsoftonline.com/login.srf" />

                    </SubjectConfirmation>

                </Subject>

                <Conditions NotBefore="2015-12-21T14:36:25.512Z" NotOnOrAfter="2015-12-21T15:06:25.512Z">

                    <AudienceRestriction>

                        <Audience>urn:federation:MicrosoftOnline</Audience>

                    </AudienceRestriction>

                </Conditions>

                <AuthnStatement AuthnInstant="2015-12-21T14:36:25.511Z">

                    <AuthnContext>

                        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>

                    </AuthnContext>

                </AuthnStatement>

                <AttributeStatement>

                    <Attribute Name="IDPEmail">

                        <AttributeValue>*** Email address is removed for privacy ***</AttributeValue>

                    </Attribute>

                </AttributeStatement>

            </Assertion>

        </samlp:Response>

    </S:Body>

</S:Envelope>

The next request is issued to autodiscover service:

POST autodiscover-s.outlook.com/.../autodiscover.xml HTTP/1.1

Connection: Keep-Alive

Content-Type: text/xml

User-Agent: Outlook/15.0 (15.0.4779.1000; C2R; x86)

X-MS-WL: Outlook/1.0

X-TransactionID: {FBBE69BF-2E72-4AD3-B01B-195240B79D0F}

Content-Length: 368

Host: autodiscover-s.outlook.com

Authorization: Basic somebase64encodedcredentials

<?xml version="1.0" encoding="UTF-8"?><Autodiscover xmlns="schemas.microsoft.com/.../Autodiscover&gt;

HTTP/1.1 503 Service Unavailable

Cache-Control: private

Content-Type: text/html

Retry-After: 30

Server: Microsoft-IIS/8.0

request-id: 56fa9e4f-ab8f-4ea0-89c5-5f8397c0a424

Set-Cookie: ClientId=EQFSGY250WEMP7SKICUXW; expires=Tue, 20-Dec-2016 14:41:58 GMT; path=/; secure; HttpOnly

X-CalculatedBETarget: am3pr01mb177.eurprd01.prod.exchangelabs.com

X-AutoDiscovery-Error: LiveIdBasicAuth:LiveServerUnreachable:<X-forwarded-for:85.232.232.142><HRD-Business-0ms-430ms-ppserver=PPV: 30 H: CH1IDOALGN92 V: 0><GetDomainInAD-5ms><SyncHRD-1ms><CACHE FAIL> creds LiveIdFailure.<tarpit suggested><FEDERATED><UserType:Federated>Logon failed "*** Email address is removed for privacy ***".;

X-DiagInfo: AM3PR01MB177

X-BEServer: AM3PR01MB177

X-AspNet-Version: 4.0.30319

Set-Cookie: X-BackEndCookie2=; expires=Sat, 21-Dec-1985 14:41:59 GMT; path=/autodiscover; secure; HttpOnly

Set-Cookie: X-BackEndCookie=; expires=Sat, 21-Dec-1985 14:41:59 GMT; path=/autodiscover; secure; HttpOnly

X-Powered-By: ASP.NET

X-FEServer: HE1PR03CA0015

Date: Mon, 21 Dec 2015 14:41:59 GMT

Content-Length: 27

The service is unavailable.

This results in failing the "Searching for *** Email address is removed for privacy *** settings" in the Outlook's wizard. The same flow can be recreated using the Connectivity Analyzer. Unfortunately, we cannot advance past this point. The same user is able to log in to portal.microsoftonline.com using federation. Could you please help us? What could be the problem? It seems that "Logon failed" message is quite generic and covers even the most obvious problems like incorrect ImmutableId (I tried to arrange such case in purpose just to find that out) or missing signature. I'm afraid that the error message is not specic enough and there has to be one detail that we cannot see and we cannot be informed on. I know that Modern Authentication is an alternative to ECP solution, but since it's still in preview phase and support for it is limited, we would like to stick to SAML standard at this point.

Thank you,

Peter

Microsoft 365 and Office | Subscription, account, billing | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

Answer accepted by question author

Anonymous
2016-03-30T21:32:53+00:00

Hi Peter,

Thanks so much for your response. As our forum concentrates on Office 365 online related issues/questions, to ensure the question “SAML response format Office 365 receive from IDP” precisely answered, we recommend you post it in our dedicated MSND forum via the link below where our engineers will provide you corresponding answers.

https://social.msdn.microsoft.com/Forums/sharepoint/en-US/home?filter=alltypes&sort=relevancedesc&brandIgnore=True&filter=alltypes

Best regards,

Ran

Was this answer helpful?

0 comments No comments

2 additional answers

Sort by: Most helpful
  1. Anonymous
    2016-03-30T03:49:17+00:00

    Hi Ran,

    Thank you for your reply. We have full control over the SSO provider, since it is a part of our product. I'm aware of differences between passive and active authorizations. Is there any particular template or SAML response format Office 365 expects to receive from IDP during the active logon? The current implementation we have is fairly generic and similar to that one used in the already working passive mode (but additionally wrapped in Soap Ecp envelope). I've been thinking to take an alternative approach and perhaps try to use ADFS or similar supported solution as an example to follow. At the same time, I'm not sure what's the best way to incorporate it. Could you please help me to advance past the current state?

    Thank you again,

    Peter

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2016-03-30T01:44:04+00:00

    Hi Peter,

    Since users are able to login portal page, it indicates that your third party SSO provider process the authentication flow OK regarding the web page requests. However, as Authentication flow on the web application has a different mechanism with the one on the Outlook client, and this is a third party SSO solution which is not the ADFS that Microsoft provides, we are not familiar with this product working mechanism and we might not be able to provide you further assistance on this issue. To ensure the issue is resolved, we strongly recommend you contact your SSO provider.

    Thanks for your time and understanding on this.

    Best regards,

    Ran

    Was this answer helpful?

    0 comments No comments