[MUSIC]
Charity Shelbourne: Hello, and welcome back to the Azure
Active Directory Architecture Deep Dive Series. My name is
Charity Shelbourne and I’m a Program Manager on the Azure
AD Engineering team at Microsoft.
Tosin Lufadeju: My name is Tosin Lufadeju and I’m a Program
Manager on the same team as Charity.
In our last video, I walked through the process of using
privileged identity management or PIM to activate an Azure
AD role so that I could perform administrative tasks for
Exchange Online. In this session, Tosin will walk us through
three tasks. One, the process of activating Azure resource
roles, two, through the approval process for both Azure AD
and Azure roles, and three, through the deactivation process.
Tosin, would you like to get us started?
Tosin: Of course. Azure Resource Manager has rich capabilities
for managing the resources behind Azure, such as subscriptions.
These are all governed by Azure resource roles that are
separate from that of Office 365 and Azure AD. For example,
subscription owner is a privileged role that can be targeted
by a PIM. The process is very similar to that of Azure AD
roles. In Step 1, a request is sent to the PIM service saying
who you are and what services you’re trying to get access
to. In Step 2, the PIM service then checks the repository for
policies related to this activation. This could be synchronous
or asynchronous. In Step 3 instead of going up to the Azure
AD, as we saw in the last video, the change then goes
down to the Azure Resource Manager. In Step 4, the Azure
Resource Manager is the target system that is updated for
all Azure resource roles. In Step 5, a notification is then sent
out to the appropriate people and logs are populated to
record this event.
Charity: Thank you, Tosin. We’ve talked about and given
examples of a synchronous policy that interrupts the flow
of a user real-time in our last video. Can you walk us
through an example of an asynchronous policy?
Tosin: Sure. In the previous examples, we mentioned PIM
services check the repositories for policies related to the
activation. If this has an asynchronous policy attached, then
an approver is needed to complete the workflow process.
Let’s take a look at this and see what the flow looks like.
Let’s say I need to administer Office 365 and I require
approval before I can do so.
In Step 1, a request is sent to the PIM service saying who I
am and what services I’m trying to get access to.
In Step 2, the asynchronous policy is checked, but then in
Step 3, when they asynchronous policy is checked, it would
see that require workflow approval. Because of this, in
Step 4, a notification is sent out to the approver.
Some time goes by and then they can either approve
or decline in Step 5.
This can be done by clicking on the link in the email or
within the portal. Once this is done successfully in Step
6, the Azure target system is updated. Lastly in Step 7,
the logs are captured and notifications are sent out.
Charity: Thank you, Tosin. What about when we’re done
performing our administrative tasks?
Tosin: Good question. We call that process deactivation.
There are two scenarios here. The admin can manually
deactivate the role. When they’re done or when the allocated
time expires, a schedule sweeping task will run to revoke
the permissions. Let’s look at this.
The request to connect specifically says I’m done, please
deactivate. When that happens, in Step 1, we send the
request to deactivate the role. Step 2, PIM checks who you
are. And in Step 3, we update the PIM tracking database,
as well as the target system to then take the user out of
the role. Boom. Tosin is no longer an Office 365 Admin.
In Step 4, we log the change and send an appropriate
notification.
Charity: That makes sense. What happens if the user goes
to grab coffee and forgets to deactivate?
Tosin: I’m glad you asked. We actually have a
scavaging type of batch job that runs to find out any
outstanding roles that are past due. So, let’s say my window
is eight hours and time’s up. In Step 1, the schedule
sweeping task wakes up, it picks up all dual role
assignments from the PIM tracking database, and in Step 2,
a worker process then updates the target system, as well as
the PIM tracking database to deactivate the roles. This
workflow runs once every 30 seconds.
Charity: Great. We hope you have found this video useful.
Three takeaways from the session include the activation
for Azure resource roles is a separate workflow from that of
Azure AD roles. PIM role activation is subject to policies and
these policies can be used to request approval for role
activation. Deactivation can either be request driven or time
bound.
We hope you have enjoyed this video. Please check out the
other architecture videos in the link below.
Tosin: Thank you.
[MUSIC]