Exploring Azure AD Privileged Identity Management (PIM) – Part 3 – Deep Dive

Exploring Azure AD Privileged Identity Management (PIM) – Part 3 – Deep Dive

Welcome back fellow geeks to my third post on my series covering Azure AD Privileged Identity Management (AAD PIM).  In my first post I provided an overview of the service and in my second post I covered the initial setup and configuration of PIM.  In this post we’re going to take a look at role activation and approval as well as looking behind the scenes to see if we can figure out makes the magic of AAD PIM work.

The lab I’ll be using consists of a non-domain joined Microsoft Windows 10 Professional version 1803 virtual machine (VM) running on Hyper V on my home lab.  The VM has a local user configured that is a member of the Administrators group.  I’ll be using Microsoft Edge and Google Chrome as my browsers and running Telerik’s Fiddler to capture the web conversation.  The users in this scenario will be sourced from the Journey Of The Geek tenant and one will be licensed with Office 365 E5 and EMS E5 and the other will be licensed with just EMS E5.  The tenant is not synchronized from an on-premises Windows Active Directory.  The user Homer Simpsons has been made eligible for the Security Administrators role.

With the intro squared away, let’s get to it.

First thing I will do is navigate to the Azure Portal and authenticate as Homer Simpson.  As expected, since the user is not Azure MFA enforced, he is allowed to authenticate to the Azure Portal with just a password.  Once I’m into the Azure Portal I need to go into AAD PIM which I do from the shortcut I added to the user’s dashboard.

3pim1.png

Navigating to the My roles section of the menu I can see that the user is eligible to for the Security Administrator Azure Active Directory (AAD) role.

3pim2

Selecting the Activate link opens up a new section where the user will complete the necessary steps to activate the role.  As you can see from my screenshot below, the Security Administrator role is one of the roles Microsoft considers high risk and enforces step-up authentication via Azure MFA.  Selecting the Verify your identity before proceeding link opens up another section that informs the user he or she needs to verify the identity with an MFA challenge.  If the user isn’t already configured for MFA, they will be setup for it at this stage.

3pim3.png

Homer Simpson is already configured for MFA so after the successful response to the MFA challenge the screen refreshes and the Activation button can now be clicked.

3pim4.png

After clicking the Activation button I enter a new section where I can configure a custom start time, configuration an activation duration (up to the maximum configured for the Role), provide ticketing information, and provide an activation reason..  As you can see I’ve adjusted the max duration for an activation from the default of one hour to three hours and have configured a requirement to provide a ticket number.  This could be mapped back to your internal incident or change management system.

3pim5.png

After filling in the required information I click the Activate button, the screen refreshes back to the main request screen, and I’m informed that activation for this role requires approval.  In addition to modifying the activation and requiring a ticket number, I also configured the role to require approval.

3pim6.png

At this point I opened an instance of Google Chrome and authenticated to Azure AD as a user who is in the privileged role administrator role.  Opening up AAD PIM with this user and navigating to the My roles section and looking at the Active roles shows the user is a permanent member of the Security Administrators, Global Administrators, and Privileged Role Administrators roles.

3pim7.png

I then navigate over to the Approve requests section.  Here I can see the pending request from Homer Simpson requesting activation of the Security Administrator role.  I’m also provided with the user’s reason and start and end time.  I’d like to see Microsoft add a column for the user’s ticket number.  My approving user may want to reference the ticket for more detail on why the user is requesting the role

3pim8.png

At this point I select the pending request and click the Approve button.  A new section opens where I need to provide the approval reason after which I hit the Approve button.

3pim9.png

After approving the blue synchronization-like image is refreshed to a green check box indicating the approval has been process and the user’s role is now active.

3pim10

If I navigate to My audit history section I can see the approval of Homer’s request has been logged as well as the reasoning I provided for my approval.

3pim11.png

If I bounce back to the Microsoft Edge browser instance that Homer Simpsons is logged into and navigate to the My requests and I can see that my activation has been approved and it’s now active.

3pim12.png

At this point I have requested the role and the role has been approved by a member of the Privileged Role Administrators role.  Let’s try modifying an AIP Policy.  Navigating back to Homer Simpsons dashboard I select the Azure Information Protection icon and receive the notification below.

3pim13.png

What happened?  Navigating to Homer Simpsons mailbox shows the email confirming the role has been activated.

3pim14.png

What gives?  To figure out the answer to that question, I’m going to check on the Fiddler capture I started before logging in as Homer Simpson.

In this capture I can see my browser sending my bearer token to various AIP endpoints and receiving a 401 return code with an error indicating the user isn’t a member of the Global Administrators or Security Administrators roles.

3pim15.png

I’ll export the bearer token, base64 decode it and stick it into Notepad. Let’s refresh the web page and try accessing AIP again. As we can see AIP opens without issues this time.

3pim16.png

At this point I dumped the bearer token from the failure and the bearer token from a success and compared the two as seen below.  The IAT, NBF, and EXP are simply speak to times specific to the claim.  I can’t find any documentation on the aio or uti claims.  If anyone has information on those two, I’d love to see it.

3pim17.png

I thought it would be interesting at this point to deactivate my access and see if I could still access AIP.  To deactivate a role the user simply accesses AAD PIM, goes to My Roles and looks the Active Roles section as seen below.

3pim18.png

After deactivation I went back to the dashboard and was still able to access AIP.  After refreshing the browser I was unable to access AIP.  Since I didn’t see any obvious cookies or access tokens being created or deleted.  My guess at this point is applications that use Azure AD or Office 365 Roles have some type of method of receiving data from AAD PIM.  A plausible scenario would be an application receives a bearer token, queries Azure AD to see if the user is in one a member of the relevant roles for the application.  Perhaps for eligible roles there is an additional piece of information indicating the timespan the user has the role activated and that time is checked against the time the bearer token was issued.  That would explain my experience above because the bearer token my browser sent to AIP was obtained prior to activating my role.  I verified this by comparing the bearer token issued from the delegation point at first login to the one sent to AIP after I tried accessing it after activation.  Only after a refresh did I obtain a new bearer token from the delegation endpoint.

Well folks that’s it for this blog entry.  If you happen to know the secret sauce behind how AAD PIM works and why it requires a refresh I’d love to hear it!  See you next post.

2 thoughts on “Exploring Azure AD Privileged Identity Management (PIM) – Part 3 – Deep Dive

  1. thanks a lot for the AAD PIM posts. Can you think of any scenarios where a customer / admin could lock themselves completely out of Azure AD / Office 365 with PIM?
    a customer mentioned this possibility with PIM / PAM systems.
    regards,
    Franck

    Like

    • Thanks Franck! It could definitely happen if you made every user an eligible for the roles and say deleted the service principal for PIM.

      This why I would recommend you have at least two break glass Privileged Role Administrators / Global Admins. These two accounts should be permanent members of the roles and should have tight control over the credentials (i.e. some type of password management / vault system ).

      If you’re able to come up with other scenarios, let me know!

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s