<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008C3jazSABOkta Classic EngineMulti-Factor AuthenticationAnswered2025-04-06T09:04:16.000Z2016-05-23T22:52:11.000Z2018-10-16T06:28:48.000Z

TomF.32212 (Customer) asked a question.

Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:19 AM
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

  • 12 answers
  • 17.1K views

  • edward.holliday1.413788283869593E12 (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. https://docs.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes
    3. This will affect all user ON and OFF network - they will be asked to go through Okta Authentication more frequently with the Desktop/ Outlook client (although ADAL/ IWA will be used on network)
    4. But the effect of your MFA off network policy, will kick in and MFA for Outlook will be seen more often off-network
      
    • 3rd option - look out for Roadmap  'Device trust' enhancements
    Expand Post
    Selected as Best

  • eric.karlinsky1.4147731941881877E12 (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
    Expand Post

  • TomF.32212 (Customer)

    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
    Expand Post

  • edward.holliday1.413788283869593E12 (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
    Expand Post

  • TomF.32212 (Customer)

    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
    Expand Post

  • edward.holliday1.413788283869593E12 (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. https://docs.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes
    3. This will affect all user ON and OFF network - they will be asked to go through Okta Authentication more frequently with the Desktop/ Outlook client (although ADAL/ IWA will be used on network)
    4. But the effect of your MFA off network policy, will kick in and MFA for Outlook will be seen more often off-network
      
    • 3rd option - look out for Roadmap  'Device trust' enhancements
    Expand Post
    Selected as Best

  • TomF.32212 (Customer)

    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
    Expand Post

  • Steve Slaviero (Customer)

    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

    Expand Post

  • edward.holliday1.413788283869593E12 (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

    Expand Post

  • 0kum7 (0kum7)

    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.
    Expand Post

  • 00u4tguvf7AqKV3GA2p61.507903644107573E12 (Customer)

    Why can Okta MFA be bypassed when using an iOS or Android device? Isn't this a huge security flaw in the MFA method(s)? If we point the finger to ActiveSync, what is the proper way to secure an account if I can simply go to any iOS or Android device to get access to the account if I know the account password? What are the technical details to this being an issue or hole Microsoft has not plugged?

    Expand Post
10 of 12
This question is closed.
Loading
Using MFA with rich clients such as Outlook