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).
- Enable business use
- Mitigate risks
- Provide excellent infrastructure via reliable service design
- 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.
The following parties are involved in this process. Listed by name, role, and responsibilities.
|Customer||Requestor||Submit 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 members||Consultants||Consulted about requested change; provide input|
|AAD CAB managers||Approver (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:
- MI Service Owner, which currently is Nathan Dors
- MSCA Service Owner, which currently is Scott Norton
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
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)
The MI 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 that change should also use this mechanism)
- Customer submits a change request to MI Support via UW Connect.
- MI Support reviews the customer's request for enough information that it can be acted on.
- Open CHG record, if needed. This may require having both a REQ and a CHG record, with the REQ to communicate with the customer.
- 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.
- If needed, MI Engineering reviews request and designs a solution.
- MI Support has a documented request for change that must include:
- Specific details about what is to be changed
- What the back out plan is, should the change not go according to plan
- Some explanation of the desired outcome/goal behind the change–what's the business need this requested change meets?
- A desired timeframe for the change. NOTE: specific dates are not required at this time.
- MI Support assigns the request to the MI Service Manager for review for feasibility.
- 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.
- 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.
- 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.
- If feasible, then
- 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
- MI Service Manager marks the change as feasible.
- 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.
- Gate #2: AAD CAB reviews change request.
- 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.
- AAD CAB reviews request to ensure that business uses are enabled and risks are mitigated.
- Questions about potential issues are directed to the MI Service Manager for clarification/resolution.
- All discussion and concerns are expected to be voiced in advance of the monthly AAD CAB meeting.
- 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.
- 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.
- 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.
- Change implementation
- MI Service Manager assigns approved change request to MI Engineering for implementation
- 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.
- MI Engineering implements change and updates CHG record listing results of change. Separately MI Engineering updates service design documentation
- 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.
- Change resolution
- MI Service Manager reviews CHG record results and closes it.
- Change request resolution
- MI Support resolves original REQ request, if needed.
- 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 at least 1 week in advance of the AAD governance meeting so AAD CAB members have time to review and ask questions ahead of time.
- AAD routine changes are documented. New types of routine changes are approved as an AAD change.