This document includes common Microsoft terms associated with Entra ID (was Azure AD) and provides a basis for understanding what they mean. We welcome suggestions as to additional terms that should be added to this document.
- What is a tenant?
- What is an Entra ID directory?
- What is an Entra ID domain or accepted domain?
- What is the Entra ID Security Token Service (STS)?
- What is Entra ID B2B?
- What is Azure AD B2C?
- When signing in, why do I get a question about which account I want to use? What is a Microsoft account? What is a ‘Work or school account’? Which do I use?
- What is Entra ID External Users or Guests?
- What is Azure RMS?
- What is Azure MFA (AzMFA)?
- What is Entra ID Application Proxy?
- What is Entra ID Roles Based Access Control (RBAC)?
- What is Entra ID Administrative Units (AUs)?
- What is Entra ID Roles?
- What is Microsoft Graph API?
- What is Entra ID Workplace Join?
- What is Entra ID Device Join?
- What is the Entra ID Device Registration Service?
- What is Mobile Device Management (MDM)?
- What is Entra ID Cloud App Discovery?
- What is Microsoft Enterprise Data Protection (EDP)?
- What is Entra ID Privilege Identity Management (PIM)?
- What is Microsoft Passport?
- What is Entra ID Applications?
- What is the difference between an Entra ID Application and an Entra ID Service Principal?
- What is Entra ID Conditional Access?
- What is the difference between an Organizational Account and a Microsoft Account?
- What is password vaulting?
- What is ADAL, Katana, or OWIN?
A tenant is the organization that owns and manages a specific instance of Microsoft cloud services. It’s most often used in a inexact manner to refer to the set of Entra ID and Office 365 services for an organization, e.g. “we’ve configured our tenant in this way.” A given organization might have many tenants (the UW does), and when this is the case, the name of core domain of the tenant is usually used to remove any ambiguity. The name of the core domain comes in the form <tenantname>.onmicrosoft.com, where the <tenantname> varies. A tenant may have many subscriptions, exactly one directory, and one or more domains associated with it.
The primary Entra ID tenant used at the UW is uwnetid.onmicrosoft.com. It has a default domain of cloud.washington.edu. The primary domain used by this tenant is uw.edu. There are several other domains associated with this tenant like washington.edu and u.washington.edu. You may see references to the enterprise Entra ID tenant–that’s this tenant.
A directory is the Entra ID service for a given tenant. Each directory has one or more domains. A directory can have many subscriptions associated with it, but only one tenant. An Entra ID directory has a broad set of core capabilities. Some of those capabilities require additional per user licensing (implying an additional cost for you to use those capabilities).
A domain (or accepted domain) is a DNS zone for which a tenant has proven ownership (by creating an arbitrarily named DNS record as requested by Microsoft). It represents the possible domain suffixes (or namespace) which directory objects can use. Each tenant has a core domain (<tenantname>.onmicrosoft.com) and a default domain (which by default is the core domain, but which can be changed). Neither of these are necessarily the primary domain used by the tenant.
This is an Identity Provider which issues logon tokens for use with Entra ID applications. It supports WS-Federation, SAML, OpenID Connect, and OAuth 2.0. Strictly speaking, the OAuth 2.0 tokens are issued by the Entra ID OAuth Authorization Server, but this detail is not emphasized by Microsoft. The Entra ID STS supports federation from external Identity Providers. The federation scenarios supported are limited by the overall Entra ID architecture and individual application support.
Entra ID B2B refers to a general set of functionality that enables businesses to collaborate with each other. In specific, Entra ID allows users from other tenants and Microsoft Accounts to be guest users in your Entra ID tenant. These guest users are called External Users. Once an external user is present in your Entra ID tenant, you can permit them access to resources and leverage other Entra ID capabilities like Azure MFA (e.g. requiring them to provide a stronger authentication). Leveraging some of these other capabilities may require additional licensing, so there may be a cost associated.
Within the uw.edu Entra ID 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.
You can find out more about this capability here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2b-what-is-azure-ad-b2b/
Azure AD B2C refers to a specific offering from Microsoft that allows an organization to easily provide a commonly desired package of capability oriented at consumers. The package includes a web application you provide, a custom Entra ID directory with more flexible federation options, and an easily leveraged user registration process. This allows you to permit your organization access to the application, but also allow others to create their own user account. And you can leverage the other Entra ID capabilities for these user accounts.
This offering is appropriate for applications which include a user population that is not eligible for a UW NetID. In some cases, the other user population may have an existing identity and other UW solutions like UW Shibboleth will be more appropriate. There is an additional cost to this offering. Engage with UW-IT to explore what the best solution is.
When signing in, why do I get a question about which account I want to use? What is a Microsoft account? What is a ‘Work or school account’? Which do I use?
Most Microsoft applications and services require a sign in, as pictured below. To sign-in, you initially provide a username, such as firstname.lastname@example.org or email@example.com.
After you’ve entered the username, Microsoft checks to see what type of account it is, and whether there are multiple types of accounts with that username. If there are multiple types of accounts with that same username, then you see the next dialog as pictured below.
You can pick either. Depending on which you pick, the sign in experience will be different and what you have access to will also be different.
The ‘Work or school account’ option will almost always be the right one to pick for any UW resource or application. ‘Work or school account’ is synonymous with ‘Entra ID user account’, ‘Office 365 user’, and ‘Azure user’. In other words, that same account can be used with any application which leverages Entra ID as an identity source–including Office 365 and Azure services. This account is managed by the University of Washington, and is integrated with your UW NetID.
The ‘Personal account’ option will only be the right one to pick if you are accessing resources that only belong to you and which have no relationship to the UW. ‘Personal account’ is synonymous with ‘Microsoft account’, ‘Hotmail account’, ‘Xbox account’, and others. In other words, this is a consumer account which is used to access consumer services that Microsoft provides. This account is NOT managed by the University of Washington–only you manage it.
Some Microsoft services and applications do not support both types of accounts. In that case, you may have to pick the ‘personal account’ option despite it being something related to the UW.
Personal accounts (or Microsoft accounts) can be an Entra ID external user and be granted access to resources managed by the UW. This is not a good idea when the other person is at the UW, but it may be the only option for others.
For more information about Entra ID authentication and the expected Microsoft sign-in experience at the UW, please see: /tools-services-support/it-systems-infrastructure/msinf/aad/authn/. There are step-by-step pages describing the most common Microsoft sign-in experience for UW users.
Entra ID allows users from other Entra ID tenants and Microsoft Accounts to be guest users in your Entra ID tenant. These guest users are called External Users. Once an external user is present in your Entra ID tenant, you can permit them access to resources and leverage other Entra ID capabilities like Azure MFA (e.g. requiring them to provide a stronger authentication). An Entra ID external user is a special user object which says: go over there to find the account to use for authentication, but use this user account for all the access in this Entra ID tenant. If there was an external user in the UW Entra ID of firstname.lastname@example.org, the account for authentication is in the pottery.edu Entra ID tenant, and any authentication problems should be handled by the pottery.edu IT support. But folks at the UW would control what access that account had to resources in our tenant.
The external user object, by itself, poses no real risk to the university. Access controls which allow this external user access to specific resources might pose a risk. UW-IT generally doesn’t manage those resource access controls. UW-IT does not have the ability to determine whether all the scenarios for which a given external user needs access to UW resources have disappeared. In scenarios where the external user account should have tighter controls enforced for access to specific resources, UW-IT would be happy to explore solutions for that.
Within the uw.edu Entra ID enterprise tenant, we allow any user in the tenant to invite external users. There is no automated or manual removal of external users from the uw.edu Entra ID tenant. The person in control of an external user account can deprovision the account in other Entra ID tenants by themselves. See https://docs.microsoft.com/en-us/azure/active-directory/b2b/leave-the-organization.
In the future, as Microsoft develops the management capabilities for external users, there may be additional restrictions or limitations.
Azure Rights Management Services (RMS) provides a digital rights management solution for data. Conceptually, this solution allows you to put a “container” around a file which adds an additional layer of protection by encrypting what is within. To “open” the container, you must possess the right key. Azure RMS provides the key management via a cloud-based service, which means the data can live anywhere and be accessed from almost anywhere, if you possess the right key. Use of Azure RMS requires a client, and some applications support richer controls such as preventing the data from being copied to the clipboard or emailed. Azure RMS provides a broad set of client support. Azure RMS also provides a tracking mechanism and the ability to remotely kill access, regardless of where the data is at.
If you need a solution that provides at-rest encryption, Azure RMS may be what you are looking for. Azure RMS does require additional licensing, so there may be a cost associated with using it. Engage with UW-IT to explore whether this is a solution for your scenario.
Azure MultiFactor Authentication (MFA) provides an additional phone-based verification that you are who you say you are when logging in. Azure MFA provides the additional verification by leveraging information passed through a separate communication channel that has been previously configured for that purpose–a phone. The phone does not need to be a smart phone, but there is a much richer set of verification options if you do use a smart phone. Azure MFA can be required for all authentications for a given user, or via Entra ID Conditional Access it can only be required for access to specific Entra ID applications.
Azure MFA does require additional licensing, so there may be a cost associated with using it. Engage with UW-IT to explore whether this is a solution for your scenario.
Azure Application Proxy provides a cloud-based endpoint for on-premises web-based applications (and in some cases, non-web-based applications), and allows you to layer additional security protections. You “publish” an on-premises application, even an application behind a UW firewall. Clients access a different URL for the application which terminates in Microsoft’s cloud. Clients authenticate using Entra ID. The Azure Application Proxy then proxies client web traffic via an on-premises connector server which can access your web application.
You can also use Application Proxy to create solutions which span cloud and on-premises platforms as it does logon token transformation from an Entra ID logon token to an AD logon token.
Because Entra ID authentication is used, you can use Entra ID based authentication capabilities like Conditional Access and Azure MFA to add additional protections, without any change to your application–it continues to use Integrated Windows Authentication or whatever authentication it currently uses.
Entra ID Role Based Access Control (RBAC) provides a role based mechanism for authorizing access to resources. Identities are provisioned into roles. Resources are defined in Entra ID Administrative Units. A RBAC rule ties the two together specifying what permission scopes are allowed.
Entra ID Administrative Units (AUs) are an organizational concept that allow you to group resources together. Once the resources are grouped into an AU, you can use Entra ID RBAC to permit access across all of that set of resources. AUs are similar to an OU, but unlike OUs, any given resource can be in many AUs. This makes them much more flexible as an organizational concept for access control purposes.
The UW’s enterprise Entra ID currently has no AUs defined, nor a process for defining them. If you have a need for this capability, please engage with UW-IT to explore your scenario.
Entra ID Roles are a concept that allow you to group identities who need a certain set of permissions. Once the identities are grouped into a role, you can use RBAC to permit access across a set of resources. Every Entra ID application can define its own set of roles (including Entra ID applications you write) and Entra ID itself has some roles.
The Microsoft Graph API provides modern interfaces to discover data in any Microsoft cloud-based service–including Entra ID and Office 365 applications. This includes a RESTful web service interface and native client libraries for .NET, Android, and iOS. The Microsoft Graph API emerged in late 2015 and does not have full support for all Microsoft APIs, but the broad usefulness of interacting with a single API endpoint suggests that it will be a preferred mechanism for application developers.
Most of the directory data in the UW’s enterprise Entra ID and some data from Office 365 applications is accessible via this interface.
Entra ID Workplace Join allows you to use your Entra ID account on a device you own. You do not use your Entra ID as the primary login to your device, but your credentials are cached on the device permitting you to easily access resources for which your Entra ID account is permitted. Microsoft supports this capability for Windows 7, Windows 8.1, Windows 10, iOS, and Android devices. This capability leverages the Entra ID Device Registration Service to assign a unique identifier to your device and also associates a certificate with that device. The certificate can be used for various purposes including Microsoft Enterprise Data Protection and Microsoft Passport. Entra ID Workplace Join or Device Join is required to leverage Entra ID MDM capabilities.
The UW’s enterprise Entra ID allows Entra ID workplace join for Windows 10 devices. If you are interested in getting support for other platforms please engage with UW-IT to explore your scenario. Existing UW support for Entra ID Workplace Join is limited.
Entra ID Device Join (AADDJ) allows you to directly use your Entra ID account on a device you own. You can use your Entra ID as the primary login to your device. Microsoft supports this capability for Windows 10. This capability leverages the Entra ID Device Registration Service to assign a unique identifier to your device and also associates a certificate with that device. The certificate can be used for various purposes including Microsoft Enterprise Data Protection and Microsoft Passport. Entra ID Workplace Join or Device Join is required to leverage Entra ID MDM capabilities. The primary reason to do Entra ID device join is to gain device management capabilities, however, there are better device management mechanisms available.
The UW’s enterprise Entra ID does not broadly recommend Entra ID device join. If you are interested in getting support please engage with UW-IT to explore your scenario.
The Entra ID Device Registration Service (DRS) provides a mechanism that allows devices to create a device object in Entra ID and get an associated certificate for various purposes. This service plays a central role for Entra ID MDM capabilities.
Mobile Device Management (MDM) is a term for an industry defined device configuration management capability. There are open standard specifications for MDM and many providers with MDM services. Entra ID provides a mechanism for a single MDM service to be associated with a given tenant. Devices registering with Entra ID are then automatically enrolled in that MDM solution. Existing MDM features are not as rich as Active Directory group policy or System Center Configuration Manager, but may grow to surpass these traditional mechanisms.
The UW’s enterprise Entra ID currently has Intune as its MDM provider. If you are interested in getting support please engage with UW-IT to explore your scenario.
Entra ID Cloud App Discovery allows IT staff to detect which SaaS applications your users are accessing so you can provide better support, ensure proper security, and align your investments to what your users need. It can be deployed via a client agent or web proxy.
Cloud App Discovery does require additional licensing, so there may be a cost associated with using it. Engage with UW-IT to explore whether this is a solution for your scenario.
Microsoft Enterprise Data Protection (EDP) is a set of capabilities that allows organizational data to be protected when on devices not owned by the organization. That data is essentially encrypted and depending on the specific scenario that data can be remotely wiped or remotely have access removed without completely wiping the device or otherwise impacting the non-owned device. EDP requires the device to run Windows 10 and be managed either by SCCM or your Entra ID MDM, and also depends on unreleased products.
The UW does not currently support this capability. Engage with UW-IT to explore whether this is a solution for your scenario.
Entra ID Privilege Identity Management (PIM) is a set of capabilities that allows management of Entra ID roles. This capability permits ‘just in time’ on-demand management of who has a given Entra ID role, alerting for role changes, and provides reporting.
Microsoft Passport provides a two-factor authentication solution for Windows 10 devices. Users can authenticate with a Microsoft account, AD account, an Entra ID account, or a non-Microsoft service that support FIDO. After enrollment, the user sets up a “gesture”, which can be Windows Hello or a PIN. Enrollment causes a certificate to be provisioned as a credential for that user account, where the private key of the certificate is only stored on that device. Windows then uses Microsoft Passport to authenticate that user on that device and enable access to MFA protected resources and services. Microsoft Passport is a low-cost MFA solution, which combines something you have (the device) with either something you know or something you are. Microsoft Passport is not yet supported for use with AD accounts.
The UW does not yet provide Microsoft Passport. Engage with UW-IT to explore whether this is a solution for your scenario.
An Entra ID Application is code that has an identity and credential in Entra ID . That code can get a logon token, define permission scopes that allow other users or applications to access special data (or features), and require permissions to other Entra ID applications. Entra ID Apps can also require user consent when the application needs to access data in another Entra ID application on their behalf. You can also “publish” your Entra ID app so that users in other Entra ID tenants can use it.
More details about using Entra ID applications in the UW’s enterprise AD tenant is documented at: /tools-services-support/it-systems-infrastructure/msinf/aad/apps/.
Each Entra ID application lives (or is “owned by”) in a single tenant. If that Entra ID app is enabled for multi-tenancy, then other tenants can “add” and use it. Adding an Entra ID app that lives in another tenant results in a service principal in your Entra ID tenant. The service principal is a “shadow principal” which references the actual Entra ID application in the other tenant. Single tenant Entra ID applications have both an Entra ID application object AND a service principal object in that tenant. A multi-tenant application which lives in some other tenant will only have a service principal object in your tenant. So Entra ID service principals are an instantiation of an Entra ID application–they are tightly entwined.
The Entra ID STS provides a special additional layered capability called Entra ID Conditional Access. Entra ID Conditional Access allows an organization to define additional rules that a user must meet to get an Entra ID logon token for a given Entra ID application. In other words, with this capability you can add additional security protections for Entra ID applications. The kinds of protections include require Azure MFA, require a specific network location, require a compliant endpoint device, and others. You can additionally enforce or exclude these additional protections based on group membership. For example, this would allow you require Azure MFA for an application if a given user is in a high-risk group, but not require it for anyone else. Again, the capability is tied to an Entra ID application and provides a decision workflow on whether a given user can login to that application.
This capability requires additional user licensing so additional costs may apply. Engage with UW-IT to explore whether this is a solution for your scenario.
An organizational account (sometimes called a work account or a school account) is an Entra ID user account. It’s used for business purposes. An organizational account is owned by the organization which owns the Entra ID tenant.
A Microsoft account is what used to be known as a LiveID. It is used for consumer purposes. A Microsoft account is owned by the individual.
NOTE: like any identity system on the internet, the username of both of these types of accounts can be the same, but for security purposes the password should not be the same. When you are interacting with Microsoft services, after you provide a username, you may be asked whether you want to use your organization account or your Microsoft account. The answer should almost always be the organizational account.
For UW business, you should not use a Microsoft account. There are a few Microsoft business-oriented services which do not yet support an organizational account, but Microsoft has plans to address these few services. In those cases, at this time, a Microsoft account is the only option.
Entra ID supports “password vaulting”, which allows one to save the username and password for a 3rd party application and associate with your Entra ID user account. This capability in concert with custom application authentication integrations which Microsoft is happy to do for any app requested by a customer allows you to use Entra ID to achieve a SSO like experience regardless of the authentication the application uses. When used in concert with Entra ID Conditional Access, you can increase the default authentication security for 3rd party applications.
These are the key Microsoft identity libraries:
- Open Web Interface for .NET (OWIN) and Katana
- Active Directory Authentication Library (ADAL)
Katana is Microsoft’s implementation of OWIN. The specifications behind Microsoft’s identity libraries are open source and standards based, see OWIN, with from the perspective of a developer, really nice somewhat interchangeable support for modern standard protocols. The OAuth 2.0 standard leaves a lot of implementation details unspecified, so there are proprietary stuff that Microsoft provides, but that’s true for every OAuth 2.0 provider.
ADAL is used to get an authentication token, whereas, Katana is used to get an authorization token.
The Microsoft identity library lifecycle is best captured in the diagram here: http://www.cloudidentity.com/blog/2015/03/23/IDENTITY-LIBRARIES-STATUS-AS-OF-03232015/. WIF, the Windows Identity Framework, is 3 or 4 generations old, superseded by ADAL (client) + Katana (server). Those parentheticals are oversimplifications which correspond to their “role” in the authentication pipeline.
https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-libraries/ is a link for all the ADAL libraries along with several OWIN/Katana ones–as is https://github.com/AzureAD.