Identity Architecture: Privileged Identity Management | Azure Active Directory

Identity Architecture: Privileged Identity Management | Azure Active Directory


[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]

Leave a Reply