Azure AD provides multiple cloud-based capabilities using emerging technologies. Capabilities include authentication & credential management, collaboration and application management, device management, information security, and Azure AD is a cloud-enabling capability.
| On This Page |
General Azure AD Architecture
Microsoft has a lot of material published about Azure AD, but almost none of it is architectural in nature, and what is architectural is focused on a specific component. For this reason, it is difficult to conceptualize the big picture of what Azure AD is exactly, and how it all connects. We’ve created a general architectural diagram to help provide that context for Azure AD.
Brief description of what is in this diagram
- Azure AD has a lot of components, interfaces, and data stores–far more than its on-premises counterpart AD-DS. This diagram shows most but not all of these parts.
- Identity data flows along the blue line to AAD from AD-DS through AAD Connect. It also flows along the black line to Office 365 applications (and from Exchange Online). It can alternatively flow to AAD via the PowerShell API or Graph APIs.
- Authentication flows to the Azure AD STS along the red line through ADFS. ADFS leverages AD-DS as an authenticator. This results in a Work Account token which is passed to various applications leveraging AAD like Office 365.
- Legacy web apps can expose a higher security client endpoint in the cloud via AAD App Proxy. A Work Account token is obtained, and the AAD App Proxy connector fetches an AD-DS token. The legacy web app doesn’t need to understand AAD at all, and any client that can reach AAD can access the web app.
- Modern web apps leverage the Graph APIs to get identity data, and the OAuth token service to get access to other modern web apps.
- File servers can leverage Azure MFA via an on-premises MFA server. They can also leverage Azure RMS via an on-premises RMS connector. Cloud services enhance the security of on-premises services.
- Your Azure subscription(s) are homed in your AAD tenant, providing identity services for your cloud-based Azure services.
NOTE: There are other AAD components such as AAD Directory Services (AAD DS), which I haven’t pictured because of the additional complexity it would add to the diagram. I’ve tried to only leave out components I feel are ancillary in value.
UW Azure AD Domains and Tenants
The Azure AD tenant used at the UW is uwnetid.onmicrosoft.com. It has a primary domain of cloud.washington.edu, but the domain used most commonly in this tenant is uw.edu, with many UW NetIDs automatically provisioned for use. The list of all domains associated with this tenant is:
- cloud.uw.edu
- cloud.washington.edu (primary domain)
- deviceusers.washington.edu
- exchange.washington.edu
- netid.washington.edu
- o365.uw.edu
- o365.washington.edu
- resource.washington.edu
- u.washington.edu
- uw-sbc-nv.nuwaveteams.com
- uw-sbc-va.nuwaveteams.com
- uw.edu (99% of all use happens here)
- uwnetid.onmicrosoft.com (default domain)
- washington.edu
Of those domains, all that include “uw.edu” are federated, while the others are not.
Other UW Azure AD tenants exist and are also managed. The UW has guidance on when a new Azure AD Tenant should be created and when the existing enterprise Azure AD tenant should be leveraged. If in doubt, contact help@uw.edu for assistance.
UW Azure AD Technical Diagram
Here is a UW-specific technical architecture diagram like the one above.
Some specific notes about items which differ from the generic diagram:
- The NETID AD gets identity data from the UW NetID service, the Identity Registry, and the Groups Service.
- We do not use ADFS, but rather leverage password hash sync.
- Items missing aren’t in use or planned
Azure AD Identity Data
AAD Users
All NETID users are present in our Azure AD. There are some additional users in our AAD, corresponding to the domains listed above which are not federated. These other users are generally either administrative in nature or to facilitate Office 365 features.
Do note that Azure AD name values have a longer change latency period, with a change in a source system taking a couple hours to reach the NETID AD and then an hour to reach our Azure AD. If the name value is then in an Office 365 application, there may be an additional latency due to the undocumented “sync glue” Microsoft employs. Also note that a common known problem is cached identity data in your Office 365 fat client, which may make it appear that a name change hasn’t occurred, when in reality it has. The MSCA service can be consulted about that known problem.
AAD Groups
Only NETID groups which are not member private are in our Azure AD. This is a significant gap in our current design, which unfortunately is tied to a gap in Microsoft’s Azure AD design. This means that course groups and significant institutional groups like uw_employee are missing in our Azure AD. That in turn means a lot of value can’t be realized.
Addressing this issue has been and continues to be our #1 request to the Microsoft Identity division in continuing discussions with them over the last several years.
Azure AD Applications
Unlike Active Directory, Azure AD considers applications as significant as a user or group. You can leverage Azure AD for authentication and authorization for existing applications, applications you are developing, or 3rd party applications. A key difference to Azure AD applications is the possibility of application to application permissions, leveraging OAuth2.
OAuth permissions also imply more risk, so we employ some deliberation before approving AAD applications. For this reason, our tenant settings differ from the defaults with respect to AAD applications, requiring all AAD applications to be added by a tenant administrator. A consequence of having all AAD applications be added by a tenant administrator is that user consent is suppressed, or put another way, Microsoft considers the tenant administrator to be consenting on behalf of all users in our tenant.
Azure AD Devices
Azure AD provides integration support for devices.
There is Azure AD device join for Windows 10, which allows you to log into Windows 10 using your Azure AD user account. The UW supports this.
There is also Azure AD device registration. This allows a variety of devices to use an Azure AD user account to access services that require AAD. Behind the scenes, this capability provides a mechanism to revoke data access on that device if that device is lost or stolen.
Each AAD tenant can have only a single MDM provider. Ours is InTune, but there is no delegated use.
Azure AD Administrative Units and RBAC
AAD Administrative Units (AUs) are like AD-DS Organizational Units (OUs), except more flexible and not tied to the LDAP directory concept of being a parent/container. AUs are used as a grouping mechanism to define a set of objects on which you associate roles which have a defined set of access controls. This type of approach is commonly referred to as Role Based Access Controls (RBAC).
Because we currently have no AUs we also have no custom RBAC permissions defined. There are many built-in roles, but we’ll consider them outside the scope of this document. There are no custom roles defined at this time.
Tenant Settings
Each Azure AD tenant has settings which apply to the entire tenant. Here are those settings and the values of each:
| Setting | Value |
| DirectorySynchronizationEnabled | True |
| PasswordSynchronizationEnabled | False |
| SelfServePasswordResetEnabled | True |
| UsersPermissionToCreateGroupsEnabled | False |
| UsersPermissionToReadOtherUsersEnabled | True |
| UsersPermissionToCreateLOBAppsEnabled | False |
| UsersPermissionToUserConsentToAppEnabled | False |