Child pages
  • Azure AD Background Material
Skip to end of metadata
Go to start of metadata



This page is a placeholder for links, descriptions, and other material that will enable others to understand what Azure AD is, does, and its capabilities. It's been organized by a variety of different kinds of capabilities.


Every application which uses Azure AD authentication has an identity in Azure AD. Application objects are a template defining the characteristics of the operational instances of each AAD application. The operational instance is a serviceprincipal object, and it includes a list of permissions granted/consented for other AAD applications. Most applications have no interaction with other applications, so no need for consent/permissions. Any AAD applications which uses or provides permissions is using OAuth. Many 3rd party SaaS applications have an easy to deploy published application listed in the Azure AD App Gallery. Customers can also define AAD applications in concert with Azure AD Application Proxy to extend on-premises applications and layer additional security features. If used, customers get an Azure AD logon token (after meeting any requirements to get that token), then the proxy facilitates connection to the on-premises application (getting whatever additional token is required).

UW developers can self-service create their own application and serviceprincipal objects, and if they have an API can define their own permission scopes that other AAD applications can use.

Users can see AAD applications in several interfaces. The Azure AD Access Panel ( is a user-specific portal that lists all AAD apps which have been assigned to given user. The Access Panel includes a couple other user-specific features like groups and the ability to revoke the user's primary refresh token on that device. The Office 365 application panel (sometimes called the waffle) also shows some AAD apps. Finally, 3rd party websites often provide an interface to their application which is AAD integrated.

Links to learn more:



Data Source (directory)


Access Control

  • Azure Authorization Service: Note this service is under-documented. 
    • Azure AD Roles. There are 5 "out of the box" roles, emerging roles, and custom roles. (emerging roles: sharepoint admin, exchange admin, lync admin, compliance admin, azure sql admin, azure web admin)
    • Administrative Units (AUs): Define a set of "resources" which can have a role and privilege assigned to them. Status: Public preview
    • Role Based Access Control. Leverages roles and AUs to provide fine-grain access control by defining JSON policy and assigning roles + permissions + AUs. Status: Public preview
  • Conditional Access: Provide complex conditions that control authentication or access to a given resource. Status: limited capabilities today.
  • Groups
    • Self-service Groups: Via web portal, allow customers to create and manage groups.
    • Dynamic Groups: Via web portal, allow customers to define groups with dynamic memberships based on data sources. Status: Public preview
    • Dedicated Groups: All users group and futures. Status: Public preview
  • Group based license assignment. Status: Private preview
  • Privilege Identity Management (Just in Time Admin): ability to provision AAD roles on demand and audit actions taken during elevation. Status: Public Preview.
  • Azure AD Access Panel (listed separately): control access to apps, provision 3rd party SaaS app accounts (those which don't do federated authN), custom attribute mapping (claims) for SaaS app users.
  • Azure RMS (which is considered part of the AD family): provide DRM/encryption for data. In most cases provides an encrypted container around file so it doesn't matter where data lives.


Credential Management


Infrastructure Integration

  • Azure AD DirSync or Azure AD Connect: Synchronize users, groups, contacts with on-premises data sources. Today mostly one direction to cloud. Future will include bi-directionality.


Device Management



  • No labels