Legacy authentication

Legacy (or basic) authentication is characterized by:

• a client or network protocol which is incapable or not configured to do modern authentication
• a client which sends both the username and password to the application
• an application using the username and password to get a logon token on behalf of the user

Modern authentication is characterized by:

• a client and service capable and configured to use OpenID Connect, SAML, and/or OAuth 2.0 for authentication AND
• a client and service which can accept redirects to the identity provider for all authentication interactions and can work with authentication tokens of the protocols above

All Microsoft cloud services are modern authentication capable.

Whether legacy or modern authentication is used is dependent on the client capabilities. To use modern authentication, you can, in many cases, update your client application or change to an alternative client application.

A list of known clients using legacy authentication is available. Transitioning from legacy authentication usually requires the individual user to change the client software they are using, which may require assistance from departmental IT support.

Protection with two-factor authentication (2FA)

Legacy authentication can not be protected by 2FA. Because the password is known to the application accessed via legacy authentication, it is less secure than modern authentication. If legacy authentication is not blocked for your account, 3rd party applications can ask for your credentials and have your password without you being aware they do.

Transition from legacy authentication

For the typical user, the complexity of determining whether you are using legacy authentication is significant. If you are using one of the client applications does not use modern authentication protocols (see above linked list), you should replace them. If you don’t have one of these client applications but still suspect you have legacy authentication, involving your IT unit can help.

In most cases, users will need to do one or more of the following: 

• Update their application to a version that supports modern authentication protocols
• Upgrade to the latest version of their phone operating system
• Remove and re-add their UW account in the configuration of their iOS or MacOS application so it will use modern authentication protocols –

All three of these actions are informed by the list of known insecure client apps. UW-IT doesn’t know your devices like you do, nor do we manage which client applications you use, so only you can identify where action needs to be taken.

If you don’t seem to have one of the insecure client applications but still suspect you have legacy authentication, involving your IT unit can help. They have access to logs which may assist you in identifying which of your devices needs attention.

To remove your UW account on iOS:

1. Open Settings
2. Choose ‘Calendar’ or ‘Mail’
3. Choose ‘Accounts’
4. Choose ‘Exchange’ or ‘Google’ — make sure you are choosing an account in the format uwnetid@uw.edu
   
5. Choose ‘Delete account’
   
6. Confirm deletion by choosing “Delete from my iPhone”
   

To re-add your UW Exchange account on iOS (note: only slight modifications are needed for Google):

View Apple’s documentation on how to add an email account to your device or follow the directions here.

1. Open Settings
2. Choose ‘Calendar’ or ‘Mail’
3. Choose ‘Accounts’
4. Choose ‘Add Account’
   
5. Choose ‘Microsoft Exchange’
6. Enter the UW email address you’d like to add and select Next
   
7. At the dialog select ‘Sign In’
   
8. This will take you to the modern sign in for the UW Entra ID. Complete sign in. You may be required to verify your identity with Duo. If so, you’ll be asked if you’re logging in to “Azure Active Directory”.
        
9. If you chose ‘Microsoft Exchange’ you’ll see consent screen for Apple Internet Accounts. You’ll need to ‘Accept’ to proceed. This allows the client app to access your mailbox/calendar data.
   
10. Select the services you’d like to enable then choose ‘Save’
    

This list is not intended to be comprehensive; it is only a list of known client applications. If you have one which should be added, please let us know.

You may see an email in your UW inbox like this:

While the email message says it was sent by your IT department, it was not. This email message wasn’t actually sent–it only exists on your mobile device and was created to alert you to the fact that your client application can’t sign into your account. Your email access has not been blocked–it is only that this client application is broken. You can verify for yourself that your email access was not blocked by going to Outlook on the Web. And the reason the client application is broken is because it can only do legacy authentication OR it only has cached credentials which are based on legacy authentication.

One of three things likely happened to cause this error message:

1. You are a student and have not opted into ‘UW Duo 2FA for the web’. As a result, you have been assigned a terms of use reminder screen. That screen is not compatible with legacy authentication and is invisible to you when you try to open your email client. You must accept it to continue, but you can’t see it. To resolve, you must either fix your email client or opt into 2FA. If you opt-in, the terms of use screen will no longer be present.
2. You have opted into 2FA and are using an iPhone with 15.6 or better. In this scenario, Apple tries to automatically convert your cached legacy authentication credentials into cached modern authentication credentials silently. However, because 2FA is part of the experience, you must interact with something which is designed to be invisible to you. You may need to remove your UW account and re-add it in order to complete the process.
3. You have waited beyond the deadline communicated to you and your use of legacy authentication has been blocked. To resolve, fix your email client.

We have published log details about legacy authentication in a CSV file, with data from each day in a separate CSV file. We plan to keep 30 days worth of data. Employees of UW-IT and all OU administrators have access–access to the data is available to current employees for IT support and information security purposes only. Other IT staff can request access via help@uw.edu with a subject line of “Microsoft Infrastructure: Legacy authentication reporting”.

Searchable legacy authentication logs (interactive and non-interactive sign-ins)

Downloadable legacy authentication logs (daily CSVs, interactive sign-ins only)

If you receive a notification that we detected legacy authentication, but you don’t show up in the logs above, this may be because of a known problem. The sheer size of log data involved means that we are limited in terms of how far back we can provide the data in the searchable tool (42 days is our limit). Contact UW-IT and we can do a search specific to your username against the data which will circumvent this known problem.

The following fields are available in these reports:

• Client application: the individual component within the cloud application service reporting the legacy authentication
• Sign-in status: whether authentication succeeded or not
• Mask IP address: the last two octets of the client IP address. The full address has been masked to address privacy concerns.
• App: the cloud application service reporting the legacy authentication
• Error code: error codes reported as part of the authentication
• Operating system: the client platform, if available to the cloud application service
• Browser: the client application name or information, if available to the cloud application service
• Country or region: the country of origin for the client
• State: the state of origin for the client
• City: the city of origin for the client
• Time generated: timestamp for the authentication
• User Principal Name: the fully qualified username
• User: the display name of the user

Determining the client application is not necessarily straightforward, but this is the best data available.

In most cases, you should be able to leverage the combination of these fields to narrow down the source of legacy authentication to a specific device, then use the list of known clients (in concert with any data in the browser field) to determine which client application needs to be upgraded or replaced on that device.