Auditing your Okta org for Legacy Authentication

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.
  

OR

• 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 (client.geographicalContext.city)
• Country (client.geographicalContext.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. 

Save and export your search

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.

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.