Auditing your Okta org for Legacy Authentication

Brett Winterford

Using Okta System Logs to monitor use of basic authentication to Office 365

As promised on the Risky Business podcast, here are some System Log queries to help Okta administrators weed out examples of clients connecting to their Office 365 tenant over basic authentication (“legacy authentication”, in Microsoft parlance.) If you already know why these authentication methods are risky, skip straight on to the queries and containment strategies. Otherwise, read on!

In 2019, Microsoft announced the deprecation of basic authentication for Microsoft 365 (formerly Office 365), which if all had gone according to plan, would be disabled on all tenants by now.

Basic Authentication are methods to authenticate to Office 365 using only a username and password. It’s a mode of authentication that doesn't support OAuth2, so administrators can’t protect that access with multi factor authentication or client access policies. That makes any account in an Office 365 tenant that hasn’t disabled basic authentication far more vulnerable to credential stuffing, because its security relies on the strength of user-defined passwords.

Given the availability of hundreds of millions of stolen credentials, account checker tools that are “point and shoot” and proxies that attempt to anonymise the source of requests, credential stuffing has developed into an industry-wide problem. A disproportionate volume of credential stuffing activity detected by Okta’s ThreatInsight targets Office 365 tenants, specifically, checking credentials stolen from third parties against accounts with basic authentication enabled.

Why is this still a problem?

Today, basic authentication is disabled by default in any new Office 365 tenant, just as it has been in the default Okta access policy for some time. But there are a number of reasons Microsoft customers continue to use it:

  1. Lack of awareness: If an Exchange Online tenant was activated before August 2017, it was configured to use basic authentication by default. Administrators must actively enable modern authentication and disable basic authentication to remedy this.

  2. Lack of visibility: Administrators may not understand the full breadth of older Microsoft clients and third party apps still connecting via basic authentication until basic authentication is disabled or they explicitly search for it.

  3. Business requirements: Some organizations rely on third-party apps/Outlook plugins that haven’t upgraded to modern authentication. Modern authentication methods are almost always available.

Block basic authentication at the source

Okta advises Microsoft customers to enable modern authentication and disable legacy authentication to Exchange Online using PowerShell before federating Office 365 access to Okta (at either the tenant or mailbox level). Once Office 365 is federated to Okta, administrators should check Okta’s System Logs to ensure all legacy authentication requests were accounted for.

Use Okta’s System Log to find legacy authentication events

Let’s start with a generic search for legacy authentication in Okta’s System Log.

If you already know your Office 365 App ID, the search query is pretty straightforward.

  1. Navigate to Reports > System Log.

  2. Set an appropriate date range and enter the following query into the search field:

    debugContext.debugData.requestUri eq "/app/office365/{office365 App ID}/sso/wsfed/active

Tip: If you can’t immediately find your Office365 App ID, here are two handy shortcuts.

  • Navigate to Applications and search for office to locate and select the relevant Office 365 instance. Select View Logs to open System Log with the Office 365 app ID pre-populated in the search field. Copy the App ID into the search query in (2) above.


  • From Reports > System Log, set an appropriate date range and type office365 into the search field.

  1. To find events that were authenticated via the Legacy Authentication endpoint, expand on user login events and select Expand All to see the full context of the request. Look for login events under System > DebugContext > DebugData > RequestUri that include the string sso/wsfed/active.

  2. Click on any string with the sso/wsfed/active endpoint and it will populate a new search, as described in (2) above, only now with the Office 365 App ID inserted into the query.

Using Okta’s System Log to find FAILED legacy authentication events

You can also limit your search to failed legacy authentication events using the following System Log query:

eventType eq "user.session.start" and outcome.result eq "FAILURE" and debugContext.debugData.requestUri eq "/app/office365/{office365 App ID}/sso/wsfed/active"

Auditing your events by IP or user agent

If search results return a large number of events from a diverse range of devices, the best option is to:

  1. Filter on the same events from logs exported to your SIEM, or

  2. Export the search results from the System Log to a CSV file for further analysis by selecting Download CSV.

When troubleshooting a relatively small number of events, Okta’s System Log may suffice. With any of the prior suggested searches in your search bar, select Advanced Filters.

