Using MFA with rich clients such as Outlook Skip to main content
https://support.okta.com/help/answers?id=906f0000000i0gkiak&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Tom FreemantleTom Freemantle 

Using MFA with rich clients such as Outlook

Hi there,

I'm currently testing out MFA. We have Office 365 federated with Okta. I can set up an off-network policy for logging into Okta with Okta Verify. It works well and I get prompted as expected.  My question is how does this work with rich clients such as Outlook?  I can use an off-network laptop to set up a new mail profile for Outlook.  Everything goes fine and I log in to the account and start downloading emails.  However, I'm not prompted for a second factor of authentication at any point.  Shouldn't the MFA policy kick in during, at least, first log in?

I've treid an Okta wide MFA policy and an application specific MFA policy.  Neither seem to prompt when not using a browser.

Cheers
Tom

Best Answer chosen by Tom Freemantle
Edward HollidayEdward Holliday (Okta, Inc.)
Yes and you are NOT seeing the Okta MFA because the 'JSON refresh token period' for the Desktop/ Outlook rich client is set by default to somewhere between 14-90 days. It is this that is authenticating the user each time NOT a new authentication call to Okta IdP.

O365 caches this and doesn't present it to the Okta IdP for authentication. If there is no authentication or 1FA then we i.e. Okta cannot invoke the 2FA or second factor - does that make sense?

So you have 2 (or 3) options to move forward:
  1. Stick with ADAL enabled in your tenant, but reduce the effect of the 'JSON refresh token period' by making a O365 "configurable token lifetimes" change to  'MaxInactiveTime' and 'MaxAgeSingleFactor' properties
  2. Or consider Okta's O365 'Client access policy' enhancement as a way forward
  3. 3rd option - look out for Roadmap  'Device trust' enhancements

All Answers

Eric KarlinskyEric Karlinsky (Okta, Inc.)
Hey Tom,

The issue with older clients is that they only support simple authentication; there is no opportunity for interaction, wherein the end user could perform MFA. This applies also to ActiveSync clients, such as older versions of Outlook or Native Mobile Mail applications on either iOS or Android. Due to the technical limitations of these older clients, it's common to disable MFA for authentication requests which rely on ActiveSync protocol. Otherwise, authentication would fail and end users would not be able to access email. This is likely what you're experiencing on your Okta implementation today.

The approach that I recommend, if you're using Office 365, is to enable ADAL on the thick clients. See here (https://support.office.com/en-us/article/Enable-Modern-Authentication-for-Office-2013-on-Windows-devices-7dc1c01a-090f-4971-9677-f1b192d6c910) for instructions on how to do that. Once ADAL is enabled, the thick client is able to perform the broswer-based WS-Federation authentication flow. This can include MFA, so if MFA is enabled for either the app or Okta as a whole, you will be prompted. Some mobile clients, such as the Microsoft Outlook iOS app, also support the WS-Federation flow.

Eric
Tom FreemantleTom Freemantle
Hi Eric,

Thank you for the reply.  It's good to know about the ADAL settings. I was coming at it from a slightly different angle though.  Everything is working fine with MFA enabled for Okta as a whole.  I was expecting it to break or prompt, but it didn't seem to do either.  I thought this was maybe a security hole in the MFA policy as an attacker could use a thick client to circumnavigate MFA.  Appologies if I've misunderstood something.

Thanks,
Tom
Edward HollidayEdward Holliday (Okta, Inc.)
... So your use case/ security requirement is how do you get MFA to prompt/ trigger on thick clients more frequently?

The trouble we have is that (with ADAL/ modern ADAL enabled rich clients) whilst we can enforce MFA the 1st time/ or when a user authenticates to the client- we can't enforce the 2FA frequency- say every 8 hours regardless (we are only the 2nd factor)

The 1st factor is triggered by the fat client JSON Web Token/ refresh token which typically lasts 14-90 days and is NOT triggered again until the password is changed (and possibly not ever if the new password is synched by Okta)

see https://support.office.com/en-us/article/Session-timeouts-for-Office-365-37a5c116-5b07-4f70-8333-5b86fd2c3c40

Would Okta customer's like to trigger re-authentication (for ADAL Outlook fat clients) more frequently from the 1st factor (and thereby Okta MFA) every 8 hours/ each day say?

