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.

Authentication Experience

The uw.edu Azure AD domain uses UW NetID passwords in the form of Microsoft calls password hashes. This jargon just means your password is not actually present in Microsoft’s cloud-based Azure AD, but a derived form of it which can be used to verify whether the password you provide to prompts is correct.

When signing in, after you’ve entered the user principal name (e.g. uwnetid@uw.edu) , Microsoft first checks to see what type of account it is, and whether there are multiple types of accounts with that user principal name (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.

We recommend that users opt into the Duo 2FA for Web.

You will have one of two sign-in experience based on whether your account is configured to require Duo 2FA:

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.

Microsoft documentation for leaving an organization: https://docs.microsoft.com/en-us/azure/active-directory/external-identities/leave-the-organization

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 of the impact of token lifetime on overall security and the user experience. Microsoft has found that binding your Azure AD authentication token to a device with a lengthy default token lifetime paired with 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 UW Duo ‘remember me’ guidance doesn’t have meaning for Azure AD; an Azure AD identity token essentially lives forever unless something happens to require a fresh sign-in.

An Azure AD access token (constrained to the AAD application) is obtained when the user wants to access an application which uses Azure AD for authentication. Azure AD access tokens do not live forever.  By default Azure AD access tokens have a 1 hour lifetime, but can be anywhere from 10 minutes to 1 day.  By default, the application developer controls the lifetime of its access tokens. 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.

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

 

For token lifetime, there is also an administrative control called authentication session management, by which Azure AD Conditional Access (CA) is used to control the lifetime of identity and access tokens which meet the specific conditions in the CA policy configured. UW can configure a CA policy upon request, but Conditional Access can lead to significant unexpected impacts, so we have to exercise judicious vetting and practices to prevent undesirable outcomes. Also note that many of the CA conditions possible may not be viable.

For more info about Azure AD tokens, see https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token.

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.

Conditional Access can lead to significant unexpected impacts, so we have to exercise judicious vetting and practices to prevent undesirable outcomes. Also note that many of the CA conditions possible may not be viable.

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 by Microsoft.

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.

To block legacy authentication, anyone with a personal UW NetID can join (and unjoin) this group: https://groups.uw.edu/group/u_msinf_aad_ca_blocklegacyauthn. 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 not permit legacy authentication.

If you have another type of UW NetID you’d like to opt-in, you’ll need to request it via UW-IT. Send requests to help@uw.edu with a subject line of: “Microsoft Infrastructure: conditional access block legacy for X” where X is your unit name. Be prepared with a group of the users to block legacy authentication.

Last reviewed June 29, 2021