The debugContext query should appear as the first filter. The search can now be refined by:

  • User Agent (client.userAgent.rawUserAgent)

  • Client IP (client.ipAddress)

  • Client Operating System (client.userAgent.os), or

  • Client Browser (client.userAgent.browser)

  • City (

  • Country (

  • ISP (securityContext.asOrg)

  • Client email address (check “actor.alternateId” or “target.alternateId”)

Place the mouse cursor in “Enter Field Value” and System Log will list all the available results from events in the System Log.NB: these results won’t be limited to the previous conditions in your search. If the number of choices is overwhelming, we recommend exporting the search to a CSV or continuing the search in a SIEM.

We recommend saving relevant searches as a shortcut for future use.

  1. Select Save (it’s next to the search icon).

  2. Give the search a name

  3. The custom report will now be permanently listed at the top-right of Reports > Reports

Common user agents in legacy authentication logs

Here are some common user agent strings from Legacy Authentication events (those with “/sso/wsfed/active" in the requestUri.

User Agent Contains


Common issues and fixes


Exchange Web Services (EWS)

EWS is an API used in Outlook apps that interact with Exchange (mail, calendar, contacts) objects.

Microsoft’s OAuth2-compliant Graph API is subject to licensing restrictions.

NB: Your Okta tenant will not have visibility of EWS authentication events that (a) support basic authentication and (b) authenticate to the domain instead of the domain federated to Okta.

Apple-iPad, Apple-iPhone

Native mail clients on iOS devices

Apple’s native iOS mail app has supported Modern Authentication since iOS11.3.1 (Sept 2017). If a user’s mail profile was configured prior to this date, the basic authentication profile may remain unchanged and will need to be reset.


Native Android mail client

Android’s native mail client does not support modern authentication. Instruct users to configure Outlook, Gmail or other mobile apps that support modern authentication.

Microsoft Outlook

Outlook for Windows

Outlook 2010 and below on Windows do not support Modern Authentication. Modern Authentication can be enabled on Office 2013 clients by modifying registry keys.


Outlook for Mac

Outlook 2011 and below on MacOS only support Basic Authentication. If newer versions connect using Basic Authentication, the user’s mail profile may need to be reset.

AppleExchangeWebServices CalendarAgent

MacOS Mail and Calendar clients

MacOS Mail did not support modern authentication until version 10.14. Instruct users to upgrade to a more recent version. If a mail profile was manually configured for basic authentication, this mail profile must be removed and a new one established using the “sign-in” workflow in the MacOS Mail client.


Exchange ActiveSync on Android and iOS

Instruct users to configure Outlook, Gmail or other mobile apps that support modern authentication.


Legacy PowerShell client

Instruct admins to upgrade to EXO V2 module to support modern authentication.

ZOOM (usually followed by OS)

Zoom video conferencing 

“Zoom Rooms” offers two authentication profiles to integrate with Exchange Online. Switch from basic authentication to the OAuth 2.0 option. 

An audit of your legacy authentication will undoubtedly unearth various bots and crawlers, BITS jobs and all sorts of other things to make you feel anxious. The whole exercise is a good reminder to monitor logs for red-flags on a semi-regular basis: As you get used to doing this, your muscle memory for these processes will grow, along with your understanding of what “normal” looks like in your environment. Happy hunting!

This article is the first of a three-part series. Our second entry calculates the risks associated with using Microsoft legacy authentication.

Brett Winterford
Regional CSO, Okta APJ
Brett Winterford is the regional Chief Security Officer for Okta in the Asia Pacific and Japan.
He advises business and technology leaders on evolving threats and helps them harness advances in identity technology to drive business outcomes and mitigate risk.
Prior to Okta, Brett held a senior security leadership role at Symantec, and helmed security research, awareness and education at Commonwealth Bank.
Brett is also an award-winning journalist, having long ago been the editor-in-chief of iTnews Australia and a contributor to ZDNet, the Australian Financial Review and the Sydney Morning Herald. Most recently, he was the founding editor of the Srsly Risky Biz newsletter, a companion to the Risky Business podcast, providing the cybersecurity, policy, defense and intelligence communities with a weekly brief of the news that shapes cyber policy.