Status: Active

Purpose

This page describes the AAD Change Management Process, the Azure AD CAB, including the goals, roles, and operational processes used to manage changes to our enterprise Azure AD tenant(uwnetid.onmicrosoft.com).

Goals

  1. Enable business use 
  2. Mitigate risks
    1. Provide excellent infrastructure via reliable service design
    2. Show due care for the impact of changes on services dependent on our enterprise Azure AD

These goals imply a variety of desired outcomes which we won't explicitly call out, e.g. communication with customers, roll-back plans, pursuing solutions that broadly meet business needs, etc.

Change Flow Diagram

The following picture shows the general flow of a comprehensive change request through the approval process via the various roles. It does not account for the flow if an approval is not approved at various gates.

Roles

The following parties are involved in this process. Listed by name, role, and responsibilities.

NameRoleResponsibility
CustomerRequestorSubmit a request for AAD change with sufficient information about business need. 
MI Support Coordinator 

Support the requestor through this process, at times suggesting or supplying technical detail and specifics the customer won't be able to supply. 

Guide requested change through the process to completion.

MI Engineering Solution Designer, Implementer 

As needed, design solutions which meet requests.

Implement approved changes.

MI Service Manager 

Approver (Gate #1)

Determine feasibility of requested change. Adjust change as needed. Determine what to do with change requests with significant issues. Set date of change.
AAD CAB membersConsultantsConsulted about requested change; provide input
AAD CAB managersApprover (Gate #2) Approve or deny change via review for business use and risks. Suggests recommended changes to the requested change.

 

The MI Support role is filled by the service team members.

The MI Engineering role is filled by the service team engineers.

The MI Service manager is filled by the service manager or their designated alternate during leave.

The AAD CAB members are the members of the AAD Governance team, which is defined separately at https://wiki.cac.washington.edu/x/9UtJB.

The AAD CAB managers are comprised of:

The AAD CAB has a leader role, which is filled by the MI Service Owner.

CAB members and managers can select a temporary alternate should they be unavailable.

Change Request Process

 Comprehensive Change Request vs. Routine Change Request

ComprehensiveRoutine

Comprehensive changes include the following:

  • Any request that meets the entry criteria and not previously called out explicitly as an routine change by the AAD CAB

Routine changes do not require the CAB to approve them. The approved routine changes include the following:

  • If a new setting or Microsoft app is deployed to our AAD tenant as enabled, upon discovery a tenant admin can immediately disable that setting/app treating it as a routine change. Communication of this change should happen among tenant admins, and to the MI service manager. Back out: Remove as routine. Goal: Mitigate Microsoft from implementing changes without our consideration. (approved 2/8/2016) 
  • Requests for Basic AAD Applications authored by UW developer. Back out: Remove as routine. Goal: Streamline AAD applications for UW developers, removing friction of waiting a month for low-risk use; value is provided in a timely manner. (approved 4/11/2016)
  • Requests to add additional permissions to the Azure AD risky permissions list can be approved by the Microsoft Infrastructure service manager. Customers who disagree with a denied request can escalate to the AAD CAB. (approved 10/10/2016)
  • AAD apps with a risky permission which has not been explicitly approved should be disabled by Microsoft Infrastructure service team members. This should happen within 72 hours of the app's creation, but can happen outside that period. (approved 10/10/2016)

Entry Criteria

The MI service has a request for a change to:

Process Steps

  1. Customer submits a change request to MI Support via UW Connect.
  2. MI Support reviews the customer's request for enough information that it can be acted on.
    1. Open CHG record, if needed. This may require having both a REQ and a CHG record, with the REQ to communicate with the customer.
    2. If necessary clarify with the customer to determine any unclear information. If needed, engage MI Engineering to design a solution to the customer's request.
    3. If needed, MI Engineering reviews request and designs a solution.
    4. MI Support has a documented request for change that must include:
      1. Specific details about what is to be changed
      2. What the back out plan is, should the change not go according to plan
      3. Some explanation of the desired outcome/goal behind the change–what's the business need this requested change meets?
      4. A desired timeframe for the change. NOTE: specific dates are not required at this time.
    5. MI Support assigns the request to the MI Service Manager for review for feasibility.
  3. Gate #1: MI Service Manager determines the feasibility of the the change request and considers the relative prioritization of the change, i.e. whether it needs speedier consideration or might be an emergency change. 
    1. If the change request is a routine change, then the MI Service Manager assigns the request to MI Engineering for implementation. Go to step #8.
    2. If not approved, the MI Service Manager will determine how best to handle/address. This may mean going back to 2a, 2b, or denying the request.
    3. If feasible, then
      1. MI Service Manager assigns a specific date for the change that reflects the relative prioritization compared to the overall service backlog and available resources and attempts to honor the customer requested desired timeframe
      2. MI Service Manager marks the change as feasible. 
      3. This results in a notification to Azure AD CAB members for comment and ultimately an approval decision by CAB managers. Unless otherwise noted, the approval will happen at the monthly CAB meeting. If speedier approval is needed, an ad hoc meeting will be scheduled.
  4. Gate #2: AAD CAB reviews change request.
    1. AAD CAB members discuss change, implications, and suggest recommended changes to the requested change. They supply these via UW Connect or by responding to the email notification.
      1. AAD CAB reviews request to ensure that business uses are enabled and risks are mitigated.
      2. Questions about potential issues are directed to the MI Service Manager for clarification/resolution.
      3. All discussion and concerns are expected to be voiced in advance of the monthly AAD CAB meeting.
    2. The monthly AAD CAB meeting provides a venue for the AAD CAB managers collectively review pending change requests and make a final decision to approve or reject those changes.
    3. When an AAD change is approved, an AAD CAB manager marks it as such within UW Connect. This signals the MI Service Manager to proceed.
    4. If not approved, the request has significant issues and needs further work. The request is assigned back to the MI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, or denying the change request.
  5. Change implementation
    1. MI Service Manager assigns approved change request to MI Engineering for implementation 
    2. For changes which are potentially customer impacting, MI Service Manager announces planned change via MI-announce mailing list, to the customer via the original REQ request, and where appropriate other mechanisms.
    3. MI Engineering implements change and updates CHG record listing results of change. Separately MI Engineering updates service design documentation
    4. If the change doesn't go well, MI Engineering executes the documented back-out plan. The UW Connect CHG record is then re-assigned to the MI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, 4a, 6a or denying the request.
  6. Change resolution
    1. MI Service Manager reviews CHG record results and closes it.
  7. Change request resolution 
    1. MI Support resolves original REQ request, if needed.

Change Practices