[MUSIC]
Charity Shelbourne: Hello, and welcome back to our 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 this session, we’re going to be talking about Privileged
Identity Management, or PIM for short. Specifically, the
process that occurs when a user needs to carry out
administrative tasks in Azure AD or service such as Office
365 or Exchange Online.
Charity, why don’t you get us started.
Charity: Sure thing. In Azure Active Directory, you have
roles in the directory for a group of people that have
privileged access to Microsoft Services. Examples of
privileged roles can include Global Admin, SharePoint
Admin, and Exchange Admin to name a few. Prior to
implementing PIM, when a user is assigned a privileged
role such as Global Administrator, the role assignment is
permanent, meaning that account always has the ability
to perform privileged operations. This increases the risk of
a bad actor gaining access in case of a compromised
account. With PIM, we have just in time access that allows
you to convert your privileged account from permanent
access to eligible access. This means your regular account
does not have outstanding access and is instead granted
temporary assignment of admin privileges on an as needed
basis for a period of time.
In order to retain admin rights, we need to go through an
activation process.
So, let’s pretend I’m an Exchange Online Administrator,
and I need to do an administrative task. In Step 1, what
happens here is as the user, I send a request to a backend
service. We say, hey, I’m Charity, I want to interact and get
the Exchange Online Administrator role. When that happens,
in Step 2 and Step 3, the PIM service queries its repositories
and finds policies. There are two kinds of policies. We have
synchronous policies, meaning that I interrupt the flow of
the user real-time when I need to fulfill a requirement and
asynchronous policies, such as when I need an approver to
approve the activation of my administrative role. So, we
check for both kinds of policies and depending on that, we
interrupt with the controls, for example, if the synchronous
policy requires MFA.
Tosin: Charity, what about now viewers are probably noticing
that authentication flows are not in this diagram. Does that
happen prior to the Step 1?
Tosin: Yes, Tosin. That is correct. MFA is actually good
example of a synchronous policy. If I have a policy that
requires MFA before any user authenticates and my current
token does not contain the MFA claim, we’ll interrupt the
user. The behavior looks different if you’re coming in via
the portal or via the APIs. If the user is using the APIs,
we’ll kick them back until they have the MFA claim.
If they’re coming in through the portal, then we’ll guide
the user through that interruption to do MFA. This all takes
place in the portal prior to Step 1. When a user chooses
to activate their role in the case of MFA, we actually go
and bounce the user back to Azure AD with an OpenID
connect request, get a token with an MFA claim in it,
and come back to privileged identity management blade.
That is when our first step comes into play.
At that point, I have the MFA claim in my token. The policy
says I need MFA. We see the claim and we continue. So
in Step 2 and 3, we actually verify that we have met both
our synchronous and asynchronous policy requirements.
Another example of a synchronous policy is time. If you’re
approved to activate a role for eight hours and you ask for
nine, we’ll reject you real-time, so you can make the change.
Tosin: So, how do we keep track of these changes?
Charity: Well, when our policies are satisfied, in Step 4,
we update our internal PIM tracking database and the
target system using graph APIs. This is all done in one
transaction. When I say target system, this is any system
external to PIM that we’re updating with our changes.
Azure AD is an example of a target system. Azure
Resource Manager is an example of another target system.
Once the update is complete, in Step 5, we send back a
notification, trigger any alerting, and generate additional
logging. One of the features of PIM is when I activate my
role, we generate additional auditing, so we have the logs
to state who activated what and when. We also have many
optional settings in PIM. For example, we could also send
email to other admins holding the same role to say, hey,
Charity just requested privileged access to this role. It’s
an additional optional level of alerting available.
Once we have gone through these five steps, Azure AD has
a user properly in the role, and the change of who is an
Exchange Administrator reaches a target workload. This is
a sync based approach and can have some latency, which
is one of the reasons you are required to log out and log
back in. In this instance with Exchange Online, Exchange Online
is another example of a target system. We have some services
that read membership directly from the directory and some
have their own data structures and copy accordingly. For
Exchange Online, we have a short circuit call to Exchange
that happens during Step 4 to go ahead and populate the
role membership. This is actually a faster notification than
the yellow line you see here on the slide. And as a result,
Exchange has much less of a delay than SharePoint, for example.
All of our target systems can decide how and when they
want to be updated. In the case of SharePoint, SharePoint
has its own interval, where they pull role membership
changes.
Tosin: Thank you, Charity. That was really helpful.
We hope you have found this video useful. Three key
takeaways from this video are: Azure AD role membership
and Azure resource role memberships go through two
different workflows. Some roles may have some latency when
activating. And activation is available on the portal or via
APIs.
Join us in the next video when I talk about the process of
activating Azure resource roles, activating with a required
approver, and deactivation.
Please also check out our other architecture videos listed in
the link below.
Charity: Thank you.
[MUSIC]