IT Connect
Your connection to information technology at the UW

Azure AD Authentication

Azure AD provides authentication via SAML, OpenID Connect, and OAuth 2.0. This page covers topics related to user authentication with Azure AD. For more on application integration with Azure AD, see Azure AD Applications.

Azure AD Authentication topics

UW NetID integration

UW’s Azure AD is integrated with the UW NetID system. If your UW NetID is “pottery” then your Azure AD username is pottery@uw.edu. This longer form is called the user principal name or UPN. Every cloud-based experience will require this longer form because cloud-providers can not assume you are from the UW, like the UW identity provider can.

Your Azure AD user account is provisioned based on its status in the NETID Active Directory; if it is inactive, disabled or deleted there, it will not exist in the UW Azure AD.

At this time, the uw.edu Azure AD domain is federated.

Federated Authentication Experience

The uw.edu Azure AD domain is federated with the UW ADFS service, sts.netid.washington.edu. In turn, the UW ADFS service is federated with the UW identity provider, idp.washington.edu. This means that after you provide your UPN, Azure AD will redirect you to sts.netid.washington.edu, which will redirect you to idp.washington.edu, where you’ll see the familiar sign in experience there.

After you’ve entered the UPN, Microsoft first checks to see what type of account it is, and whether there are multiple types of accounts with that UPN. If there are multiple types of accounts with that same username, it asks whether the account is a work/school account or a personal account. In almost all cases, you should chooose work/school account. See here for more info.

The typical sign-in experience for a federated uw.edu Azure AD user account is detailed here.

Cloud-only Authentication Experience

We are synchronizing the NETID Active Directory password hashes to the uw.edu Azure AD. At some point in the future, we will transition the uw.edu Azure AD from federated authentication to cloud-only authentication. This event should not be disruptive–it only changes the user experience.

Individual users can be configured with this cloud-only authentication experience now. To do so, anyone with a personal UW NetID can join (and unjoin) this group: https://groups.uw.edu/group/u_msinf_aad_phs_optin. If you have another type of UW NetID you’d like to opt-in, you’ll need to request it via help@uw.edu.

After joining the group, you’ll need to wait for Azure AD Connect to synchronize the group to Azure AD which could be up to an hour. Any sign in after that should follow the cloud-based authentication experience. We recommend that you have also opted into the Duo 2FA for Web. That combined experience of cloud-only authentication with Duo 2FA is documented here.

External Users

Azure AD allows users from other organization’s Azure AD tenants and personal Microsoft Accounts to be guest users in your Azure AD tenant. These guest users are called External Users. Once an external user is present in your Azure AD tenant, they can be permitted access to resources in our Azure AD tenant. Azure AD Conditional Access policies can be applied to external users. Leveraging some of these other capabilities may require additional licensing, so there may be a cost associated.

Within the uw.edu Azure AD enterprise tenant, we allow any user in the tenant to invite external users. In the future, as Microsoft develops the management capabilities for external users, there may be additional restrictions or limitations.

Your uw.edu Azure AD account may be an external user in another organization’s Azure AD. You can tell whether it is or not by going to https://myworkaccount.microsoft.com/organizations. You can remove your external user account in those other organizations via that same interface.

Your sign ins

Your Azure AD sign ins are logged and you can review them. See https://mysignins.microsoft.com/ for more info.

2FA Authentication

Token lifetimes, Remember me, and Preventing Misuse

Unlike the UW identity provider, Microsoft’s Azure AD product has authentication tokens with long lifetimes. Microsoft’s design reflects their extensive experience and analysis on the impact of token lifetime on overall security as well as the user experience. Microsoft has found that binding your Azure AD authentication token to a device, along with a lengthy default token lifetime, and token revocation events that are triggered when something risky is detected result in the best security and user experience. To be clear, Microsoft has found that requiring users to sign-in frequently causes users to grow fatigued about entering their credentials and therefore be more easily fooled by malicious phishing attempts.

For this reason, the Duo ‘remember me’ guidance doesn’t have meaning for Azure AD; an Azure AD token essentially lives forever unless something happens to require a fresh sign-in. For more information about token lifetimes, see https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes#configurable-token-lifetime-properties.

In contrast, Azure AD access tokens do not live forever. A unique Azure AD access token is needed to access each application which requires Azure AD sign-in. Azure AD access tokens have a maximum lifetime of 1 hour.

When misuse is detected on a uw.edu Azure AD user account, all of its tokens are revoked and an Azure AD Conditional Access policy blocks issuance of any new Azure AD access tokens. For more information about token revocation, see https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens#token-revocation.

Conditional Access

Conditional Access (CA) is a powerful feature that allows security controls to be enforced at the time an access token is requested based on a variety of conditions. UW support for Conditional Access is limited at this time. If you feel you need a CA policy, send a request and we’ll consider it.

Legacy Authentication

“Legacy authentication” is a term Microsoft sometimes uses to describe basic authentication when used with its cloud-based services. This is in contrast with the term “modern authentication” which provides more security and capabilities, via SAML, OpenID Connect, or OAuth 2.0. Legacy authentication is insecure and caused by the choice of client application. At some point in the future, we expect legacy authentication to be blocked. For example, Microsoft plans to turn most legacy authentication off for Exchange Online in 2021.

Departmental IT units should read more about legacy authentication, leverage the reporting resources we’ve provided, and when ready, block legacy authentication for their users.

Last reviewed April 27, 2020