This article explains an issue where Multi-Factor Authentication (MFA) and Office 365 sign-on policies may not be enforced when users access their emails via third-party clients. It will outline the causes of this issue and suggest a resolution.
Symptoms:
-
Office 365 sign-on policies are not being enforced when accessing email from a third-party email client.
-
Users are not being prompted for MFA as expected when accessing Office 365 email from a third-party email client.
-
Users are getting locked out by multiple login attempts, but users are not attempting to log into Okta.
-
Okta System Log entries indicate a successful sign-in attempt and do not indicate that MFA did not occur.
-
Expanding the System Log event to display Client > UserAgent reveals several Unknown and Null entries, as in the example below:
-
- Microsoft Office 365
- Post Office Protocol (POP)
- Internet Message Access Protocol (IMAP)
- Okta Classic Engine
The issue arises when an email client utilizes POP or IMAP protocols to connect to Office 365. These older protocols do not support sign-on policies or MFA. As a result, users might not be prompted for MFA as expected, and Office 365 sign-on policies may not be enforced. The signs of this situation may include successful sign-in attempts in the Okta System Log that do not reflect MFA, or users being locked out despite not making login attempts.
In order to enforce sign-on policies and MFA for Office 365 email access from an email client, the client needs to support Modern Authentication and be properly configured for its use. Here is how to ensure these conditions are met:
- Confirm that the email client being used supports Modern Authentication.
- Configure the mail client to use Modern Authentication.
If required to prevent email clients from using POP or IMAP to connect to Office 365 explicitly, Microsoft provides a guide titled How to enable or disable POP3, IMAP, MAPI, Outlook Web App or Exchange ActiveSync for a mailbox in Office 365. Please refer to it for detailed steps.