You can now modify the default  'JSON refresh token period' to invoke a more frequent 1st factor/ OKta MFA authentication event, for these ADAL enabled Outlook clients ...

this is done with "configurable token lifetimes" - see the 'MaxInactiveTime' and 'MaxAgeSingleFactor' properties
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes
only caveat is that it will apply an Okta authentication event more frequently for ALL Outlook client users whether they are off or on the corporate network
Tom FreemantleTom Freemantle
Hi Edward,

My problem is, we configured a rule that requires MFA always when off network.  When a user tries to get to Okta/O365 via their browser, they are prompted for a second factor.  However, if they have Outlook on their home machine, they can connect to their inbox without ever needing to give a second factor.  It just works for them.  This is great for the user, but seems like a security hole or at least a way around MFA.  Maybe I'm doing something wrong, but that's how it apeared to work when we were testing it.

Thanks,
Tom
Edward HollidayEdward Holliday (Okta, Inc.)
Yes and you are NOT seeing the Okta MFA because the 'JSON refresh token period' for the Desktop/ Outlook rich client is set by default to somewhere between 14-90 days. It is this that is authenticating the user each time NOT a new authentication call to Okta IdP.

O365 caches this and doesn't present it to the Okta IdP for authentication. If there is no authentication or 1FA then we i.e. Okta cannot invoke the 2FA or second factor - does that make sense?

So you have 2 (or 3) options to move forward:
  1. Stick with ADAL enabled in your tenant, but reduce the effect of the 'JSON refresh token period' by making a O365 "configurable token lifetimes" change to  'MaxInactiveTime' and 'MaxAgeSingleFactor' properties
  2. Or consider Okta's O365 'Client access policy' enhancement as a way forward
  3. 3rd option - look out for Roadmap  'Device trust' enhancements
This was selected as the best answer
Tom FreemantleTom Freemantle
Thanks for this Edward, really useful stuff.

I assume the token lifetimes are also the reason our internal users get prompted by Outlook for credentials all the time.  This leads them to tick the 'remember my credentials' box.  This causes Windows to cache the credentials, but when the AD password changes, we need to flush the credential cache on peoples machine.

I'll have a play around with the polices.

Cheers
Tom
ADM Steve SlavieroADM Steve Slaviero
Hi Edward,

In the section below in BOLD:

Or consider Okta's O365 'Client access policy' enhancement as a way forward
configure an "Any Client" or  “Desktop application” policy as documented here  Office 365 Client Access Policies (Blog) (https://support.okta.com/help/blogdetail?id=a67F0000000L1QlIAK) Office 365 Client Access Policies (Knowledge Article) (https://support.okta.com/help/articles/Knowledge_Article/Getting-Started-with-Office-365-Client-Access-Policies)
caveat that the "Desktop application" policy needs ADAL disabling which might be an issue, if it is then use one of the other Client access policies -probably "Any Client" rule

Do you mean that ADAL needs to be disabled in our Office 365 Tenant?  Or do you mean disable ADAL on the desktop application on the laptop?

We're running Office 2016, which I think has ADAL enabled by default.  Correct me if I'm wrong...

Thanks,
Steve
 
Edward HollidayEdward Holliday (Okta, Inc.)
Hello Steve

Yes ADAL would neec to be disabled in the O365 tenant ....

see
"Note: Modern Authentication is a configurable setting on the Office 365 tenant for Exchange Online. For more information about configuring this setting, refer to Microsoft’s documentation at https://support.office.com/en-us/article/Enable-Exchange-Online-for-modern-authentication-58018196-f918-49cd-8238-56f57f38d662 "

So you would loose the benefit(s) of ADAL, BUT at least you would be able to distinguish Desktop/ thick client applications again, whereas with ADAL in the O365 tenant enabled they just look like browsers to Okta.

I would test this out in an Okta preview tenant/ O365 trial license tenant if you want an MFA policy to protect access specifically from Desktop/ thick clients
 
Srujan Reddy KolaSrujan Reddy Kola
Hi Edward,

We have a similar situation, where we are not experiencing the MFA for non-network access with the Modern Authentication enabled on the Office 365 side for Desktop and Mobile Clients. You said above that the MFA may be delayed for 14 - 90 days based on the O365 setting, but in our case we are not seeing the 2nd factor prompted for Thick Clients for the very first time access. Can you please suggest something here.

Thanks,
Srujan.