Entra ID provides multiple cloud-based capabilities using emerging technologies. Capabilities include authentication & credential management, collaboration and application management, device management, information security, and Entra ID is a cloud-enabling capability.
| On This Page |
General Entra ID Architecture
Microsoft has a lot of material published about Entra ID, 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 Entra ID is exactly, and how it all connects. We’ve created a general architectural diagram to help provide that context for Entra ID.
Brief description of what is in this diagram
- Entra ID 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 Entra ID from AD-DS through Entra ID Connect. It also flows along the black line to Office 365 applications (and from Exchange Online). It can alternatively flow to Entra ID via the PowerShell API or Graph APIs.
- Authentication flows to the Entra ID STS. Many organizations federate with ADFS, so this is included, but is not necessary. This results in a Work Account token which is passed to various applications leveraging Entra ID like Office 365.
- Legacy web apps can expose a higher security client endpoint in the cloud via Entra ID App Proxy. A Work Account token is obtained, and the Entra ID App Proxy connector fetches an AD-DS token. The legacy web app doesn’t need to understand Entra ID at all, and any client that can reach Entra ID 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 Entra ID tenant, providing identity services for your cloud-based Azure services.
NOTE: There are other Entra ID components such as Entra ID Directory Services (Entra ID DS), which are not pictured because of the additional complexity it would add to the diagram. Only components which provide significant potential value are included.
UW Entra ID Domains and Tenants
The Entra ID 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 Entra ID tenants exist and are also managed. The UW has guidance on when a new Entra ID Tenant should be created and when the existing enterprise Entra ID tenant should be leveraged. If in doubt, contact help@uw.edu for assistance.
UW Entra ID 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
Entra ID Identity Data
Entra ID Users
All NETID users are present in our Entra ID. There are some additional users in our Entra ID, 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 Entra ID 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 Entra ID . 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.
Entra ID Groups
Only NETID groups which are not member private are in our Entra ID . This is a significant gap in our current design, which unfortunately is tied to a gap in Microsoft’s Entra ID design. This means that course groups and significant institutional groups like uw_employee are missing in our Entra ID. 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 decade.
Entra ID Applications
Unlike Active Directory, Entra ID considers applications as significant as a user or group. You can leverage Entra ID for authentication and authorization for existing applications, applications you are developing, or 3rd party applications. A key difference to Entra ID applications is the possibility of application to application permissions, leveraging OAuth2.
OAuth permissions also imply more risk, so we employ some deliberation before approving Entra ID applications.
Entra ID Devices
Entra ID provides integration support for devices.
There is Entra ID device join for Windows 10, which allows you to log into Windows 10 using your Entra ID user account. The UW doesn’t recommend this configuration.
There is also Entra ID device registration. This allows a variety of devices to use an Entra ID user account to access services that require Entra ID. Behind the scenes, this capability provides a mechanism to revoke data access on that device if that device is lost or stolen.
Each Entra ID tenant can have only a single MDM provider. Ours is InTune, but there is no delegated use.
Entra ID Administrative Units and RBAC
Entra ID 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 Entra ID 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 |