Information technology tools and resources at the UW
MI Architecture Guide
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
- FIM: a person directory synchronization component
- Group Sync Agent: a Groups Service sync agent
- Azure AD Sync: an Azure AD sync agent
- ADFS: a federated authentication token service
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.
Going Deeper into the Diagram
- Group data flow (Purple): In the diagram above, you can see the flow of group data from the Group Web Service along the purple arrows to MI. That data flow continues along the blue arrows through DirSync to Azure AD. Not all groups are provisioned to Azure AD, because AAD does not yet support member private groups.
- 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. Note that passwords also flow to the MIT Kerberos system which is behind WebLogin and Shibboleth, which MI also leverages for some authentication flows.
- 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.
- 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. When the flow hits ADFS, the flow goes one of two directions depending on whether the client is passive (browser) or native (fat client), with native clients using their AD logon token.
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.
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 FIM 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 application NetIDs for non-person entities that have a need to authenticate; service accounts, scheduled tasks, and the like should use an application 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.