#76 ADFS can't always be used

[Nicolas Dély]

Summary of the discussion: for some setups ADFS is enabled for an account but it is not usable for Lync authentication. Currently this seems to be the case when multi-factor authentication (MFS) is enabled for the account.

We either automatically need to detect this (how?) or add a setting for it (bad).

Original description follows:

---

Hi guys,

I've read most topic on office365 integration, thanks a lot for your work.
However I still have not found how to fix strong authentication requirement :-(

our company is switching from internal lync server to office365 one, my lync account was migrated in advance to check pidgin-sipe on linux can work.

my settings:
pidging 1.18.2
http_proxy on
adfs server
username: email address
login: usual AD DOMAIN\login the one working when authenticating to this federated gateway
Password: AD password

Server: sipdir.online.lync.com:443
Connection type: Auto
User Agent: UCCAPI/15.0.4420.1017 OC/15.0.4420.1017
Authenticated scheme: TLS-DSK
SSO: off
Dont publish calendar off
Email service URL: empty
Email address: empty
Email login: empty
Email password: empty

with this setting I can see ssl tunnel through proxy working well then adfs connection looks ok

(14:42:11) sipe: sipe_svc_https_response: code 200
(14:42:11) sipe: generate_federation_wsse: found timestamp & keydata, expires 2014-10-20T13:42:10.935Z
(14:42:11) sipe: webticket_token: received valid SOAP message from ADFS https://adfs.mycompany.com/adfs/services/trust/2005/usernamemixed
(14:42:11) sipe: sipe_http_parse_uri: host 'login.microsoftonline.com' port 443 path 'RST2.srf'

then login to login.microsoftonline.com failed because strong authentication required ("Require strong authentication"), I suspect it comes office365 password (app password) I do not know where to set it.

MESSAGE START >>>>>>>>>> HTTP - 2014-10-20T12:42:11.101533Z
POST /RST2.srf HTTP/1.1
Host: login.microsoftonline.com
User-Agent: Sipe/1.18.2
SOAPAction: "http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue"
Content-Length: 6238
Content-Type: text/xml

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:auth="http://schemas.xmlsoap.org/ws/2006/12/authorization" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" ><soap:Header> <wsa:To>https://login.microsoftonline.com:443/RST2.srf</wsa:To> <wsa:ReplyTo>  <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address> </wsa:ReplyTo> <wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action> <wsse:Security><wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="timestamp"><wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2014-10-20T12:42:10.935Z</wsu:Created><wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2014-10-20T13:42:10.935Z</wsu:Expires></wsu:Timestamp><saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_d3eef59b-8f7a-41ae-92bd-9085945eaa11" Issuer="http://company.com/adfs/services/trust/" IssueInstant="2014-10-20T12:42:10.938Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><saml:Conditions NotBefore="2014-10-20T12:42:10.935Z" NotOnOrAfter="2014-10-20T13:42:10.935Z"><saml:AudienceRestrictionCondition><saml:Audience>urn:federation:MicrosoftOnline</saml:Audience></saml:AudienceRestrictionCondition></saml:Conditions><saml:AttributeStatement><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">L4mzpazE40GQPkoUgbH9Ng==</saml:NameIdentifier><saml:SubjectConfirmation><saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod></saml:SubjectConfirmation></saml:Subject><saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims"><saml:AttributeValue>Nicolas.Dely@company.com</saml:AttributeValue></saml:Attribute><saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05"><saml:AttributeValue>L4mzpazE40GQPkoUgbH9Ng==</saml:AttributeValue></saml:Attribute></saml:AttributeStatement><saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2014-10-20T12:42:10.935Z"><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">L4mzpazE40GQPkoUgbH9Ng==</saml:NameIdentifier><saml:SubjectConfirmation><saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod></saml:SubjectConfirmation></saml:Subject></saml:AuthenticationStatement><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#_d3eef59b-8f7a-41ae-92bd-9085945eaa11"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>dHkJFkZTIKgSzQGmAz1jq7k8xN4=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>m6Xb/rvNGaNWjLP0X3s4nxYeqgI1jxcjkirBIL1UehPdhW0Dn7gHPH7oQtE+KS4LJOBmnmrYR95ZIZUMIRls39UbGyAkoOoXmvF+sCXYK1vF8ZmrHKGck42qg4jJ9w1fmwPvONRr+MC2EYp9aKrX0PYda60ICPL7nG/9DZGTKtSRwncro0ZqJsL6a0V96mNhbROhLtS7rusL3581fQ8Sp83s1W4WWZW3fFixAE9eKAF6FQPKcguY+rgXoHkWkHpR48nkg+FG/ylCpw9e8iq1rdgg2qojDePAdNo79VdObKXLH22HtlQzNpeDmJLT0deud4J1cVysPqAwfOttV9vUpg==</ds:SignatureValue><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><X509Data><X509Certificate>MIIFHDCCBASgAwIBAgIETCHvKDANBgkqhkiG9w0BAQUFADCBsTELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0Lm5ldC9ycGEgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMDkgRW50cnVzdCwgSW5jLjEuMCwGA1UEAxMlRW50cnVzdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEwxQzAeFw0xNDAxMjcxNzQzMDdaFw0xNTA4MjQyMTI2NTRaMG4xCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdJbmRpYW5hMRUwEwYDVQQHEwxJbmRpYW5hcG9saXMxFDASBgNVBAoTC1RlY2huaWNvbG9yMSAwHgYDVQQDExdmZWRzaWduLnRlY2huaWNvbG9yLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQByHrEUzMLR7JqOv5wudVsNZNEzeSQRzOH5zu2LiSppMPRBEYVNo9hFMC216sMcjWUcX9Tn0n9vFhueIfQaMqE0XusEVEbNX+Uhvm/lfsYsUUsmu3BgU5+C9OgtvGO04chEWaTlLPWou4AZMndmmJ8aicPQNfoWO5apsoAjmwAUIyRDjUpKf8KNrYCQVeyivVLEztuBCBwQCJmBIOHspK9znPZp7iGWoke6yyOpHivaAHzlOgd2dabukC2Rl7PT9mcTZ6vrS1+FeGWaOnpG5cplAta435IfuH4wfby7aQl1esKKzWsFBylpOLn1vsWSoYTleH6BTFxbrLVVGLCdlcCAwEAAaOCAXwwggF4MAsGA1UdDwQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmVudHJ1c3QubmV0L2xldmVsMWMuY3JsMGQGCCsGAQUFBwEBBFgwVjAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwLwYIKwYBBQUHMAKGI2h0dHA6Ly9haWEuZW50cnVzdC5uZXQvMjA0OC1sMWMuY2VyMEoGA1UdIARDMEEwNQYJKoZIhvZ9B0sCMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuZW50cnVzdC5uZXQvcnBhMAgGBmeBDAECAjAiBgNVHREEGzAZghdmZWRzaWduLnRlY2huaWNvbG9yLmNvbTAfBgNVHSMEGDAWgBQe8auJBvhJDwEzd+4Ueu4ZfJMoTTAdBgNVHQ4EFgQUxVKs6Z2Zpm5UMtU4gkzO+RlIzFEwCQYDVR0TBAIwADANBgkqhkiG9w0BAQUFAAOCAQEAeXOZYJpGuFwObvEqrXm+iHpJBMjw0wpaJke/W9P63a+s/1M4U3dW9ICiPUaoYpSgpdLTCVwDOKZoXa81RQQWnX8OsFT3IC8L0286WueYzBveUsS3bOzx5iQzVdpT1dai/Z4d6fQ7jDwujj9pI/vWUc1Giqc0h0ZeaO/FmAIKceNOu5wO92KMJaWKkIk9xUMud1pxx9lotL+i3zKsCz8DODf56xJBOzUKNEtjuitBnrUxZtTK7aiwk111cA307Loa0t4sMddYG34DO/3C348E0CBu7MvfXFMIaClo1pMIV7G4+eyqoeA1F8i+3oP6RcNmqYai94Eg7mekFN8m051z/A==</X509Certificate></X509Data></KeyInfo></ds:Signature></saml:Assertion></wsse:Security></soap:Header> <soap:Body><wst:RequestSecurityToken><wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType> <wsp:AppliesTo>  <wsa:EndpointReference>   <wsa:Address>https://webpoolbl20a07.infra.lync.com/WebTicket/WebTicketService.svc/WsFed_bearer</wsa:Address>  </wsa:EndpointReference> </wsp:AppliesTo> </wst:RequestSecurityToken></soap:Body></soap:Envelope>
MESSAGE END >>>>>>>>>> HTTP - 2014-10-20T12:42:11.101533Z
(14:42:11) sipe: sipe_schedule_remove: action name=<+http-timeout>
(14:42:11) sipe: sipe_schedule_allocate timeouts count 2 after addition
(14:42:11) sipe: scheduling action <+http-timeout> timeout 58 seconds
(14:42:11) sipe: 
MESSAGE START <<<<<<<<<< HTTP - 2014-10-20T12:42:11.437489Z
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/soap+xml; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-XSS-Protection: 0
PPServer: PPV: 30 H: CH1IDOALGN83 V: 0
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: SASession=; expires=Thu, 30-Oct-1980 16:00:00 GMT;domain=login.microsoftonline.com;secure= ;path=/;HTTPOnly= ;version=1
X-Powered-By: ASP.NET
Date: Mon, 20 Oct 2014 12:42:10 GMT
Content-Length: 884

<?xml version="1.0" encoding="utf-8" ?><S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"><S:Body><S:Fault><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value>wst:FailedAuthentication</S:Value></S:Subcode></S:Code><S:Reason><S:Text xml:lang="en-US">Require strong authentication</S:Text></S:Reason><S:Detail><psf:error><psf:value>0x800434d4</psf:value><psf:internalerror><psf:code>0x800434d4</psf:code><psf:text>Login requires strong authentication.&#x000D;&#x000A;</psf:text></psf:internalerror></psf:error></S:Detail></S:Fault></S:Body></S:Envelope>

then disconnected

[Stefan Becker]

• 1.18.2 is obsolete, please retry with 1.18.4. As you are using a different user and login name you will be affected by a change to the ADFS authentication in 1.18.4.
• please attach the complete --debug log, not just selected excerpts
• do not set server:host unless you really have to. Otherwise SIPE might be talking to the wrong server
• HTTP proxy will most likely not work, unless it is 100% binary transparent to the connections. Please switch it off.

If SIPE can successfully retrieve an authentication token from the ADFS but it is rejected by LMC then I can't imagine that this is a bug in SIPE. SIPE just forwards the token from ADFS to LMC. This will be visible from the full --debug log.

[Nicolas Dély]

Please find a complete log, still same error with 1.18.4

[Stefan Becker]

My guess was right: the token provided by your ADFS is rejected by login.microsoft.com.

(17:29:03) sipe: 
MESSAGE START <<<<<<<<<< HTTP - 2014-10-20T15:29:03.229666Z
...
<t:RequestedSecurityToken>
 <saml:Assertion ....>
 .... everything in here is simply copied as-is ...
 </saml:Assertion>
</t:RequestedSecurityToken>

You'll find that string in the next message

(17:29:03) sipe: 
MESSAGE START >>>>>>>>>> HTTP - 2014-10-20T15:29:03.235849Z
POST /RST2.srf HTTP/1.1
Host: login.microsoftonline.com
...

My guess is that your ADFS is out of sync or not authenticated/authorized to generate valid tokens for LMC.

I'm leaning towards closing this as NOTABUG, because I don't see what could be "fixed" in the code. The only way you could convince me otherwise would be with cleartext wireshark/tcpdump network dumps from the same HTTPS connections generated by the official Windows Lync client with your account. Then I could check for differences.

[Nicolas Dély]

Thank your for this feedback.

A consultant for our lync migration to office365 told me I'm attempting to use my Active Directory user and password against office365 (which is true since the federated ADFS is in the middle) but I have MFA enforced (and our office365 setup only allow UPN and app password)
He suggests also to disable ADFS but currently there is no such option.

Stefan, currently, is it possible to prevent ADFS and authenticate through MFA only? otherwise I suppose this is a new feature request: have a pidgin-sipe option to disable ADFS as well as "Use Single Sign-On" or "Dont publish my calendar information"

What's your opinion?
Do you still wanna my successful lync login tcpdump traces from windows lync 2010 client?

Nicolas

[Stefan Becker]

Disabling ADFS can't be the option here, because your user authentication is local and Lync is external.

You could try to comment out this else if branch in sipe-webticket.c:

    } else if (webticket->webticket_adfs_uri) {
        if ((success = sipe_svc_webticket_adfs(sipe_private,
                               wcd->session,
                               webticket->webticket_adfs_uri,
                               webticket_token,
                               wcd)))
            wcd->token_state = TOKEN_STATE_FEDERATION;
    } else {
        if ((success = sipe_svc_webticket_lmc(sipe_private,

but then SIPE would try to login to LMC directly using your login and AD password.

BTW: are you sure that you have to use login name? Doesn't your ADFS accept also your user name, i.e. leave login name field empty?

I have no idea how multi-factor authentication is supposed to work for automated logins. What would be the other factors? ADFS is supposed to be secured trusted source, i.e. its tokens should be accepted by LMC.

[Nicolas Dély]

When I force webticket->webticket_adfs_uri to NULL then direct login works and I can see all my buddies and send IM to them
cf workaround in attachment.

So do you think it could be a new feature request: having checkbox to prevent adfs lookup?

sorry for cross post

what I mean by direct login is
pidgin: git 271b8ec43f57e7afd317caf4563aae162ecde38a +
siplcs-prevent-adfs-authent-workaround.patch
http_proxy on
username: email address
login: empty
Password: office365 app password

Server: sipdir.online.lync.com:443
Connection type: Auto
User Agent: UCCAPI/15.0.4420.1017 OC/15.0.4420.1017
Authenticated scheme: TLS-DSK
SSO: off
Dont publish calendar off
Email service URL: empty
Email address: empty
Email login: empty
Email password: empty

[Stefan Becker]

OK, so ADFS does not work for your setup, then why is realminfo set up to say otherwise?

Please ask your consultant to remove ADFS URL from your realminfo responses.

[Nicolas Dély]

good point, I will check with IT people ;-)

thank you for support

[Stefan Becker]

Thanks. If I don't hear back from you, I'll close this one as NOTABUG eventually.

[Nicolas Dély]

Yes you can close it

Could you please add a note about your finding in pidgin-sipe FAQ? I mean how you detect adfs is not allowed and when MFA forced, realminfo should not return any ADFS url?

[Stefan Becker]

I don't think this has anything to do with multi-factor authentication. Just Lync mis-configuration :-)

Closing as NOTABUG

[Nicolas Dély]

Hi, after reading some documentation [1] and discuss with IT people, it looks Azure authentication can work differently depending on browser-based app vs heavy client (outlook, lync, ...)

Internally, I understand lync and outlook use app password whereas browser app use adfs.
Externally, lync and outlook still use app password whereas browser app requires phone based authentication (2FactorAuthentication).

So the solution changing getuserrealm.srf result looks not the right one.

Moreover I was able to test with a special account created for this test (MFA feature disable) and adfs authentication works see attached log

I hope it can help you to analyse this behavior

Regards,

Nicolas

[1] http://technet.microsoft.com/en-us/library/dn394284.aspx

[Nicolas Dély]

another interesting description of ADFS3 and MFA support

I guess if we can get
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod

we can see app password method and so prevent adfs webticket

[1] https://authenticationfactor.wordpress.com/tag/mfa/

[Stefan Becker]

Ticket moved from /p/sipe/bugs/267/

Can't be converted:

• _milestone: 1.18.x

[Stefan Becker]

Moved from bugs to feature-requests and re-opened.

I'll be honest with you: unless you (or somebody else) provides a test account where MFA is enabled, the chances to get this implemented are slim.

I'm against adding new settings, because they only confuse users and lead to incredibly incorrect "how I fixed my SIPE setup problem" blog entries.

[Nicolas Dély]

I'm against adding new settings, because they only confuse users and lead to > incredibly incorrect "how I fixed my SIPE setup problem" blog entries.

Indeed, you're right, so I'll do by best to provide you such test account with MFA enabled

[Stefan Becker]

I finally could reproduce the problem with the test account.

Please retry with git commit 39a6ea6. With this change in place I can login successfully from the Internet.

Does this work for you also on the Intranet?

[Stefan Becker]

Feedback from reporter: with latest code he can login from the intranet.

Closing as IMPLEMENTED.