Skip to end of metadata
Go to start of metadata

Objective

In order to provide functionality for UW Medicine, MSCA needs an Exchange Enabled security group.

This group is critical to implement:

  • Exchange Admin role delegations via RBAC roles to increase the agility and time to resolution for ITS
  • Exchange Admin role delegations via RBAC roles to support UW Medicine compliance needs
  • Automatic routing of user reported phishing from Microsoft built in tooling to UW Med CISO
  • Other specialized routing rules as needed
  • User forwarding controls to comply with UW Medicine forwarding policies.
  • SPAM and Phishing policies appropriate for UW Medicine

It can potentially be used for scoping in Cloud App Security.

Requirements

The membership should include:

  • All UW Medicine Workforce members
  • All Clinical Shared NetIDs available in Azure AD

The Exchange settings should be:

  • TBD – No one, Anyone, Members of a specified group, list of groups or netids

Known constraints

The solution architecture includes the following constraints:

  • Solutions that rely on Azure Connect have a 50K limit on group memberships synchronized from AD to AAD (see note)
  • Disclosing group membership data to new audiences requires authorization from data owners

Note: we have asked Microsoft to increase their limit, and where is this ask is being tracked; let's shift this to the related AAD govteam discussion.

Design proposals

Group memberships

MSCA may have forgotten about some of the groups is this area, which they referenced in REQ1385495 to obtain access to the groups service.

These same groups are also described on this page:

https://wiki.cac.washington.edu/display/infra/UW+Affiliation+Groups

If you click through to the groups themselves, none are larger than 50K.

To move forward:

1. We need someone to help you confirm a mapping between the subscription codes you listed in this request and these existing groups:

13: UW Medicine Workforce = uw_affiliation_uw-medicine-workforce
76: UWP Provider = uw_affiliation_uwp-provider
77: UWP Admin Staff = uw_affiliation_uwp-staff
80: UWPN Admin Staff = uw_affiliation_uwnc-staff (TBD? maybe?)
104: NWHMC Admin Staff = uw_affiliation_nwh-staff
105: NWHMC Provider = uw_affiliation_nwh-provider

Note: There is an "Audience RX" product that UWM Marketing was using that introduces a different business and technical definition of UWM workforce that includes UWP, UWPN, NWH, Valley, Workday (by box number), but not "Workforce" people as provided to IAM from UWM's Puma database integration.

Note: UW Medicine affiliation group transitions 2019-2020

2. There is no reference group for "22: UW Medicine Shared", so we can draft a design proposal here:

Clinical shared UW NetID group design

Note: Above MSCA team refers to "Clinical Shared NetIDs available in Azure AD" which may or may not be the same as "22: UW Medicine Shared".

Provisioning to AAD

Given the requirements and constraints, what proposed designs do we have for provisioning to AAD?

It might be simplest to model the overall membership as a policy group in the groups service (e.g. u_msca_uwm-exchange-access), and have it include whatever reference groups it should include over time, and then either:

(a) if less than 50K members, exchange enable the groups and sync them over to AAD through the current design through AD, or

(b) sync the one group and its effective membership directly to AAD via the graph API or other direct methods.

Data custodian approvals

Based on the proposed design decisions above...

3. We need to get authorization to integrate the group membership data into the new target systems (AD, AAD, Exchange) and therefore disclose data to new data viewers. This is the item that I'm responsible for coordinating, and I'll request a discussion about this at the next Azure AD govteam meeting. In particular, we need to document the AD, AAD, Exchange access policies with respect to data disclosure. We have a good set of subject matter experts who understand the technical controls applied to data in these systems, and we can translate that into an access policy in natural language that data custodians can understand.



  • No labels