This document is for computing professionals interested in how the Microsoft Infrastructure is designed.
|On This Page||Related to This Page|
The Microsoft Infrastructure is built upon Active Directory (AD) and Azure Active Directory (AAD).
The NETID AD has its own page with specifics about it, including the directory structure, schema, user attributes, SPNs, and delegation.
Provisioning and Synchronization Integration
There are five integration components feeding the NETID AD and Azure AD. They are:
- Kiwi: an account and password provisioning component. The MI kiwi agent is sometimes called fuzzy_kiwi
- MIM: a person directory synchronization component
- Group Sync Agent: a Groups Service sync agent
- Azure AD Sync: an Azure AD sync agent
Together these components automatically provision accounts, groups, passwords, personal directory information, and help computing services to work with MI.
This set of components is responsible for all user creations, and almost all group creations. This set of connectors is also responsible for almost all modifications to users or groups. Direct creation or modification of users and groups is not allowed without very good reason, because these components assume responsibility and authority for these functions, and in some cases will overwrite direct changes made, possibly resulting in disastrous consequences.
NOTE: Arrows with solid lines represent push-based data transfer from one component to the destination. Arrows with dotted lines represent pull-based data transfer, with the recipient as the initiator.
Groups data flow (Purple)
In the diagram above, you can see the flow of group data from UW Groups along the purple arrows to NETID Active Directory. That data flow continues along the blue arrows through Azure AD Connect to Azure AD. From Azure AD, it continues to cloud-based directories specific to Exchange Online and Sharepoint Online via an undocumented sync system that Microsoft provides.
Not all groups are provisioned to Azure AD, because Azure AD does not yet support member private groups.
Latency from UW Groups to NETID AD typically has a very short latency. There is a recurring event once per quarter which can result in a larger expected latency for this hop, but generally the latency is very short.
Latency from NETID Active Directory to the UW Azure AD is typically longer, usually not more than 30 minutes, as documented here: /tools-services-support/it-systems-infrastructure/msinf/design/arch/aad-sync/. As noted at that page, there are occasional times where the latency is longer than 30m, and even extreme maintenance events where the latency might be 2 days. You’d see the Azure AD group change present via a tool like https://portal.azure.com/#blade/Microsoft_AAD_IAM/GroupsManagementMenuBlade/AllGroups or https://account.activedirectory.windowsazure.com/r#/groups (this last one is useful only if you are a member of the group).
Latency from the UW Azure AD to the cloud-based directory supporting Exchange Online or Sharepoint Online is not well documented by Microsoft, and there are no clear support guidelines for it. It occasionally has significant problems and might require a support case to be opened by UW to Microsoft.
Password data flow (Yellow)
You can see the flow of password data from the UW NetID system along the yellow arrows to MI. PDS data is pulled as part of the password/user provisioning, so the red path is not the only vector for identity data. Password hashes are synchronized from NETID Active Directory to UW Azure AD along the blue line.
Identity data flow (Red)
You can see the flow of identity directory data along the red arrows to MI. This is data like preferred name, department, phone–data you might think of as your user profile.
Latency of this overall data flow is slower than any of the other data flows pictured.
Dotted red line represents the fact that the MI Kiwi agent reaches out to PDS for updated identity data when making changes to NETID AD user accounts.
Microsoft Cloud Service and License Provisioning (Green)
The flow of Azure AD based licenses like Office 365 services is represented by the green lines. Subscription 250 adds users to groups that bestow licenses they are eligible for. This in turn provisions access to Microsoft cloud services. In the case of Exchange Online, a special flow ensures that a mailbox and Exchange Online account is provisioned immediately before the flows represented by the blue line have fired.
Microsoft Cloud (Blue)
You can see the flow of directory data (users, groups, and contacts) from the NETID Active Directory to our Azure Active Directory (AAD) along the dark blue arrows. This data is then synchronized by Microsoft to various Office 365 applications like Exchange Online and Sharepoint Online. Other Azure AD applications also leverage this data.
Azure AD Authentication (White)
You can see the path Azure AD based authentication flows along the white arrows. This flow is extremely simple–Azure AD applications such as Exchange Online send a user to the Azure AD security token service, i.e. a Microsoft sign-in page.
For more detailed information about these key architectural components, please follow the links to each component above. You may also want to investigate documents nested within the links above, notably:
- The full details on how MIM maps data from PDS to MI are here.
- The full details of how the Group Sync Agent maps Group Service data to MI are here.
- The details of the Azure Active Directory DirSync connector are here (undocumented at this time).
Additional Directory Access
Additional directory access can be requested. Please use the MI Elevated Directory Access Request Form to initiate the process of getting additional access. This form will generate an email that will be used to track your request and obtain any related approvals.
In some cases, if you request access to student data, we may also ask that you also submit a UW Directories – Student Data Access Request form (http://studentdata.washington.edu/system-access-forms/ is the parent for this form).
There are some directory objects which Windows administrators can not create regardless of the permissions they have been delegated. These include: users, contacts, and groups. This is because these objects have the potential to cause a namespace collision with institutionally provisioned objects.
All user accounts are created via the UW NetID account system. Where appropriate, you should use a Shared NetIDs for non-person entities that have a need to authenticate; service accounts, scheduled tasks, and the like should use an shared NetID.
All groups are created via the Groups Web Service which is an interface to the Groups Service which are then subsequently synchronized to NETID domain (and subsequentl Azure AD). If, for some reason, the namespace enforced by GS isn’t compatible with your needs, e.g. a vendor product that is hard-coded for a specific group name, then feel free to escalate this issue.
Users do not reset their NETID account passwords directly; instead passwords are changed with the UW NetID system using the Manage Your UW NetID site.