#105 Add Support for Microsoft's Modern Authentication / ADAL

[Roland]

Requesting to add support for Microsoft's "Modern Authentication", which is a new Microsoft authentication method that allows ADAL-based sign in and multi-factor authentication. Essentially it is Microsoft's implementation of OAuth 2.0.

I noticed that MFA support was recently added for ADFS (https://sourceforge.net/p/sipe/feature-requests/76/). However, I am using Duo for MFA on a Hybrid Office 365 / ADFS domain with the latest Sipe plugin, and can't login . From some research it seems as if clients need to support Microsoft's ADAL / Modern Authentication in order to login to Duo MFA. Is it possible to add support for this type of login via Sipe? Here is a good rundown of related info https://help.duo.com/s/article/4419?language=en_US

Attached are debug logs from Pidgin for a failed Duo MFA login.

[Stefan Becker]

First: SIPE does not support MFA. Feature request #76 is about of falling back to an alternative authentication method for clients that do not support MFA.

---

Second: I'm not aware that M$ Lync/SfB clients do support MFA either

• where and when would you supply the 2nd factor in the client?
• how would resuming from suspend work (client needs to reconnect)?
• how would re-authentication timeout be handled (usually happens every 8 hours)?

I'm happy to be proven wrong if you can provide some screen shots or videos that show how 2nd factor is handled in M$ Lync/SfB clients.

---

Third: as far as I remember adding 2nd factor authentication to an existing authentication scheme based on name & password using Duo mobile app doesn't require any changes to clients. When a client authenticates to the server then the authentication infrastructure sends a request to the Duo infra. The authentication request is completed after the user accepts the "Please confirm" notification on his mobile device. I.e. the 2nd factor handling is transparent to the client.

I haven't used Duo app for two years, so I might remember some details incorrectly.

---

Fourth: you didn't enable unsafe debug logging (see FAQ). Therefore the debug log doesn't include the contents of the last response from your ADFS server which leads to the authentication failure:

(12:08:26) sipe: sipe_http_transport_connected: adfs.mydomain.com:443
...
(12:08:26) sipe: sipe_svc_https_response: code 200
...
(12:08:26) connection: Connection error on 0x5588d5c26920 (reason: 2 description: Web ticket request to https://webdir0B.online.lync.com:443/CertProv/CertProvisioningService.svc failed)

[Stefan Becker]

The provided link to the Duo documentation page isn't really helpful, because the documents there only discuss administrative procedures, not implementation details.

So if we really need new implementation in SIPE to support this feature request, you'll either need to

• setup a MITM attack environent to collect clear text protocol logs of the communication between a M$ Lync/SfB client and the servers, or
• provide a non-intranet test account so that SIPE developers can run those MITM attack themselves.

[Roland]

Thanks Stefan,

Unsafe Pidgin log is attached, the login error mentions indicates a "web ticket request failed".

In answer to your questions about MFA on Skype4B

When logging into Skype for Business on Windows, a separate window pops up with an ADFS + Duo login (appears to be a stripped down browser window). My guess is that this browser window stores OAuth tokens which are periodically updated by the client. This popup does not reappear on subsequent logout/login or reboots. A bit more info on session timeouts can be found here. Long story short: there is a 90+ day refresh token and a 1 hour access token. The refresh token is used to acquire new access tokens periodically. Tokens are stored in the Credentials Manager on Windows .

My best guess to your questions:
Where and when would you supply the 2nd factor in the client?
* Browser popup during login used to obtain MFA login tokens ?? How would resuming from suspend work (client needs to reconnect)?
* Locally stored long-lived refresh token is used to obtain a new access token when needed
* How would re-authentication timeout be handled (usually happens every 8 hours)?
* Locally stored long-lived refresh token is used to obtain new access token before timeout

It's tough to find details on implementation. This page has a bit of info on Duo infrastructure https://duo.com/docs/adfs I'm not sure if I can get a test account setup, we'll see. I will try to MITM myself if I have time. I wish I knew more but I'm not an AD admin on this domain, so I don't have access to the backend infrastructure.

[Stefan Becker]

Thanks for the extended log.

The log doesn't show anything out of the ordinary, just the usual protocol handshake messages that lead up to your ADFS. The ADFS response does not contain the usual XPath Body/Fault/Detail/error/internalerror/text which is the reason why SIPE doesn't provide a detailed failure message. Instead Body/Fault/Detail node has a IssuanceAuthorizationFault child node, but that doesn't tell us anything:

  <s:Body>
    <s:Fault>
      <s:Code>
        <s:Value>s:Sender</s:Value>
        <s:Subcode>
          <s:Value xmlns:a="http://schemas.xmlsoap.org/ws/2005/02/trust">a:FailedAuthentication</s:Value>
        </s:Subcode>
      </s:Code>
      <s:Reason>
        <s:Text xml:lang="en-US">MSIS7068: Access denied.</s:Text>
      </s:Reason>
      <s:Detail>
        <IssuanceAuthorizationFault xmlns="http://schemas.microsoft.com/ws/2009/12/identityserver/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"/>
      </s:Detail>
    </s:Fault>
  </s:Body>

The Duo ADFS integration documentation isn't really helpful. Looking at the "Network Diagram" section at the end of the page would support my original statement that the Duo authentication is transparent and handled by a mobile app (steps 3-5) which is invisible to the client that initiated the ADFS login.

Here are some other things you might try:

• install Pidgin + SIPE on the Windows machine where you use the M$ SfB client. Do you get the Duo login window, just like with the M$ SfB client?
• try M$ SfB Client on Mac OS X. Does Duo MFA work on that platform?
• your log shows that you set the Login field in the SIPE account settings to <AD name>\<AD account>. What happens if you leave that field empty, Ie. SIPE would try to authenticate against the ADFS with username@domain.com instead? Please remember to take a log.
• upgrade to SIPE 1.24.0 and check if different user agent values, which are now also used for HTTP, have any effect (see FAQ).
• a Goggle search forIssuanceAuthorizationFault led to this M$ support page: Create an for app password for Office 365. Can you try this approach?

[Roland]

Thanks Stefan,

An App Password was the first thing I tried, but they are not permitted for security reasons unfortunately because essentially it allows bypassing MFA.

I attempted leaving the Login blank to allow SIPE to use username@domain.com (unsafe debug log attached). This seems to have given the exact same error. Error message in the GUI:
"Web ticket request to https://webdir0B.online.lync.com:443/CertProv/CertProvisioningService.svc failed"

I also tried Pidgin + SIPE from a Windows machine, which gives the exact same error. I can send Windows logs if needed.

I have tried changing the User Agent, but I think the user agent I'm using should be accurate because it's the one specified by others on my network, and it worked before enabling MFA on my account. I am currently on SIPE v1.24.

[Joakim Tjernlund]

GNOME Evolution (EWS) supports OAuth against O365, maybe one can get hints from there?
Works fine here but SIPE will stop working one they make OAuth mandatory