This document includes common Microsoft terms associated with Azure Active Directory (or 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 Azure AD directory?
- What is an Azure AD domain or accepted domain?
- What is the Azure AD Security Token Service (STS)?
- What is Azure AD 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 Azure AD External Users or Guests?
- What is Azure RMS?
- What is Azure MFA (AzMFA)?
- What is Azure AD Application Proxy (AAD-AP)?
- What is Azure AD Roles Based Access Control (AAD RBAC)?
- What is Azure AD Administrative Units (AAD AUs)?
- What is Azure AD Roles?
- What is Azure AD Graph API?
- What is Microsoft Graph API?
- What is Azure AD Workplace Join?
- What is Azure AD Device Join?
- What is the Azure AD Device Registration Service?
- What is Mobile Device Management (MDM)?
- What is Azure AD Cloud App Discovery?
- What is Microsoft Enterprise Data Protection (EDP)?
- What is Azure AD Privilege Identity Management (PIM)?
- What is Microsoft Passport?
- What is Azure AD Applications?
- What is the difference between an Azure AD Application and an Azure AD Service Principal?
- What is Azure AD 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 Azure AD 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 Azure AD 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 Azure AD tenant–that’s this tenant.
A directory is the Azure AD 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 Azure AD 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 Azure AD applications. It supports WS-Federation, SAML, OpenID Connect, and OAuth 2.0. Strictly speaking, the OAuth 2.0 tokens are issued by the Azure AD OAuth Authorization Server, but this detail is not emphasized by Microsoft. The Azure AD STS supports federation from external Identity Providers. The federation scenarios supported are limited by the overall Azure AD architecture and individual application support.
The UW federates with its uw.edu Azure AD enterprise tenant via ADFS, which in turn is chained to the UW Shibboleth IdP, which uses the UW Weblogin (and UW MIT Kerberos realm) for authentication.
Azure AD B2B refers to a general set of functionality that enables businesses to collaborate with each other. In specific, Azure AD allows users from other Azure AD tenants and 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, you can permit them access to resources and leverage other Azure AD 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 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.
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 Azure AD 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 Azure AD 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 email@example.com or firstname.lastname@example.org.
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 ‘Azure AD user account’, ‘Office 365 user’, and ‘Azure user’. In other words, that same account can be used with any application which leverages Azure AD 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 Azure AD 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 Azure AD 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.
Azure AD allows users from other Azure AD tenants and 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, you can permit them access to resources and leverage other Azure AD capabilities like Azure MFA (e.g. requiring them to provide a stronger authentication). An Azure AD 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 Azure AD tenant. If there was an external user in the UW Azure AD of email@example.com, the account for authentication is in the pottery.edu Azure AD 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 Azure AD 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 Azure AD tenant. The person in control of an external user account can deprovision the account in other Azure AD 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 Azure AD Conditional Access it can only be required for access to specific Azure AD 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 (AAD-AP) 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 Azure AD. The AAD-AP then proxies client web traffic via an on-premises connector server which can access your web application.
You can also use AAD-AP to create solutions which span cloud and on-premises platforms as it does logon token transformation from an Azure AD logon token to an AD logon token.
Because Azure AD authentication is used, you can use Azure AD 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.
Azure AD Role Based Access Control (AAD RBAC) provides a role based mechanism for authorizing access to resources. Identities are provisioned into roles. Resources are defined in Azure AD Administrative Units. An AAD RBAC rule ties the two together specifying what permission scopes are allowed.
Azure AD 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 AAD 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 AAD 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.
Azure AD Roles are a concept that allow you to group identities who need a certain set of permissions. Once the identies are grouped into a role, you can use AAD RBAC to permit access across a set of resources. Every Azure AD application can define its own set of roles (including AAD applications you write) and Azure AD itself has some roles.
Azure AD Graph API provides modern interfaces to discover directory data in Azure AD, including a RESTful web service interface and native client libraries for .NET, Android, and iOS.
All directory data in the UW’s enterprise Azure AD is accessible via this interface, and it is an architecturally sound method for getting that data.
The Microsoft Graph API provides modern interfaces to discover data in any Microsoft cloud-based service–including Azure AD and Office 365 applications. Like the Azure AD Graph API it 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 Azure AD and some data from Office 365 applications is accessible via this interface.
Azure AD Workplace Join allows you to use your Azure AD account on a device you own. You do not use your Azure AD as the primary login to your device, but your credentials are cached on the device permitting you to easily access resources for which your Azure AD account is permitted. Microsoft supports this capability for Windows 7, Windows 8.1, Windows 10, iOS, and Android devices. This capability leverages the Azure AD 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. Azure AD Workplace Join or Device Join is required to leverage Azure AD MDM capabilities.
The UW’s enterprise Azure AD allows AAD 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 AAD Workplace Join is limited.
NOTE: There is public Microsoft documentation about an automatic AAD workplace join mechanism tied to AD domain join. Details about this emerging capability are sparse, so this is likely an area where what’s written here will become out of date.
Azure AD Device Join (AADDJ) allows you to directly use your Azure AD account on a device you own. You can use your Azure AD as the primary login to your device. Microsoft supports this capability for Windows 10. This capability leverages the Azure AD 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. Azure AD Workplace Join or Device Join is required to leverage Azure AD MDM capabilities. The primary reason to do Azure AD device join is to gain device management capabilities, however, there are better device management mechanisms available.
The UW’s enterprise Azure AD does not broadly allow AAD device join. If you are interested in getting support please engage with UW-IT to explore your scenario.
The Azure AD Device Registration Service (AAD DRS) provides a mechanism that allows devices to create a device object in Azure AD and get an associated certificate for various purposes. This service plays a central role for Azure AD 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. Azure AD provides a mechanism for a single MDM service to be associated with a given tenant. Devices registering with Azure AD 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 AAD currently has Office 365 for MDM as its MDM provider but it is not configured or used, and there are plans to replace it with Microsoft InTune. If you are interested in getting support please engage with UW-IT to explore your scenario.
Azure AD 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 Azure AD 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.
Azure AD Privilege Identity Management (PIM) is a set of capabilities that allows management of Azure AD roles. This capability permits ‘just in time’ on-demand management of who has a given AAD role, alerting for role changes, and provides reporting.
The UW’s AAD tenant does not currently provide PIM. Engage with UW-IT to explore whether this is a solution for your scenario.
Microsoft Passport provides a two-factor authentication solution for Windows 10 devices. Users can authenticate with a Microsoft account, AD account, an AAD 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 Azure AD Application is code that has an identity and credential in Azure AD. 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 Azure AD applications. AAD Apps can also require user consent when the application needs to access data in another AAD application on their behalf. You can also “publish” your AAD app so that users in other AAD tenants can use it.
More details about using Azure AD applications in the UW’s enterprise AD tenant is documented at: /tools-services-support/it-systems-infrastructure/msinf/aad/apps/.
Each AAD application lives (or is “owned by”) in a single tenant. If that AAD app is enabled for multi-tenancy, then other tenants can “add” and use it. Adding an AAD app that lives in another tenant results in a service principal in your AAD tenant. The service principal is a “shadow principal” which references the actual AAD application in the other tenant. Single tenant AAD applications have both an AAD 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 AAD service principals are an instantiation of an AAD application–they are tightly entwined.
In the UW’s enterprise AAD tenant, only a tenant admin can create an AAD service principal. This is not the default setting–the default allows any AAD user to add an AAD application from another tenant.
The Azure AD STS provides a special additional layered capability called Azure AD Conditional Access. AAD Conditional Access allows an organization to define additional rules that a user must meet to get an AAD logon token for a given Azure AD application. In other words, with this capability you can add additional security protections for Azure AD 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 Azure AD 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 Azure AD user account. It’s used for business purposes. An organizational account is owned by the organization which owns the AAD 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.
Azure AD supports “password vaulting”, which allows one to save the username and password for a 3rd party application and associate with your AAD 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 Azure AD to achieve a SSO like experience regardless of the authentication the application uses. When used in concert with Azure AD 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.