Child pages
  • Azure AD Change Management Process
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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),
Approver (Gate #3)

Determine feasibility of requested change. Adjust change as needed. Determine what to do with change requests with significant issues. Set date of change.
Azure AD CAB members (was Governance team) Approver (Gate #2) Consulted about requested change; provide input
AAD CAB managersApprover (Gate #4) 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 Governance team is defined separately at https://wiki.cac.washington.edu/x/9UtJB.

The AAD Governance team has a leader role, which is also defined separately.

The AAD CAB managers are comprised of:

  • MI Service Owner, which currently is Brad Greer
  • MSCA Service Owner, which currently is Tom Lewis

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

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

Change Request Process

 Standard Change Request vs. Routine Change Request

StandardRoutine

Standard changes include the following:

  • Any request not previously called out explicitly as an expedited change by the AAD CAB

Routine changes do not require the CAB to approve them. The accepted 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 UWWI service manager. Back out: Remove as routine. Goal: Mitigate Microsoft from implementing changes without our consideration. (approved 2/8/2016) 

Entry Criteria

The UWWI service has a request for a change to:

  • the enterprise Azure AD tenant design, including the following items
    • namespace design or accepted domains,
    • tenant-wide configuration settings,
    • enable or disable a new Azure AD capability that Microsoft has released (depends on what the default state of the new capability is)
    • change to provisioning or authentication integration design 
  • Azure services which can only be enabled or changed by a tenant global admin (e.g. Azure RMS, InTune, and many more)
  • a one-time change or recurring change--outside existing service design--to some number of objects in our AAD
  • implement significant management or operational practices (e.g. AAD app approval process or tenant global admin practices)
  • a change to MSCA service design which may have impact to the Azure AD design (note: MSCA may have a separate change approval process, but when a change intersects with AAD design should also use this mechanism)

Process Steps

  1. Customer submits a change request to UWWI Support via UW Connect.
  2. UWWI Support reviews the customer's request for enough information that it can be acted on.
    1. If necessary clarify with the customer to determine any unclear information. If needed, engage UWWI Engineering to design a solution to the customer's request.
    2. If needed, UWWI Engineering reviews request and designs a solution.
    3. UWWI Support has a documented request for change in the form of a wiki page which can be referenced and updated as needed. A link to this request is added to the UW Connect request. The documented request 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.
    4. UWWI Support assigns the request to the UWWI Service Manager for review.
  3. Gate #1: UWWI Service Manager makes a determination on whether to proceed and the relative prioritization of the change request.
    1. If the change request is an expedited change and approved, then the UWWI Service Manager assigns the request to UWWI Engineering for implementation. Go to step #8.
    2. If approved, then the UWWI Service Manager sends the change request to the Azure AD Governance team for discussion and their recommendation. The timing of submission to the AAD governance team will reflect the relative prioritization of the UWWI Service Manager.
    3. If not approved, the UWWI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, or denying the request.
    4. The UWWI Service Manager assigns the request to the AAD governance team leader.
  4. Gate #2: AAD Governance team reviews change request.
    1. AAD governance team discusses change, implications, and suggests recommended changes to the requested change. They supply these via the wiki page. The AAD governance team votes on whether to proceed with the change (based on their recommended changes) and supply the outcome on the wiki page.
    2. If approved, the AAD governance team leader will assign the request back to the UWWI Service Manager to proceed.
    3. If not approved, the request has significant issues and needs further work. The request is assigned back to the UWWI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, or denying the request.
  5. Gate #3: UWWI Service Manager reviews the approved change request with possible modifications by the AAD governance team and makes a determination on whether to proceed and the relative prioritization of the change request.
    1. UWWI 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. If approved, then the UWWI Service Manager sends the change request to the Azure AD Change Advisory Board for discussion and their recommendation. The UWWI Service Manager assigns the request to the AAD CAB leader.
    3. If not approved, the UWWI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, 4a, or denying the request.
  6. Gate #4: Azure AD Change Advisory Board reviews the change request
    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 UWWI Service Manager for clarification/resolution.
    3. AAD CAB discusses change, implications, and suggests recommended changes to the requested change. They supply these via the wiki page. The AAD CAB votes on whether to proceed with the change (based on their recommended changes) and supply the outcome on the wiki page.
    4. If approved, the AAD CAB leader will assign the request back to the UWWI Service Manager to proceed.
    5. If not approved, the request has significant issues and needs further work. The request is assigned back to the UWWI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, 4a, or denying the request.
  7. UWWI Service Manager assigns approved change request to UWWI Engineering for implementation 
    1. For changes which are potentially customer impacting, UWWI Service Manager announces planned change via Uwwi-announce mailing list, to the customer via the request, and where appropriate other mechanisms.
  8. UWWI Engineering implements change and updates change log and service design documentation
    1. If the change doesn't go well, UWWI Engineering executes the documented back-out plan. The UW Connect request is then re-assigned to the UWWI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, 4a, 6a or denying the request.
  9. UWWI Service Manager resolves customer request. 

Change Practices

  • The AAD CAB will meet monthly as part of the AAD governance team meeting. If there is no change to approve, they need not attend.
  • AAD CAB members attend the AAD governance meeting not as voting members of the AAD governance team, but can provide input and direction
  • AAD Changes should be submitted 1 week in advance of the AAD governance meeting so AAD CAB members have time to review and ask questions ahead of time.

 

 

  • No labels