Identity Architecture: Privileged Identity Management #2 | Azure Active Directory

Identity Architecture: Privileged Identity Management #2 | Azure Active Directory


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

Leave a Reply