The idea is simple. A user requests activation of a role and writes a justification. PIM sends the activation request to a REST API that you control. Your API evaluates the request and tells PIM to continue, automatically approve it, or deny it.

That REST API can apply whatever business logic your organization needs. It can validate a ticket, check an HR system, look at the requested duration, apply different rules for different roles, or let an AI model reason over the justification written by the user.

And the really interesting part is that the current PIM portal can require an extension both before and after the normal human approval step. So of course I had to build one together with my favourite AI companion to see how it actually works.

In this blog post we will look at:

1. What PIM custom extensions actually are
2. Pre-approval and post-approval calls
3. What the API receives and must return
4. How to protect the API with Microsoft Entra ID
5. How to create the custom extensions with Microsoft Graph
6. How to attach an extension to a PIM role
7. Why I added an admin console
8. What I learned while testing the preview

Note: I am not going to spend this blog post walking through every line of API code. Your favorite AI coding tool can likely build it for you, as long as you give it the correct requirements and verify the output. The interesting part is to show how PIM, Entra ID and the API fit together.

What is a PIM custom extension?

A PIM custom extension is an HTTPS endpoint that PIM calls during activation of an eligible assignment.

It is available for:

• PIM for Groups
• PIM for Microsoft Entra roles
• PIM for Azure resources

The feature is currently in preview and requires Microsoft Entra ID Governance or an Entra Suite license. Microsoft has documented the feature here: Configure custom extensions for PIM role activation.

PIM sends the activation request directly to your API using HTTP POST. There is no Logic App, connector or shared secret sitting between PIM and the API. PIM gets an access token from Entra ID for your API and puts it in the Authorization header.

For the documented pre-approval flow, your API then returns one of three outcomes:

• Approved lets the request continue through the normal PIM workflow
• AutoApproved lets the activation continue without normal human approval
• Denied blocks the activation

That makes this a real policy decision point. It is not just another notification webhook, although you can use it for that too.

Before approval or after approval

When editing the activation settings for a role, the current PIM portal can require a custom extension at two different stages.

Pre-approval

The pre-approval extension runs before the normal PIM human approval step, if you have that configured. This is useful when the custom API should reject requests that should never reach an approver. It can also return AutoApproved, which skips the normal approval step completely.

In my dev tenant the portal provided two modes for the pre-approval extension:

• Audit mode calls the extension but does not enforce its decision
• Enabled mode calls the extension and enforces its decision

Audit mode is exactly what I want from a preview feature. It lets you see what the extension would have decided before giving it the power to block or automatically approve anything.

Post-approval

Note: Post-approval isn’t covered in the Microsoft Learn docs as of 2026-09-07, but it’s available as configuration properties in Graph and the PIM Portal so I guess it’s work in progress to just finalize the documentation.

The second checkbox in the screenshot above is called Require post-approval custom extension to activate. The wording and its position in the activation settings show the intended order. Normal PIM human approval happens first, then the custom extension is called before activation completes. Post-approval does not mean that access has already been granted. It means that a human has approved the request and the custom logic gets one final check before PIM completes activation.

This could be useful if the API needs to check that a ticket is still open, verify that an emergency condition is still active, or run a final compliance check after the human decision.

The same API application can serve both stages. I would still create separate extension registrations with different endpoint paths. This makes the intended stage visible in logs without depending on undocumented payload fields.

For example:

https://pim-api.learningbydoing.cloud/api/v1/pim/preapproval
https://pim-api.learningbydoing.cloud/api/v1/pim/postapproval

What could we use this for?

Microsoft lists ticket validation, HR checks, compliance workflows and dynamic approval logic as examples. This is where it gets interesting, because there are many other possibilities.

An API could check whether:

• The justification says what the user is going to do
• The requested role makes sense for that task
• The requested duration is reasonable
• A valid change or incident ticket exists
• The ticket belongs to the person or team requesting access
• The user is currently on call
• The device or user risk is acceptable
• The target resource is inside an approved maintenance window
• A highly privileged role always requires human approval

My test API looks at the reason entered by the user. It applies some normal deterministic rules first and is prepared to send the reason and relevant request context to an AI model. When that integration is enabled, the model returns a structured assessment with a verdict, confidence, risk and a useful explanation.

Something like need access tells us almost nothing and should not be enough to activate a powerful role. A reason explaining what needs to be changed, why it needs to happen now, which system is involved and which ticket tracks the work is much more useful.

AI is not magic here. The model is one policy component, not an all knowing security administrator. Start in audit mode, measure the results, keep critical roles away from automatic approval, and make sure failures never silently turn into approvals.

The request from PIM

The request body differs between the three PIM providers.

For Groups, PIM sends a privilegedAccessGroupAssignmentScheduleRequest.

For Microsoft Entra roles, PIM sends a unifiedRoleAssignmentScheduleRequest.

For Azure resources, PIM sends an Azure role assignment schedule request with the values inside a properties object.

The object names are different, but fortunately the useful information is mostly the same:

• Request ID
• Principal ID
• Role or group ID
• Scope
• Justification
• Requested start time and duration
• Ticket number and ticket system, when configured

I normalize all three payloads into one internal request model before applying policy. That keeps the evaluation logic independent of the PIM provider.

Warning: Do not assume that the justification is safe input. A user can write anything in that field, including instructions intended to manipulate an AI model. If you use AI, treat the text as untrusted data, clearly separate it from system instructions, use structured model output, and apply normal policy rules before AI reasoning.

The response to PIM

The response is refreshingly small:

{
  "evaluationId": "7bb822c8-550c-42c7-98b3-1a4d095f95ee",
  "evaluationOutcome": "Approved",
  "reason": [
    "The request explains the planned change and references a valid incident."
  ]
}

evaluationId should identify the evaluation for troubleshooting and audit purposes. I recommend making it deterministic for the PIM request and stage, so a retry does not create conflicting decisions.

evaluationOutcome must be Approved, AutoApproved or Denied.

reason is an array of messages explaining the decision. This is especially important for denials because the user needs to know what was missing and how to write a better request.

Microsoft currently uses 10000 milliseconds and three retries in its Graph example. The documentation describes these fields as the time PIM waits and the number of retry attempts, but does not publish their supported ranges. Do not assume that the example values are hard limits. Use values accepted by your tenant and keep the API timeout shorter than the PIM timeout so there is still time to return a controlled response if an external service or AI model is slow.

Protect the API with Microsoft Entra ID

PIM custom extensions supports proper Entra authentication. Create a single tenant app registration for the API. In this example, the endpoint is:

https://pim-api.learningbydoing.cloud/api/v1/pim/preapproval

The host name in the Application ID URI must match the host name of the endpoint, and the URI must end with the Application client ID. Follow Microsoft’s documentation for doing this properly.

If the client ID is 11111111-2222-3333-4444-555555555555, the Application ID URI becomes:

api://pim-api.learningbydoing.cloud/11111111-2222-3333-4444-555555555555

No client secret or certificate is required for PIM to call the API. PIM requests a token for the Application ID URI itself.

Validate more than just the token signature

Validating that a token was signed by Entra ID is not enough. The API should validate all of the following:

1. The signature is valid and uses current Entra signing keys
2. The token has not expired
3. The issuer belongs to your tenant
4. The audience is your Application ID URI
5. The calling application is Microsoft Entra PIM

For a version 2 access token, the calling application is found in the azp claim. For a version 1 token, it is found in appid.

The Microsoft Entra PIM service application ID in the token I received was:

1c67c054-65c8-4f7f-92a1-eb7ba6e48627

The API should reject the request if that value does not match. Otherwise, another application that manages to request a token for your API could potentially submit its own fake activation payload.

Here is a nice preview documentation trap. The English Microsoft Learn article currently shows what looks like an example client ID in the caller validation sentence. Several localized versions show the PIM service ID above, and that value also matched the azp claim in my live request. Confirm the caller claim with a controlled test in your own tenant before hard coding it.

I would also recommend:

• Accepting POST only on the evaluation endpoints
• Limiting request size and JSON depth
• Keeping the service single tenant
• Using HTTPS with a valid certificate
• Avoiding raw request and justification logging
• Giving the API runtime identity only the permissions it actually needs
• Keeping any administrator interface behind a separate Entra role, locked behind GSA Private Access
• Using managed identities instead of API keys when calling Azure services

The activation reason can contain operational details, incident numbers and resource information. I choose to store the decision evidence, but deliberately did not store the raw justification.

Check the app registration and Enterprise application

The Application ID URI is stored as identifierUris on the app registration. PIM also checks that the same value exists in servicePrincipalNames on the Enterprise application.

You can verify both with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes 'Application.Read.All'

$clientId = '11111111-2222-3333-4444-555555555555'

$appUri = "https://graph.microsoft.com/v1.0/applications?`$filter=appId eq '$clientId'&`$select=id,appId,identifierUris"
$spUri = "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=appId eq '$clientId'&`$select=id,appId,servicePrincipalNames"

$application = (Invoke-MgGraphRequest -Method GET -Uri $appUri).value[0]
$servicePrincipal = (Invoke-MgGraphRequest -Method GET -Uri $spUri).value[0]

$application | Select-Object appId, identifierUris
$servicePrincipal | Select-Object appId, servicePrincipalNames

Both objects should contain:

api://pim-api.learningbydoing.cloud/11111111-2222-3333-4444-555555555555

Create the custom extensions with Microsoft Graph

Custom extensions are currently managed through the Microsoft Graph beta endpoint.

Connect-MgGraph `
  -Scopes 'PrivilegedAccess-CustomExt.ReadWrite.All'

The following function creates a custom extension. The timeout and retry values match Microsoft’s current example:

function New-PimCustomExtension {
    param(
        [Parameter(Mandatory)]
        [string] $DisplayName,

        [Parameter(Mandatory)]
        [ValidateSet('entraGroups', 'entraRoles', 'azureResources')]
        [string] $ResourceType,

        [Parameter(Mandatory)]
        [string] $TargetUrl,

        [Parameter(Mandatory)]
        [string] $ApplicationIdUri
    )

    $body = @{
        '@odata.type' = '#microsoft.graph.roleManagementCustomCalloutExtension'
        id = [Guid]::NewGuid().ToString()
        displayName = $DisplayName
        description = 'Evaluates PIM role activation requests'
        endpointConfiguration = @{
            '@odata.type' = '#microsoft.graph.httpRequestEndpoint'
            targetUrl = $TargetUrl
        }
        clientConfiguration = @{
            '@odata.type' = '#microsoft.graph.customExtensionClientConfiguration'
            timeoutInMilliseconds = 10000
            maximumRetries = 3
        }
        authenticationConfiguration = @{
            '@odata.type' = '#microsoft.graph.azureAdTokenAuthentication'
            resourceId = $ApplicationIdUri
        }
        resourceType = $ResourceType
        customAttributes = @()
    }

    Invoke-MgGraphRequest `
      -Method POST `
      -Uri 'https://graph.microsoft.com/beta/identityGovernance/privilegedAccess/customExtensions' `
      -Body ($body | ConvertTo-Json -Depth 10) `
      -ContentType 'application/json'
}

The three resource type values that worked in my tenant are:

entraGroups
entraRoles
azureResources

Create one extension for each PIM provider you plan to use:

$applicationIdUri = 'api://pim-api.learningbydoing.cloud/11111111-2222-3333-4444-555555555555'
$preApprovalUrl = 'https://pim-api.learningbydoing.cloud/api/v1/pim/preapproval'

New-PimCustomExtension `
  -DisplayName 'Reason validation for PIM Groups' `
  -ResourceType entraGroups `
  -TargetUrl $preApprovalUrl `
  -ApplicationIdUri $applicationIdUri

New-PimCustomExtension `
  -DisplayName 'Reason validation for Entra roles' `
  -ResourceType entraRoles `
  -TargetUrl $preApprovalUrl `
  -ApplicationIdUri $applicationIdUri

New-PimCustomExtension `
  -DisplayName 'Reason validation for Azure roles' `
  -ResourceType azureResources `
  -TargetUrl $preApprovalUrl `
  -ApplicationIdUri $applicationIdUri

If you want separate behavior after human approval, create another extension for each required provider and point it to the post-approval endpoint instead. That stage is not yet covered by the current Microsoft Learn article, so test the actual call and response in your tenant before enabling it for an important role.

You can list the registered extensions with:

$uri = 'https://graph.microsoft.com/beta/identityGovernance/privilegedAccess/customExtensions'

(Invoke-MgGraphRequest -Method GET -Uri $uri).value |
    Select-Object id, displayName, resourceType,
        @{ Name = 'TargetUrl'; Expression = { $_.endpointConfiguration.targetUrl } },
        @{ Name = 'ResourceId'; Expression = { $_.authenticationConfiguration.resourceId } }

Create the extension in the portal

You can use the Entra admin center instead of Graph.

1. Open Identity governance
2. Open Privileged Identity Management
3. Select Custom Extensions
4. Select Create a custom extension
5. Choose Groups, Microsoft Entra roles or Azure resources
6. Enter the HTTPS endpoint, timeout and retry count
7. Select the app registration used to protect the API
8. Review and create

The resource type matters. An extension created for Groups will not appear when you edit an Azure resource role.

Attach the extension to a role

Creating the extension does not make PIM call it. It must be attached to the activation settings of each role where it should run.

For an Azure resource role:

1. Open Identity governance and Privileged Identity Management
2. Select Azure resources
3. Open the subscription, Resource Group or resource
4. Open Settings and select the role
5. Select Edit and stay on the Activation tab
6. Enable Require pre-approval custom extension to activate
7. Select the custom extension
8. Choose Audit mode or Enabled
9. Optionally enable Require post-approval custom extension to activate and select the extension for that stage
10. Save the role settings

The process is almost identical for Microsoft Entra roles and PIM for Groups.

Start safely

Start with one low risk test role. Keep the normal human approval requirement enabled. Put the pre-approval extension in Audit mode, or implement a Shadow mode inside the API that always returns Approved while recording the recommendation it would have returned.

I used an internal Shadow mode because it gives me the same behavior across PIM providers and stages. The API stores both values:

Recommended: Denied
Returned: Approved

This makes it possible to collect real activation data without letting a new policy engine affect access on day one.

An admin console makes this much easier

The console is not part of the Microsoft feature and the API works without it. Still, running this thing blind felt like a bad idea, so I added a small operations console. It shows the current enforcement mode, policy version, API version, storage status, AI model status and post-approval mode. It also shows recent evaluations with the stage, target, recommended outcome, returned outcome, confidence and duration.

The difference between the recommended and returned outcome is especially useful in Shadow mode. I can see that the API wanted to deny a request while PIM still received Approved. This gives me real data before I let the new policy affect access.

The console also lets me create policies for an exact role or group. A policy can require a longer justification, limit activation duration, require a ticket and decide whether that exact target is even eligible for automatic approval. Automatic approval remains disabled unless I explicitly enable it for a target.

The console is protected by Entra ID as well. And the page deliberately does not show or store the raw activation reason. It stores enough evidence to understand the outcome without creating another database full of operational details and incident information.

Things I learned the hard way

This is a preview feature, and yes, it shows in a few places.

The create example needed an ID

The Microsoft Graph example did not include an id property when I tested it. My first POST returned:

Id property needs to have a GUID value.

Adding this to the request fixed it:

id = [Guid]::NewGuid().ToString()

The Application ID URI existed in only one place

The app registration had the correct identifierUris value, but it had not been synchronized to servicePrincipalNames on the Enterprise application.

Creating the custom extension then failed with:

The resourceId is not present in the service principal names for application id.

Checking both objects and reconciling the missing value fixed the problem.

The portal knows more than the documentation

The current Microsoft documentation explains the pre-approval extension, request payload and response contract quite well. The PIM portal also exposes a native post-approval custom extension setting, even though this is not explained in the same documentation yet.

The portal is also where you can see the difference between Audit mode and Enabled for the pre-approval call.

Preview means preview. Expect both the API and portal experience to change, and test this again before using it for important roles.

Do we need an AI agent for this?

Maybe not.

For my test use case, this is one stateless classification request with a strict response schema and a hard timeout. A direct call to a hosted model is simpler, faster and easier to audit. I do not need to give an agent tools, memory and its own workflow just to decide whether a paragraph is a good enough justification.

I would use normal code for rules that can be expressed normally, then use the model for understanding the written justification. The code remains responsible for the final outcome and enforcement mode.

I think the model should not decide whether it feels like calling another system. If ticket validation is required, the API should call that system explicitly and include the result as trusted context for the model or policy engine.

Final thoughts

This is one interesting improvement, great to see Microsoft releasing new PIM features.

PIM is no longer limited to the same static activation rules for every organization. We can insert our own business logic directly into the documented pre-approval flow. That power also makes it easy to build something dangerous. An API outage can affect role activation. Weak token validation can expose a decision endpoint. Bad automatic approval logic can bypass humans. Logging every justification can create a new pile of sensitive data.

Build it small. Protect it properly. Start in audit mode. Measure what it would do. Then decide how much authority it should actually have.

But PIM has also started to feel a bit… forgotten.

Some parts of the product have barely changed for years. Reporting Azure RBAC eligibility at scale is still painful. Important lifecycle operations available in the portal are missing from the public APIs. Getting read-only visibility into PIM often requires surprisingly powerful roles. And some of the portal experiences could definitely use some love.

So, if Microsoft made me Product Manager for PIM for a day, here’s what I’d put on the backlog.

1. PIM is still great
2. PIM enforces least privilege better than it practices it
3. Reporting shouldn’t require crawling Azure
4. Email is apparently the PIM dashboard
5. The API can do it. You just can’t
6. Fine. Put a Copilot in it
7. My PIM backlog

PIM is still great

Before complaining, let’s give PIM some credit. Having my admin account running with only Reader access most of the day, and requiring elevation before I can actually change anything, is a great security and governance model.

I think this is becoming even more important. Today many of us have our favorite AI companion sitting directly in our IDE, terminal or browser, just one badly written prompt away from doing something we didn’t really intend. If my current permissions only allow reading resources, the potential blast radius is quite different from having Contributor activated all day.

PIM also has some really good features.

One of my favorites is the ability to scope down an Azure RBAC activation. If I’m eligible for Contributor at a Management Group containing ten subscriptions, I can activate the role for only the two subscriptions I’m actually going to work on. That’s proper just-enough-access.

Conditional Access authentication context is another great addition. Requiring a compliant device and phishing-resistant authentication before activating a highly privileged role makes a lot of sense. There is one important detail though: the authentication context protects the activation, not necessarily where the activated permissions can be used afterwards. Microsoft even documents that after activation, another session, device or location isn’t prevented from using the activated permissions.

So I tend to think of PIM primarily as an access lifecycle and governance control with very useful security benefits, rather than some magical security boundary around privileged sessions. It reduces when my identity is privileged. It doesn’t bind the privilege to the session where I activated it.

Still, PIM is great, which is exactly why I wish Microsoft would give it some more attention. There have of course been additional improvements over the last few years.

PIM for Groups became a major part of the product. Conditional Access authentication context was added. Activating PIM group membership can trigger application provisioning for JIT access to applications. Azure RBAC got better integration with PIM, and Entitlement Management can be combined with PIM for Groups.

One preview feature that deserves a special mention is custom extensions for PIM role activation. PIM can call a secured REST API as part of the activation flow, allowing organizations to add their own business logic before or after approval. The extension can, for example, validate ticket numbers, check employment or compliance data, integrate with audit systems, or apply dynamic approval rules. Based on the response, PIM can continue the normal workflow, automatically approve the activation, or deny it.

Custom extensions work with PIM for Groups, Microsoft Entra roles, and Azure resources. This is exactly the kind of extensibility I want to see in PIM, although the feature is currently in preview.

These are good additions. But if you remove new UIs and integrations with other Entra services, the list of major changes to the core PIM experience over the last few years becomes surprisingly short. Meanwhile, some very old limitations are still there. Let’s look at those instead.

PIM enforces least privilege better than it practices it

One of the main reasons for using PIM is least privilege. That’s why I find it slightly ironic that administering and even viewing parts of PIM often doesn’t follow the same principle very well. Take Azure RBAC extension and renewal requests.

If I want to see pending requests across Azure resources, I need access such as User Access Administrator, Role Based Access Control Administrator or Owner at the relevant scope(s). But what if I only want to see them? Why shouldn’t a Reader for Azure RBAC, and Global Reader for Entra, or a dedicated PIM Reader role be able to see that a user has requested an extension of an existing eligible assignment?

This becomes especially important in larger organizations. Many organizations likely outsource Azure RBAC management to workload owners or development team leads:

Here’s your subscription. Here’s User Access Administrator. Manage your team’s access.

The workload owner probably should decide whether Adele still needs Contributor on the non-production subscription. But does that really mean the workload owner also needs permission to grant arbitrary Azure RBAC roles to arbitrary identities? I don’t think so.

There are really three different responsibilities here:

• Observe: Who has access? Which requests are pending? Which assignments are about to expire?
• Decide: Should Adele still have this access?
• Execute: Actually change the Azure RBAC or PIM assignment.

PIM currently ties these responsibilities too closely together. I’d like to see proper read-only PIM permissions, plus something like a scoped PIM Access Steward role. Let workload owners review and approve access for their resources without making them full RBAC administrators.

Use least privilege, even for the people managing least privilege.

Reporting shouldn’t require crawling Azure

This one has annoyed me for years. Reporting on normal, standing Azure RBAC role assignments is actually quite nice. Azure Resource Graph contains role assignments, meaning I can use KQL to query assignments across a large Azure estate. Reporting on PIM eligible Azure RBAC assignments is another story.

For example, this query returns the key properties of standing Azure RBAC role assignments across the scopes available to Azure Resource Graph:

authorizationresources
| where type =~ 'microsoft.authorization/roleassignments'
| extend roleDefinitionId = tostring(properties.roleDefinitionId),
         principalType = tostring(properties.principalType),
         principalId = tostring(properties.principalId),
         scope = tostring(properties.scope)
| project scope, principalId, principalType, roleDefinitionId

But there is no such thing as 'microsoft.authorization/roleeligibilityassignments'. The ARM PIM API exposes roleEligibilityScheduleInstances, but the API is scope based:

/{scope}/providers/Microsoft.Authorization/roleEligibilityScheduleInstances

The scope is a required part of the request. That’s perfectly fine if my question is:

Who is eligible for access on this subscription?

It isn’t so great when the auditor asks:

Who is eligible for privileged access anywhere in Azure?

In a large organization, access can be assigned at the tenant root Management Group, child Management Groups, subscriptions, Resource Groups and individual resources. Now we’re crawling the Azure hierarchy and collecting eligibility from different scopes just to build an inventory.

Azure already has a scalable inventory and query engine. It’s called Azure Resource Graph. Please index PIM eligible assignments in it.

There are of course other and often better ways to manage Azure RBAC lifecycle. Assigning a PIM-managed group to an Azure role is usually much easier to govern than creating individual eligible RBAC assignments. Entitlement Management can take this further by putting access packages, approvals, expiration and access reviews around the group or Azure role membership. I like these patterns and use them where they make sense, but they don’t remove the reporting problem.

In an organization with hundreds or thousands of subscriptions, different teams, different ways of working and different role requirements, there won’t always be one clean access model. Some access comes from groups. Some is direct on individual resources. Some is inherited from Management Groups. Some comes through access packages. Some teams have custom roles.

The auditor doesn’t really care. They just want to know:

Who can get privileged access to this thing?

We should have a good answer.

Email is apparently the PIM dashboard

If you’ve worked with PIM for a while, you probably know that PIM really likes email. Role activated? Email. Assignment changed? Email. Something needs approval? Email.

This would be fine if PIM had an equally good central place for administrators to see everything requiring attention. It doesn’t.

And if you decide that you don’t want all those emails, notification configuration is tied to role settings. Managing different notification settings across many roles and Azure scopes quickly becomes another configuration exercise. There are some good community tools out there, yes, but this should really be built-in.

I would love a central PIM operations view:

• 12 pending requests
• 8 assignments expiring this week
• 3 requests waiting for approval for more than five days
• 27 permanent privileged assignments

Give me filters, useful columns and an API exposing the same information. Speaking of useful columns, the extension and renewal approval experience has recently become another small frustration.

The current role extension UI has fixed columns. I can’t make them wider and I can’t choose which columns I want to display. So I end up looking at values such as:

subscripti…

Great. Thanks. What’s particularly frustrating is looking at the network requests in Developer Tools and seeing how much useful information is actually returned by the backend. The data is there; the UI just doesn’t show it.

There is another small UI detail that makes managing expiring assignments harder than it should be. In a user’s PIM roles UI, for active assignments, the Renew link is disabled until the assignment is close enough to expiration to be renewed, makes sense. For eligible assignments however, the Renew link is active all the time. Click it too early and PIM simply tells you that the assignment can’t be renewed yet.

So the portal already knows the renewal window. It just doesn’t use that information consistently in the UI. It’s likely a small bug.

Finding the assignments that actually are about to expire isn’t much better. There is no clear warning on the role, and the columns can’t be sorted to bring the assignments closest to expiration to the top. Which brings us back to the feature PIM seems to trust most for operational visibility: email.

The API can do it. You just can’t

This is probably my biggest PIM frustration. I recently worked with Claude on a custom approval gate portal for Azure RBAC extension and renewal requests. The idea was simple: the people who know whether someone still needs access are often the workload or project owners. I wanted those owners to review PIM extension requests without giving every one of them User Access Administrator or Owner role assignments on their subscriptions.

The flow looked roughly like this:

PIM extension request → Custom approval portal → Workload owner approves or rejects → Backend executes the decision

The workload owner makes the decision, and a controlled workload identity executes it. Nice separation of duties. There was only one problem: the public PIM APIs don’t expose the complete extension and renewal approval lifecycle I needed.

So I did what any responsible identity engineer does after spending too much time looking at Developer Tools in the browser. I found the API used by Microsoft’s own PIM portal. The internal api.azrbac.azure.com API allowed me to fetch the pending requests and approve or reject them programmatically. I authenticated using a Managed Identity with the required Azure RBAC permissions, and it worked great.

Yes, this was an undocumented and unsupported API. I knew that.

Then during the summer of 2026 something changed. Application authentication that previously worked against this internal API stopped working in my scenario, with the API now requiring a user token. I can’t really blame Microsoft for changing an internal API. It’s unsupported. The problem is that there is no supported API to migrate to. So my idea stranded there.

Using Microsoft’s PIM portal I can retrieve these requests and approve or reject them using click-ops (which I hate). The backend functionality exists, so please expose it. And while you’re at it, give workload identities a least-privileged read permission for PIM extension requests.

Even if Microsoft doesn’t want applications approving requests, I should at least be able to build automation saying:

There are seven extension requests waiting for approval.

Today PIM is very good at emailing humans about this. I’d like to let machines help too.

Fine. Put a Copilot in it

Maybe I’ve misunderstood the problem. It’s 2026. Perhaps PIM simply needs a Copilot. Microsoft has managed to put Copilot into approximately everything else, so surely we can find a licensing opportunity here too.

The annoying part is that I would actually use a PIM Copilot.

Imagine asking:

Show me everyone eligible for Owner or User Access Administrator on subscription X.

I need to whitelist this IP address on Key Vault X. Find the least-privileged role I’m eligible for on that scope and activate it for one hour.

Which privileged assignments haven’t been used for six months and could be removed?

That would actually be useful. PIM already knows a lot about roles, eligibility, scopes and activation requirements. Add proper inventory, permission analysis and automation around it and there are some genuinely interesting possibilities.

There’s just one small problem. Before we give PIM a Copilot, we need to give machines proper access to PIM: complete public APIs, a tenant-wide inventory and read-only permissions. Then you can slap a Copilot license requirement on it. Deal?

My PIM backlog

So here’s my PIM backlog:

• Complete public APIs. If the PIM portal UI can do it, there should be a supported way to automate it (e.g. for pending renewal requests).
• PIM Reader role. Let people and workload identities observe PIM without giving them permissions to administer access (e.g. for pending renewal requests).
• Delegated PIM governance. Let workload owners approve access without making them UAA, RBAC Administrator or Owner (e.g. for pending renewal requests).
• Index PIM eligible Azure RBAC roles in Azure Resource Graph. Make tenant-wide Azure RBAC reporting easy with KQL.
• A central operational dashboard. Show me more of what requires attention across PIM (expiring roles, pending renewals etc).
• Better UI. Resizable columns and column selection aren’t exactly futuristic features.
• Multi-role activation. PIM already lets me scope one activation down to selected resources. Let me activate several required roles in one workflow too.
• And yes, PIM Copilot. But please fix the plumbing first.

PIM doesn’t need to be reinvented. It needs to be finished.

Well, not anymore! Say hello to the new ‘request access packages on-behalf-of other users’ feature now in public preview, available for customers with the Microsoft Entra ID Governance or Microsoft Entra Suite licenses.

The current preview allows IGA admins to enable the functionality per access package policy, specifically allowing managers to request packages on-behalf-of their direct reports. The default setting is not to allow on-behalf-of requests, which means it can be gradually rolled out on access packages where it makes sense to offer this capability. Once enabled, managers can visit the MyAccess portal, look up the correct access package, select it, and choose which user to request for. The request follows the normal approval configuration, but there’s also an option to bypass the approval process if the manager is also the approver of the request - which makes sense in those access packages where managers are specified as approvers.

It’s time to start paying more attention to access package requests to spot when the target user is not the same as the requestor.

The public preview currently only supports managers requesting on-behalf-of their direct reports, but I’m really hoping to see this expanded before general availability. Examples of other requestors that could benefit from requesting on-behalf-of other users include application or system owners, helpdesk staff, colleagues helping with onboarding of new team members, etc.

I have to say, Microsoft is really picking up the pace with their cloud IGA offering. Hope to see more cool and highly awaited features soon!

Check out the official documentation and start testing it in your environment today.

Application permissions, often called app role assignments in Entra ID (former Azure AD), are permission sets that an app, service principal or managed identity can be assigned in another resource app, and that app’s identity can then access and utilize the resource app’s API without a signed-in user present.

Service principals by default have no access to enumerate other objects in Entra ID (former Azure AD). An example, if a service principal used in automated workflows requires read access to all user objects in Entra ID, it will need to be assigned the app role User.Read.All application permission (app role) in Microsoft Graph, consented by an admin, to be able to query Graph for any or all users.

The Microsoft Graph API is covering endpoints for most of Entra ID and Microsoft 365 services, and it has a wide range of app roles for providing specific API access. And let’s not forget the old and deprecated Azure AD Graph API which has not yet been fully been sunset. It’s critical for compliance and security hygiene of the tenant to audit and monitor app role assignments for these resources especially. Do note that there are a lot of other APIs with their own sets of app roles in Entra ID, some examples below, but for this blog post I will focus on Microsoft Graph and Azure AD Graph.

Some app roles can be abused for privilege escalation all the way up to Global Admin, as Andy Robbins (co-creator of BloodHound) points out in this blog post. A Global Admin can do whatever it wants in Entra ID, and it can also elevate its access for all Azure subscriptions in the tenant with the flip of a switch. This just proves how critical it is to have full control on any high-privilege app roles.

With these things in mind, let’s look at how to extract all app role assignments for Microsoft Graph and Azure AD Graph, including other valuable information for each service principal, using Powershell and the Graph Powershell SDK v2 module.

• Identify highly privileged app roles
• Required scopes in Graph Powershell SDK
• Extracting data
  • App roles and assignments
  • Owner organizations and sign-in activities
• Compiling the report
• Full script on GitHub

Identify highly privileged app roles

I wish there was a list of all Microsoft Graph app roles with tiering information, identifying how privileged each app role is. Since there are none I’ve added some of the app roles that I know are highly privileged - they will be specifically flagged as Tier 0 in the report. There are many other privileged app roles, but let’s start with these as abusing them can lead to Global Admin access. You can easily add other roles and other tiers, depending on what you want to report on.

# The tier 0 app roles below are typically what can be abused to become Global Admin.
# NOTE: Organizations should do their own investigations and include any app roles to regard as sensitive, and which tier to assign them.
$appRoleTiers = @{
    'Application.ReadWrite.All'          = 'Tier 0' # SP can add credentials to other high-privileged apps, and then sign-in as the high-privileged app
    'AppRoleAssignment.ReadWrite.All'    = 'Tier 0' # SP can add any app role assignments to any resource, including MS Graph
    'Directory.ReadWrite.All'            = 'Tier 0' # SP can read and write all objects in the directory, including adding credentials to other high-privileged apps
    'RoleManagement.ReadWrite.Directory' = 'Tier 0' # SP can grant any role to any principal, including Global Admin
}

Update 2023-08-17 @ 11:00 (CEST): Removed ‘Application.ReadWrite.OwnedBy’ from the list as this permission isn’t Tier 0 at all: “Allows the app to create other applications, and fully manage those applications (read, update, update application secrets and delete), without a signed-in user. It cannot update any apps that it is not an owner of.”

Required scopes in Graph Powershell SDK

When connecting to Microsoft Graph with the Graph Powershell SDK v2 module, the following delegated scopes are required:

1. Application.Read.All (to enumerate service principals)
2. AuditLog.Read.All (to pull out service principal sign-in activity)
3. CrossTenantInformation.ReadBasic.All (to query app owner tenant information for 3.party apps)

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Application.Read.All","AuditLog.Read.All","CrossTenantInformation.ReadBasic.All"

Other than that, no special privileges are necessary for the user account connecting to Microsoft Graph - only read-access is used.

Extracting data

Now let’s start extracting the data we need from Microsoft Graph to create the report.

App roles and assignments

First we are querying for Microsoft Graph and Azure AD Graph’s service principal objects in the tenant - by filtering on their well-known Application IDs (00000003-0000-0000-c000-000000000000 and 00000002-0000-0000-c000-000000000000). Once the service principals have been found, we are extracting all app roles and app role assignments, creating hashtable for quick lookups, and lastly joining the app role assignments for both service principals.

# Get Microsoft Graph SPN, appRoles, appRolesAssignedTo and generate hashtable for quick lookups
$servicePrincipalMsGraph = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
[array] $msGraphAppRoles = $servicePrincipalMsGraph.AppRoles
[array] $msGraphAppRolesAssignedTo = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $servicePrincipalMsGraph.Id -All
$msGraphAppRolesHashTableId = $msGraphAppRoles | Group-Object -Property Id -AsHashTable

# Get Azure AD Graph SPN, appRoles, appRolesAssignedTo and generate hashtable for quick lookups
$servicePrincipalAadGraph = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0000-c000-000000000000'"
[array] $aadGraphAppRoles = $servicePrincipalAadGraph.AppRoles
[array] $aadGraphAppRolesAssignedTo = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $servicePrincipalAadGraph.Id -All
$aadGraphAppRolesHashTableId = $aadGraphAppRoles | Group-Object -Property Id -AsHashTable

# Join appRolesAssignedTo entries for AAD / MS Graph
$joinedAppRolesAssignedTo = @(
    $msGraphAppRolesAssignedTo
    $aadGraphAppRolesAssignedTo
)

We can now process each of the app role assignments in $joinedAppRolesAssignedTo to create a report, while enriching the data set even further.

# Process each appRolesAssignedTo for AAD / MS Graph
$progressCounter = 0
$cacheAppOwnerOrganizations = @()
$cacheServicePrincipalObjects = @()
$cacheServicePrincipalSigninActivities = @()
$cacheServicePrincipalsWithoutSigninActivities = @()
[array] $msGraphAppRoleAssignedToReport = $joinedAppRolesAssignedTo | ForEach-Object {

    $progressCounter++
    $currentAppRoleAssignedTo = $_
    Write-Host "Processing appRole # $progressCounter of $($joinedAppRolesAssignedTo.count)"

    # Lookup appRole for MS Graph
    $currentAppRole = $msGraphAppRolesHashTableId["$($currentAppRoleAssignedTo.AppRoleId)"]
    if($null -eq $currentAppRole) {
        # Lookup appRole for AAD Graph
        $currentAppRole = $aadGraphAppRolesHashTableId["$($currentAppRoleAssignedTo.AppRoleId)"]
    }

Service principals, owner organizations and sign-in activities

The app role assignments in $joinedAppRolesAssignedTo does not contain all the information we need about the assigned service principals. So we will query Graph for the service principal objects, the owner organizations for multi-tenant apps, and sign-in activities. To optimize the script we’re utilizing cache and only querying each object one time even tho it has multiple app role assignments.

    # Lookup servicePrincipal object - check cache
    $currentServicePrincipalObject = $null
    if($cacheServicePrincipalObjects.Id -contains $currentAppRoleAssignedTo.PrincipalId) {
        $currentServicePrincipalObject = $cacheServicePrincipalObjects | Where-Object { $_.Id -eq $currentAppRoleAssignedTo.PrincipalId }
    } 
    
    else {
        # Retrieve servicePrincipalObject from MS Graph
        $currentServicePrincipalObject = Get-MgServicePrincipal -ServicePrincipalId $currentAppRoleAssignedTo.PrincipalId
        $cacheServicePrincipalObjects += $currentServicePrincipalObject
        Write-Host "Added servicePrincipal object to cache: $($currentServicePrincipalObject.displayName)"
    }

Note that looking up the app owner organization (for multi-tenant apps) uses Invoke-MgGraphRequest with a URI since I haven’t found a cmdlet for this in Graph Powershell SDK yet.

    # Lookup app owner organization
    $currentAppOwnerOrgObject = $null
    if($null -ne $currentServicePrincipalObject.AppOwnerOrganizationId) {
        # Check if app owner organization is in cache
        if($cacheAppOwnerOrganizations.tenantId -contains $currentServicePrincipalObject.AppOwnerOrganizationId) {
            $currentAppOwnerOrgObject = $cacheAppOwnerOrganizations | Where-Object { $_.tenantId -eq $currentServicePrincipalObject.AppOwnerOrganizationId }
        } 

        else {
            # Retrieve app owner organization from MS Graph
            $currentAppOwnerOrgObject = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='$($currentServicePrincipalObject.AppOwnerOrganizationId)')"
            $cacheAppOwnerOrganizations += $currentAppOwnerOrgObject
            Write-Host "Added app owner organization tenant to cache: $($currentAppOwnerOrgObject.displayName)"
        }
    }

Let’s pull the sign-in activities for the service principals. This gives us information about the most recent service principal sign-in and delegated (user) sign-in, which can help us identify stale apps. Note that this newly released reporting endpoint in Graph is still in beta, which is why we need to utilize the Get-MgBetaReportServicePrincipalSignInActivity cmdlet.

    # Lookup servicePrincipal sign-in activity if not already in no-signin-activity list
    $currentSpSigninActivity = $null
    if($currentServicePrincipalObject.AppId -notin $cacheServicePrincipalsWithoutSigninActivities) {
        if($cacheServicePrincipalSigninActivities.AppId -contains $currentServicePrincipalObject.AppId) {
            $currentSpSigninActivity = $cacheServicePrincipalSigninActivities | Where-Object { $_.AppId -eq $currentServicePrincipalObject.AppId }
        } 

        else {
            # Retrieve servicePrincipal sign-in activity from MS Graph
            $currentSpSigninActivity = Get-MgBetaReportServicePrincipalSignInActivity -Filter "AppId eq '$($currentServicePrincipalObject.AppId)'"
            
            # If sign-in activity was found, add it to the cache - else add appId to no-signin-activity list
            if($currentSpSigninActivity) {
                $cacheServicePrincipalSigninActivities += $currentSpSigninActivity
                Write-Host "Found servicePrincipal sign-in activity and added it to cache: $($currentServicePrincipalObject.displayName)"
            }

            else {
                $cacheServicePrincipalsWithoutSigninActivities += $currentServicePrincipalObject.AppId
                Write-Host "Did not find servicePrincipal sign-in activity: $($currentServicePrincipalObject.displayName)"
            }
        }
    }

Compiling the report

And finally we can generate a PSCustomObject with the data we need for the report.

    # Create reporting object
    [PSCustomObject]@{
        ServicePrincipalDisplayName = $currentServicePrincipalObject.DisplayName
        ServicePrincipalId = $currentServicePrincipalObject.Id
        ServicePrincipalType = $currentServicePrincipalObject.ServicePrincipalType
        ServicePrincipalEnabled = $currentServicePrincipalObject.AccountEnabled
        AppId = $currentServicePrincipalObject.AppId
        AppSignInAudience = $currentServicePrincipalObject.SignInAudience
        AppOwnerOrganizationTenantId = $currentServicePrincipalObject.AppOwnerOrganizationId
        AppOwnerOrganizationTenantName = $currentAppOwnerOrgObject.DisplayName
        AppOwnerOrganizationTenantDomain = $currentAppOwnerOrgObject.DefaultDomainName
        Resource = $currentAppRoleAssignedTo.ResourceDisplayName
        AppRole = $currentAppRole.Value
        AppRoleTier = $appRoleTiers["$($currentAppRole.Value)"]
        AppRoleAssignedDate = $(if($currentAppRoleAssignedTo.CreatedDateTime) {(Get-Date $currentAppRoleAssignedTo.CreatedDateTime -Format 'yyyy-MM-dd')})
        AppRoleName = $currentAppRole.DisplayName
        AppRoleDescription = $currentAppRole.Description
        LastSignInActivity = $currentSpSigninActivity.LastSignInActivity.LastSignInDateTime
        DelegatedClientSignInActivity = $currentSpSigninActivity.DelegatedClientSignInActivity.LastSignInDateTime
        DelegatedResourceSignInActivity = $currentSpSigninActivity.DelegatedResourceSignInActivity.LastSignInDateTime
        ApplicationAuthenticationClientSignInActivity = $currentSpSigninActivity.ApplicationAuthenticationClientSignInActivity.LastSignInDateTime
        ApplicationAuthenticationResourceSignInActivity = $currentSpSigninActivity.ApplicationAuthenticationResourceSignInActivity.LastSignInDateTime
    }
}

This will generate a list of all the app role assignments for Microsoft Graph and Azure AD Graph, enriched with additional data for the assigned service principals and any configured tier. Here’s an example.

ServicePrincipalDisplayName                     : az-sp-idw-reporter
ServicePrincipalId                              : 17805a37-7b8f-4319-b3d9-36fa7fd037fc
ServicePrincipalType                            : Application
ServicePrincipalEnabled                         : True
AppId                                           : cafd0954-9d88-4e33-b4ab-6e681ba2f4a4
AppSignInAudience                               : AzureADMyOrg
AppOwnerOrganizationTenantId                    : eeb4b582-c6fd-4cc0-b12f-b2604b111a4b
AppOwnerOrganizationTenantName                  : MyTenant
AppOwnerOrganizationTenantDomain                : mytenant.onmicrosoft.com
Resource                                        : Microsoft Graph
AppRole                                         : User.Read.All
AppRoleTier                                     : 
AppRoleAssignedDate                             : 2022-11-24
AppRoleName                                     : Read all users' full profiles
AppRoleDescription                              : Allows the app to read user profiles without a signed in user.
LastSignInActivity                              : 14.08.2023 21:08:25
DelegatedClientSignInActivity                   : 
DelegatedResourceSignInActivity                 : 
ApplicationAuthenticationClientSignInActivity   : 14.08.2023 21:08:25
ApplicationAuthenticationResourceSignInActivity : 

Full script on GitHub

I like to explain how the Powershell scripts I publish works, and this blog post does just that. I have also published the full Powershell script on GitHub so you don’t have to copy/paste from this page, feel free to check it out.

Thanks for reading!

Be sure to provide any feedback on X (former Twitter) or LinkedIn.

Phishing of user account credentials has been part of the cyber threat landscape for ages. This also goes for MFA phishing, or rather phishing attacks where a threat actor gets away with a valid access token, primary refresh token and session cookies for an Azure AD user account.

Now, how is it even possible to fall victim to a phishing attack when the account is protected by MFA?

Burn the password

Passwords only are bad. Passwords can be intercepted, phished, leaked, guessed, or shared. Single-factor authentication simply is not enough.

Any MFA method is better than none

Some MFA methods are weak and some are strong. But no MFA is always worse than a weak MFA method. Say all you want about false security - I’d go for the weaker MFA method any day of the week if the only option was to have no MFA.

According to Microsoft, a whooping 99% of compromised user accounts were not protected by MFA.

Weak MFA methods

Phone-call and SMS, the weakest form of MFA. This might differ from country to country, but mobile subscriptions can be vulnerable to SIM swapping by attackers which fraudulently takes control of a user’s mobile subscription by persuading their mobile carrier to transfer the phone number to a SIM card in the attacker’s possession. Another possible attack vector is simply put SMS interception - where an attacker catches the SMS contents which is not encrypted.

Strong MFA methods

Nudge users to move away from weak MFA methods and over to Microsoft’s Authenticator app which has has several great security and usability features:

• Number matching
• Additional context
• Passwordless sign-in
• GPS location
• Protect app with pin or biometrics
• Onboard Azure AD accounts directly in the app with Temporary Access Pass
• It’s free and supports iOS and Android

Other strong methods are OATH verification code apps like Google Authenticator, and hardware tokens with OTP. Unfortunately, these are all vulnerable to MFA phishing, including the Microsoft Authenticator app.

Evilginx attack framework

Evilginx is an open-source framework utilized to conduct phishing attacks using man-in-the-middle technics to catch credentials, tokens and cookies. Simply explained, an attacker can set up a phishing site looking like a normal Azure AD sign-in page, then lure users to click a link to the site by using e-mail or other means.

If the user actually do sign-in, the phishing website will look and act like the normal sign-in process. But behind the curtains it will proxy the credentials from the attacker’s webserver directly to Azure AD, triggering MFA prompt which the user might approve, and if they do approve - the access token, primary refresh token and session cookies are issued to the attacker’s server instead of the phished user’s device.

Phishing-resistant MFA methods

This phishing attack works on all types of MFA methods currently supported by Azure AD, except for those methods we call phishing-resistant; Windows Hello for Business, FIDO2 security keys and Certificate-based Authentication (CBA). The reason is that these three authentication methods are securely coupled to Azure AD on a physical device, and cannot be intercepted by an attacker’s webserver as the user have no way of providing these credentials to services that are not Azure AD.

If the user had phishing-resistant MFA when signing in to the phishing site, the attack would stop dead in its tracks.

Obvious solution?

Assign FIDO2 security keys to all users and we’re good to go! Well, unfortunately it might not be that easy after all as adoption takes more effort than for other MFA methods. The keys have a cost, it’s a physical device and requires some form of management and distribution, and Azure AD demands some other valid MFA method when registering a FIDO2 security key on a user’s account. Also, having fallback methods in the case a FIDO2 key is lost might be something to think about.

Windows Hello for Business is a no-brainer, and now it’s even easier to implement. WHfB signs the user in with PIN or biometrics, without a password on the user’s enrolled Windows device, and it’s always regarded as MFA by Azure AD. Say goodbye to MFA prompts and password reset calls.

Conditional Access policies

Another way of protecting users from MFA phishing without phishing-resistant MFA methods, is by using Conditional Access policies. Conditional Access can require hybrid-joined or compliant device for users signing in, effectively blocking users from signing in from unmanaged devices - like an attacker’s phishing website.

If an organization is able to, I would strongly advise to require hybrid-joined or compliant device with CA - as it helps prevent phishing attacks, and also prevents users from connecting to company resources from devices that have an unknown security posture. Windows, MacOS, Linux, iOS and Android are all supported by Intune enrollment. Remember - attackers have gained initial entry to organizations by pivoting from users’ home devices utilized to accessing company resources in several publicly known security breaches.

Secure device enrollment process

Even though Conditional Access policy requires hybrid-joined or compliant device for users, organizations are potentially vulnerable to fraudulent device registration during MFA phishing attacks if users are allowed to enroll devices into Intune. Supporting self-enrollment is of course a great user experience, but it comes with a risk. Allowing an attacker to get a compliant device in Azure AD is definitely very bad.

How about this - only allow Intune enrollment of devices for new hires, so they can get their Windows device installed via Autopilot and their mobile devices enrolled. Remove the access after onboarding has been completed.

To allow enrollment of e.g. new mobile devices in Intune for existing users, set up an access package granting access to this - with or without approval, and with expiration of a few hours.

Least-privilege and just-in-time principals like this can really save the day when (not if) a user in the organization falls victim to a phishing attack.

That’s all for now, thanks for reading!

Be sure to provide any feedback on Twitter, LinkedIn or Mastadon.

One of the principles in zero-trust strategy is specifically least-privilege, which comprises of just-in-time and just-enough-access plus other strategies.

• Just-in-time (JIT)
• Just-enough-access (JEA)
• PIM to the rescue
• Activate eligible role for specific scope in PIM
• Activate eligible role from a resource’s ‘Access control (IAM)’ blade

Just-in-time (JIT)

One of the key features of PIM is just-in-time (JIT) access, which allows users to gain temporary access to a privileged role or resource for a limited amount of time. JIT access minimizes the exposure of sensitive resources and reduces the attack surface by limiting the time window during which a user can access a privileged role or resource.

An example of JIT is requiring developers to elevate into the Key Vault Secrets Officer role when they need to work with secrets, expiring that access within X hours - instead of having standing and active access at persistently.

Just-enough-access (JEA)

JEA, just-enough-access, simply put means having the lowest administrative privileges possible, and access only to resources that are strictly necessary to complete a task. Good for security, but at the same time it’s lowering operational risk as there’s less chance for accidental or intentional changes to be applied to the wrong resources.

Azure AD supports JEA in certain scenarios with the concept of Administrative Units. Azure RBAC also supports JEA, as granular and specific roles can be granted all the way down to a single resource in Azure. The challenge is to not give too broad permissions, especially ones that are not necessary 99% of the time. Granting Contributor role on the tenant root management group is far from JEA, the blast radius is potentially extreme, but may still be required in certain circumstances.

PIM to the rescue

PIM can help out with JEA - while an eligible Azure RBAC role has been granted high up in the hierarchy, the role holder can choose which descendant scope to activate it for. If we’re so “lucky” to have eligible Contributor role on the tenant root management group, effectively granting contributor permissions on all descendent objects once activated, it doesn’t mean we have to activate the role with the full scope on every occasion.

Alternatively we can select a specific descendent management group, subscription or resource group we want to activate the contributor role for as scope in PIM. Which means we can choose our Contributor role on the tenant root management group, but effectively scope it down to a specific descendant resource group. By doing so we’re adhering to the least-privilege and just-enough-access principles by only elevating for what we actually need then and there.

Yes, we might have to “PIM ourselves” a few times more than only once a day, but really - that’s the only drawback. Have to get ourselves a few cups of coffee during the day anyways. While the big advantage is smaller blast radius should something disastrous happen. Think about that for a second.

Activate eligible role for specific scope in PIM

Start by accessing the PIM portal at https://aka.ms/pim:

1. Select the Azure resources blade, click Activate on the role we want to elevate into.
2. Choose duration, type a reason and go to the Scope blade.
3. In the Scope blade, click Select scope, choose Management group, Subscription or Resource group.
4. Search for and select the correct resource to scope the role elevation for, then click Activate.

We’ve now elevated our Contributor role only for the p-plt-idm resource group, instead of for the whole tenant root management group.

We can also do this programatically, but that’ll be saved for another blog post.

Activate eligible role from a resource’s ‘Access control (IAM)’ blade

This feature is brand new, released in March 2023 according to Microsoft’s documentation.

As of March 2023, you may now activate your assignments and view your access directly from blades outside of PIM in the Azure portal. Read more here. Privileged Identity Management role activation has been integrated into the Billing and Access Control (AD) extensions within the Azure portal. Shortcuts to Subscriptions (billing) and Access Control (AD) allow you to activate PIM roles directly from these blades.

1. Go to the Access control (IAM) blade of a resource.
2. Click View my access and go to the Eligible assignments tab.
3. Select the role we want to elevate into, then click Activate role.
4. Choose duration, type a reason and go to the Scope blade.
5. In the Scope blade, click Select scope, choose the correct resource to scope the role elevation for and then click Activate.

Note: This specific functionality seems buggy as of April 4, and I have not been successfull at selecting a descendant resource as scope yet. Microsoft will likely fix this very soon.

This makes it so much easier to elevate into a role for the scope of a resource we’re currently working on, and we don’t even have to visit the PIM portal. Nice!

That’s it for now, thanks for reading!

Be sure to provide any feedback on Twitter, LinkedIn or Mastadon.

• The basics
• Securing the MFA registration process
• No network exceptions
• Block risky identities
• Block unknown devices
• Tweak sign-in frequency and browser session persistence
• Final thoughts

The basics

First - if an organization’s MFA coverage for admin and user identities is below 100%, that’s where to start. All identities used by individuals with a pulse must be secured using MFA - no exceptions. Only requiring passwords in Azure AD really isn’t enough and will eventually cause a disaster.

Securing the MFA registration process

An essential step is to secure the MFA registration process. Users by default have the ability to register MFA methods upon sign-in when triggering MFA requirement - if no current MFA method exists yet for the account. An attacker could potentially sign-in with compromised credentials and enroll MFA right in the Authenticator app - which would definitely be bad.

To prevent this, use Conditional Access policy to secure the MFA registration process by either requiring known/compliant device, or another MFA method like Temporary Access Pass.

No network exceptions

As we keep focusing on Azure AD, require MFA always and from anywhere. Stop excluding MFA from known and “trusted” office networks. Seriously, the internal networks can’t be trusted anymore, it’s 2023 and we need to assume breach, never trust and always explicitly verify! If an attacker already is on the inside, excluding MFA from that network is just helping them potentially compromise the organization’s cloud resources too.

From Azure AD’s perspective, all networks should be treated as the rest of the Internet. Full zero trust.

Block risky identities

Protect Azure AD user accounts further with Identity Protection signals and Conditional Access policies. Block high-risk sign-ins and users - especially if a SOC is present and can act on such events to investigate and quickly remediate both for the sake of security and user productivity.

Medium-risk sign-ins could trigger full re-authentication with MFA, and medium-risk users could trigger full re-authentication with secure password-change through self-service password reset. This would assist users in helping themselves to get out of a potentially bad situation.

Block unknown devices

Going further it’s important to bring in device status. Which device is the user logging in from, is it known to Azure AD either as an Azure AD-joined or registered device, or as a hybrid-joined device for those organizations with AD domain-joined computers. In case of Azure AD-joined or registered device - is it in compliance with the implemented security policies in Intune?

Using Conditional Access policies to block sign-ins from unknown or non-compliant devices might be the protection mechanism fending off an actual ongoing phishing attack at the very last minute. As long as users are allowed to utilize phishable MFA methods like SMS, phone call, OTP and even Microsoft Authenticator - they are at risk to be lured into giving up both their account credentials and MFA challenge on a phishing site running Evilginx2 (as showcased by @janbakker_) or similar tool.

With this Conditional Access policy in place the attacker would be stopped dead in its tracks when signing in with the phished credentials, as the known device requirement can’t be satisfied.

Tweak sign-in frequency and browser session persistence

Deviation from the default sign-in frequency for standard users, which is a rolling window of 90 days, is likely not a good strategy for managed devices in the organization. It may impact user productivity, and will likely annoy users more than securing them.

However, in certain scenarios for specific personas it makes sense to both configure sign-in frequency to a day or less - and to disallow persistent browser session in one go:

• Highly privileged user accounts.
• Users accessing apps from unmanaged devices.

Make sure to understand how these features work by looking at Microsoft’s documentation.

Implement phishing-resistant MFA

Lastly, look into transitioning over to phishing-resistant MFA methods. High-value targets like privileged users and VIPs should be required to use FIDO2 security keys, but it’s even more important to require FIDO2 for any user excluded in the known device Conditional Access policy - as they are much more susceptible at being successfully compromised in a phishing attack.

Final thoughts

There are of course many other measures to consider and features to implement for protecting user identities. Some important things comes to mind, especially within endpoint management, like prevent giving users local admin privileges by default on their computers and instead look into Endpoint Privilege Management, make sure to use all the goodies in Windows like Defender for Endpoint and Credential Guard, look into issuing privileged and secure access workstation for high-impact users, and more.

While we’re talking about Conditional Access policies, I highly recommend looking into Microsoft’s articles on Conditional Access for zero trust - and also this GitHub repo by @claus_jespersen.

That’s it for now, thanks for reading - and keep on securing those identities!

Be sure to provide any feedback on Twitter, LinkedIn or Mastadon.

In this blogpost I will showcase how to gather data from various sources and compile it all into an actionable status report. Since different tenants have different needs and ways of working, I’m providing examples so that you can write your own custom-tailored script.

The report will list the following records:

1. Users with eligible or active Azure AD admin roles - including details on last role activation date, role assignment and expiration dates, MFA status and last sign-in date, admin owner account status etc.
2. Service Principals / Applications and Managed Identities with active Azure AD admin roles - including details on last authentication date, tenant ownership, etc.
3. Role-assignable groups with eligible or active Azure AD admin roles

Note: Role-assignable groups granted one or more Azure AD admin roles will be listed in the report but users with active or eligible membership to such groups will currently not be listed.

See the Report examples chapter for details.

• Prerequisites
• Connecting to Graph and Log Analytics
• Extracting data
  • MFA registration details
  • Role assignments
  • Principal last sign-in date
  • Eligible role last activation date
  • Default MFA method and capability
  • Admin account owner
  • Service Principal owner organization
• Compiling the report
  • Report examples
  • Example script

Prerequisites

These Powershell modules are required:

• Graph Powershell SDK
• Azure Powershell

Other prerequisites:

• Global Reader role (or other AAD roles granting enough read-access)
• Admin consent to any required non-consented Graph scopes (read-only) in Graph Powershell SDK.
• Reader-role on the Log Analytics workspace where the Azure AD Sign-in and Audit logs are exported.

Connecting to Graph and Log Analytics

Connect to Graph with the Graph Powershell SDK using the required read-only scopes, and select the beta endpoint as required by some of the cmdlets:

Connect-MgGraph -Scopes RoleEligibilitySchedule.Read.Directory, RoleAssignmentSchedule.Read.Directory, CrossTenantInformation.ReadBasic.All, AuditLog.Read.All, User.Read.All
Select-MgProfile -Name Beta

Then connect to Azure with the Azure Powershell module, for running KQL queries on the Log Analytics workspace data. Read my Query Azure AD logs with KQL from Powershell blogpost for more information on running KQL queries in Powershell. Update the various parameters according to your environment.

Connect-AzAccount
Set-AzContext -Subscription "my-subscription"
$workspaceName = "p-aadlogs-loganalyticsworkspace"
$workspaceRG = "p-aadlogs-loganalytics"
$workspaceID = (Get-AzOperationalInsightsWorkspace -Name $workspaceName -ResourceGroupName $workspaceRG).CustomerID

Extracting data

We need to extract data from various sources using Microsoft Graph and KQL queries in Log Analytics.

MFA registration details

To report on MFA registration details for Azure AD admin role holders it is likely most efficient to extract all registration details and create a hashtable for quick lookup, depending on the number of users in the tenant.

# Get MFA registration details
# Graph API: https://graph.microsoft.com/beta/reports/authenticationMethods/userRegistrationDetails
Write-Host -ForegroundColor Yellow "Fetching MFA registration details report"
$mfaRegistrationDetails = Get-MgReportAuthenticationMethodUserRegistrationDetail -All:$true
$mfaRegistrationDetailsHashmap = $mfaRegistrationDetails | Group-Object -Property Id -AsHashTable
Write-Host -ForegroundColor Yellow "Found $($mfaRegistrationDetails.count) MFA registration detail records"

Role assignments

Assigned roles are active role assignments. This query will also return eligible role assignments which are currently activated through PIM, so we’ll filter those out as they will just be duplicates in the report as they are also listed as eligible roles.

# Get assigned role assignments
Write-Host -ForegroundColor Yellow "Fetching assigned role assignments, might take a minute..."
$assignedRoleAssignments = Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance -ExpandProperty "*" -All:$true
$activatedRoleAssignments = $assignedRoleAssignments | Where-Object { $_.AssignmentType -eq 'Activated' }
$filteredAssignedRoleAssignments = $assignedRoleAssignments | Where-Object { $_.AssignmentType -eq 'Assigned' }
Write-Host -ForegroundColor Yellow "Found $($filteredAssignedRoleAssignments.count) assigned role assignments"

Eligible roles are role assignments requiring activation in PIM.

# Get eligible role assignments
Write-Host -ForegroundColor Yellow "Fetching eligible role assignments, might take a minute..."
$eligibleRoleAssignments = Get-MgRoleManagementDirectoryRoleEligibilitySchedule -ExpandProperty "*" -All:$true
Write-Host -ForegroundColor Yellow "Found $($eligibleRoleAssignments.count) eligible PIM role assignments, whereof $($activatedRoleAssignments.count) are activated"

Then we combine the two assignment types into one array. Use the Select-Object cmdlet to pick out a few records while developing and testing the script.

# Combine assignments
$allRoleAssignments = @(
    $eligibleRoleAssignments #| Select-Object -First 10
    $filteredAssignedRoleAssignments #| Select-Object -First 10
)

Now we have all the assignment objects we need in the $allRoleAssignments array, and will process each of those objects in a foreach loop to fetch other necessary data. In the following examples I’ve populated the $roleObject variable with one object from the $allRoleAssignments array.

Since the $allRoleAssignments array may contain both users and Service Principals with active or eligible role assignments, the $roleObject.Principal.AdditionalProperties.'@odata.type property will tell which principal type the current object is - either '#microsoft.graph.user or #microsoft.graph.servicePrincipal. And for Service Principals we can differentiate on types in the $roleObject.Principal.AdditionalProperties.servicePrincipalType property - which is either Application or ManagedIdentity.

Principal last sign-in date

The quickest way to get an Azure AD user’s last sign-in date is to query Graph for the user and selecting signInActivity.

$principalLastSignIn = $null
$principalSignInActivity = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/users/$($roleObject.Principal.Id)?`$select=id,userPrincipalName,userType,signInActivity"
if($principalSignInActivity) {
    if($principalSignInActivity.signInActivity.lastSignInDateTime -gt $principalSignInActivity.signInActivity.lastNonInteractiveSignInDateTime) {
        $principalLastSignIn = $principalSignInActivity.signInActivity.lastSignInDateTime
    } else { $principalLastSignIn = $principalSignInActivity.signInActivity.lastNonInteractiveSignInDateTime }
}

For Service Principals we need to query the Azure AD logs in Log Analytics with KQL to fetch the date when the Service Principal last signed in.

KQL query for Service Principal of type Application:

# KQL query for SP last sign-in
$principalLastSignIn = $null
$query = "AADServicePrincipalSignInLogs
| where ResultType == '0'
| where TimeGenerated > ago(90d)
| where AppId == '$($roleObject.Principal.AdditionalProperties.appId)'
| sort by TimeGenerated desc
| limit 1"

$kqlQuery = Invoke-AzOperationalInsightsQuery -WorkspaceId $WorkspaceID -Query $query
$principalLastSignIn = $kqlQuery.Results.TimeGenerated

KQL query for Service Principals of type ManagedIdentity:

# KQL query for MSI last sign-in
$principalLastSignIn = $null
$query = "AADManagedIdentitySignInLogs
| where ResultType == '0'
| where TimeGenerated > ago(90d)
| where AppId == '$($roleObject.Principal.AdditionalProperties.appId)'
| sort by TimeGenerated desc
| limit 1"

$kqlQuery = Invoke-AzOperationalInsightsQuery -WorkspaceId $WorkspaceID -Query $query
$principalLastSignIn = $kqlQuery.Results.TimeGenerated

Eligible role last activation date

We also need to fetch the latest date of eligible role activations for users. If $roleObject.AssignmentType equals null and the principal is a user, the following KQL query can help out:

# KQL query for last PIM role activation
$eligibleRoleLastActivated = $null
$query = "AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName == 'Add member to role completed (PIM activation)'
| where Result == 'success'
| where InitiatedBy.user.id == '$($roleObject.Principal.Id)'
| where TargetResources[0].id == '$($roleObject.RoleDefinition.Id)'
| sort by TimeGenerated desc
| limit 1"

$kqlQuery = Invoke-AzOperationalInsightsQuery -WorkspaceId $WorkspaceID -Query $query
$eligibleRoleLastActivated = $kqlQuery.Results.TimeGenerated

Default MFA method and capability

Users with administrative roles and no registered MFA method can be a security risk, depending on tenant configuration and conditional access policies. It’s best to avoid it - while also report on the default type of MFA methods active role assignees have. We already have the $mfaRegistrationDetailsHashmap hashtable and can query it for each processed role where the principal is a user.

# Fetch default MFA method and cabability
$mfaCapable = $false
$mfaDefaultMethod = $null
if($mfaRegistrationDetailsHashmap.ContainsKey("$($roleObject.Principal.Id)")) {
    $mfaCapable = $mfaRegistrationDetailsHashmap["$($roleObject.Principal.Id)"].IsMfaCapable
    $mfaDefaultMethod = $mfaRegistrationDetailsHashmap["$($roleObject.Principal.Id)"].AdditionalProperties.defaultMfaMethod
}

Admin account owner

If you’re following Microsoft best-practises and separating normal user accounts from administrative roles, you should be having a separate admin account for each user who requires privileged roles and access.

When having separate admin accounts it’s also important to check account status of the admin account owners if possible - to make sure that all admin accounts of terminated employees have been disabled and/or deleted. This query will depend on how you identify admin account owners in your tenant, the following example extracts the owner’s accountName from the UPN and queries Graph for any user with that onPremisesSamAccountName + employeeId.

# Fetch admin account owner
$adminAccountOwner = $null
if($roleObject.Principal.AdditionalProperties.userPrincipalName -like 'admin-*@<tenant>.onmicrosoft.com') {
    $adminAccountOwnerAccountName = $roleObject.Principal.AdditionalProperties.userPrincipalName -replace "@<tenant>.onmicrosoft.com","" -replace "admin-",""
    $adminAccountOwner = Get-MgUser -Filter "onPremisesSamAccountName eq '$($adminAccountOwnerAccountName)' and employeeId eq '$($roleObject.Principal.AdditionalProperties.employeeId)'" -ConsistencyLevel "eventual" -CountVariable counter -Select "id,userPrincipalName,displayName,onPremisesSamAccountName,employeeId,companyName,department,accountEnabled,signInActivity"
}

Service Principal owner organization

Service Principals of multi-tenant app registrations can be owned by other Azure AD tenants and consented to in your tenant. It’s important to know about these and understand why they have privileged roles.

If $roleObject.Principal.AdditionalProperties.appOwnerOrganizationId is not null, query Graph for the tenant properties of the owner organization.

$spOwnerOrg = $null
$spOwnerOrg = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/tenantRelationships/findTenantInformationByTenantId(tenantId='$($roleObject.Principal.AdditionalProperties.appOwnerOrganizationId)')"

$spOwnerOrg.displayName will contain the tenant organization name, and $spOwnerOrg.defaultDomainName the tenant’s default domain’, which can provide a better clue of what the Service Principal is used for and by whom.

Note: Know 100% what you’re doing before removing any privileged roles from Service Principals, especially from Microsoft-owned apps which likely have the roles for a very good reason.

That’s about it, we now have the data necessary to compile an actionable status report on all active and eligible Azure AD role assignments.

Compiling the report

We can now construct a PSCustomObject per role assignment with the collected data.

[PSCustomObject]@{
    'PIM-role last activated' = $eligibleRoleLastActivated
    'Principal Type' = switch ($roleObject.Principal.AdditionalProperties.'@odata.type') {
        '#microsoft.graph.user' { "User" }
        '#microsoft.graph.servicePrincipal' { $roleObject.Principal.AdditionalProperties.servicePrincipalType }
        '#microsoft.graph.group' { "RoleAssignableGroup" }
    }
    'Principal User Type' = $principalSignInActivity.userType
    'Principal Created' = $roleObject.Principal.AdditionalProperties.createdDateTime
    'Principal AD Synced' = $roleObject.Principal.AdditionalProperties.onPremisesSyncEnabled -eq $true
    'Principal Enabled' = $roleObject.Principal.AdditionalProperties.accountEnabled
    'Principal Last SignIn' = $principalLastSignIn
    'Principal DisplayName' = $roleObject.Principal.AdditionalProperties.displayName
    'Principal UPN / AppId' = switch ($roleObject.Principal.AdditionalProperties.'@odata.type') {
        '#microsoft.graph.user' { $roleObject.Principal.AdditionalProperties.userPrincipalName }
        '#microsoft.graph.servicePrincipal' { $roleObject.Principal.AdditionalProperties.appId }
        '#microsoft.graph.group' { "" }
    }
    'Principal Object ID' = $roleObject.Principal.Id
    'Principal Owner' = $spOwnerOrg.displayName + " ($($spOwnerOrg.defaultDomainName))"
    'MFA Capable' = $mfaCapable
    'MFA Default Method' = $mfaDefaultMethod
    'Member Type' = $roleObject.MemberType
    'Assignment Type' = if($roleObject.AssignmentType) { $roleObject.AssignmentType } else { "Eligible" }
    'Directory Scope' = $roleObject.DirectoryScopeId
    'Assigned Role' = $roleObject.roleDefinition.DisplayName
    'Assignment Start Date' = if($roleObject.StartDateTime) { $roleObject.StartDateTime } elseif ($roleObject.scheduleInfo.startDateTime) { $roleObject.scheduleInfo.startDateTime }
    'Assignment End Date' = if($roleObject.EndDateTime) { $roleObject.EndDateTime } elseif ($roleObject.scheduleInfo.expiration.endDateTime) { $roleObject.scheduleInfo.expiration.endDateTime }
    'Has End Date' = $roleObject.EndDateTime -or $roleObject.scheduleInfo.expiration.endDateTime
    'Custom Role' = -not $roleObject.RoleDefinition.IsBuiltIn
    'Role Template' = $roleObject.RoleDefinition.TemplateId
    'AdminOwner Company' = $adminAccountOwner.CompanyName
    'AdminOwner Department' = $adminAccountOwner.Department
    'AdminOwner Name' = $adminAccountOwner.DisplayName
    'AdminOwner UPN' = $adminAccountOwner.UserPrincipalName
    'AdminOwner AccountName' = $adminAccountOwner.OnPremisesSamAccountName
    'AdminOwner EmployeeId' = $adminAccountOwner.EmployeeId
    'AdminOwner Enabled' = $adminAccountOwner.AccountEnabled
    'AdminOwner LastSignIn' = if($adminAccountOwner.SignInActivity) {
        if($adminAccountOwner.SignInActivity.lastSignInDateTime -gt $adminAccountOwner.SignInActivity.lastNonInteractiveSignInDateTime) {
            $adminAccountOwner.SignInActivity.lastSignInDateTime
        } else { $adminAccountOwner.SignInActivity.lastNonInteractiveSignInDateTime }
    }
}

Report examples

User with eligible role assignment:

PIM-role last activated    : 2022-08-24T09:24:20.549Z
Principal Type             : User
Principal User Type        : Member
Principal Created          : 2022-05-11T10:19:28Z
Principal AD Synced        : False
Principal Enabled          : True
Principal Last SignIn      : 18.09.2022 10:49:55
Principal DisplayName      : Adele Vance
Principal UPN / AppId      : AdeleV@tenant.onmicrosoft.com
Principal Object ID        : 806fd75c-2147-40d7-9366-1e3e73d5677b
MFA Capable                : True
MFA Default Method         : microsoftAuthenticatorPush
Member Type                : Direct
Assignment Type            : Eligible
Directory Scope            : /administrativeUnits/bbf65f2a-df92-4e28-8991-555360fa6c98
Assigned Role              : User Administrator
Assignment Start Date      : 23.08.2022 14:07:23
Assignment End Date        : 23.08.2023 14:07:07
Has End Date               : True
Custom Role                : False
Role Template              : fe930be7-5e62-47db-91af-98c3a49a38b1

User with active role assignment and owner account details:

Principal Type             : User
Principal User Type        : Member
Principal Created          : 2022-06-14T19:27:21Z
Principal AD Synced        : False
Principal Enabled          : False
Principal Last SignIn      : 17.09.2022 09:37:23
Principal DisplayName      : AdeleV (Admin)
Principal UPN / AppId      : admin-adelev@tenant.onmicrosoft.com
Principal Object ID        : 416e9dc4-9c8d-44ce-8938-1fd9b92334a4
MFA Capable                : True
MFA Default Method         : microsoftAuthenticatorPush
Member Type                : Direct
Assignment Type            : Assigned
Directory Scope            : /
Assigned Role              : Group Creator
Assignment Start Date      : 24.08.2022 09:19:28
Assignment End Date        : 20.02.2023 09:19:13
Has End Date               : True
Custom Role                : True
Role Template              : 8ae1d011-0ae3-4cdf-b6c2-d6fb5cae8254
AdminOwner Company         : Some Company Ltd
AdminOwner Department      : IT
AdminOwner Name            : Adele Vance
AdminOwner UPN             : AdeleV@tenant.onmicrosoft.com
AdminOwner EmployeeId      : 123456
AdminOwner Enabled         : True
AdminOwner LastSignIn      : 18.09.2022 10:49:55

Service Principal with role assignment:

Principal Type             : Application
Principal Created          : 2022-05-19T11:57:00Z
Principal AD Synced        : False
Principal Enabled          : True
Principal Last SignIn      : 
Principal DisplayName      : Microsoft.Azure.SyncFabric
Principal UPN / AppId      : 00000014-0000-0000-c000-000000000000
Principal Object ID        : 80faa33c-6cbd-42e5-bb62-4bbd0370351c
Principal Owner            : Microsoft Services (sharepoint.com)
Member Type                : Direct
Assignment Type            : Assigned
Directory Scope            : /
Assigned Role              : Directory Readers
Assignment Start Date      : 
Assignment End Date        : 
Has End Date               : False
Custom Role                : False
Role Template              : 88d8e3e3-8f55-4a1e-953a-9b9898b8876b

Managed Identity with role assignment:

Principal Type             : ManagedIdentity
Principal Created          : 2022-06-14T00:03:31Z
Principal AD Synced        : False
Principal Enabled          : True
Principal Last SignIn      : 2022-08-23T11:55:41.73434Z
Principal DisplayName      : test-azrole-grant
Principal UPN / AppId      : 74d64966-c87a-4a4c-a372-fe446b9087ec
Principal Object ID        : e84f76b5-753a-4035-8d1e-c0de1d0686f7
Member Type                : Direct
Assignment Type            : Assigned
Directory Scope            : /
Assigned Role              : Directory Readers
Assignment Start Date      : 19.08.2022 11:09:05
Assignment End Date        : 15.02.2023 11:08:51
Has End Date               : True
Custom Role                : False
Role Template              : 88d8e3e3-8f55-4a1e-953a-9b9898b8876b

Role-assignable group with role assignment:

Principal Type             : RoleAssignableGroup
Principal Created          : 2022-08-22T14:08:36Z
Principal AD Synced        : False
Principal DisplayName      : AAD-role PIM: Group Creator
Principal Object ID        : 6a2640b6-df72-4333-a15a-a1dc2056cf77
Member Type                : Direct
Assignment Type            : Assigned
Directory Scope            : /
Assigned Role              : Group Creator
Assignment Start Date      : 
Assignment End Date        : 
Has End Date               : False
Custom Role                : True
Role Template              : 8ae1d011-0ae3-4cdf-b6c2-d6fb5cae8254

Example script

In case you need more tips on creating a reporting powershell script for this report, take a look at the example script I’ve published on GitHub.

Thanks for reading!

Be sure to provide any feedback on Twitter or LinkedIn.

• Who deleted a specific user.
• How often is a user elevating into an Azure AD administrative role in PIM.
• When was a user added to or removed from a specific Azure AD security group.

Since logs in Azure AD are usually deleted after 7-30 days depending on tenant licensing, it’s important to export these logs to a Log Analytics workspace for safekeeping. If the logs aren’t exported, there is no way to retrieve them back once they are deleted. You never know when you need to figure out when something happened and who or what actually did it, so having the logs available is key both for security and compliance.

To learn more about KQL I highly recommend KQL for Microsoft Sentinel by Matt Zorich (@reprise_99), and Must Learn KQL by Rod Trent (@rodtrent).

So, let’s get set up for running KQL queries in Powershell.

• Verify Azure AD diagnostic settings for log export
• Query log analytics from the Azure AD portal
• Query log analytics from Powershell

Verify Azure AD diagnostic settings for log export

Check if the Azure AD tenant is already exporting logs by visiting the Diagnostic settings blade in the Azure AD portal, any attached Log Analytics workspace will be displayed.

If the Azure AD tenant isn’t currently exporting logs to a Log Analytics workspace, see Microsoft’s documentation on how to get started:

• Create a Log Analytics workspace
• Integrate Azure AD logs with Azure Monitor logs

Query log analytics from the Azure AD portal

Go to the Log Analytics blade within the Azure AD portal, you will need Reader role on the Log Analytics workspace to query the data.

In the query box, input the following KQL and click Run:

SigninLogs
| where ResultType == 0
| where TimeGenerated > ago(1d)
| where AppDisplayName has "Azure Portal"

The results should show all successfull Azure portal sign-ins logged the last 24 hours. Not the most interesting query, but the point is just to show that it works.

Using the Log Analytics blade within the Azure AD portal grants quick and easy access to log data, and allows you to play around with queries. But also note that with exported Azure AD log data available in a Log Anayltics workspace, the built-in workbooks in the Azure AD portal will also light up. These are great for checking things like legacy authentication sign-ins, access package activities, conditional access gaps, provisioning analysis and more. Be sure to give them a run!

Query log analytics from Powershell

I’ve started using KQL queries in Powershell automation, especially for auditing and reporting scripts. An example is to discover when a specific user last activated their Azure AD administrative role in PIM - which isn’t easily available data without the exported Azure AD logs.

To run KQL queries on Azure AD logs in the Log Analytics workspace, make sure Azure Powershell module is installed. Then it’s just a matter of scripting the rest.

Add the correct subscription, log analytics workspace name and workspace resource group to connect with Powershell:

# Connect to Azure for Log Analytics
Connect-AzAccount
Set-AzContext -Subscription "my-sub"
$workspaceName = "vl-loganalytics-workspace"
$workspaceRG = "vl-loganalytics"
$WorkspaceID = (Get-AzOperationalInsightsWorkspace -Name $workspaceName -ResourceGroupName $workspaceRG).CustomerID

After a successful connection, it’s time to run a KQL query. The following query will return the latest Azure AD audit log record for when a specific user objectId last activated their eligible Global Reader role in PIM, which is the role definition id f2ef992c-3afb-46b9-b7cf-a126ee74c451. All Azure AD administrative roles with IDs are listed on Microsoft docs. The TimeGenerated property can be set to the number of days you want to check for backwards in time.

# Query user's last PIM role activation for 'Global Reader' (role definition id: f2ef992c-3afb-46b9-b7cf-a126ee74c451)
$query = "AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName == 'Add member to role completed (PIM activation)'
| where Result == 'success'
| where InitiatedBy.user.id == '8b51737b-f961-41b0-ade7-6e59c77d6e62'
| where TargetResources[0].id == 'f2ef992c-3afb-46b9-b7cf-a126ee74c451'
| sort by TimeGenerated desc
| limit 1"

$kqlQuery = Invoke-AzOperationalInsightsQuery -WorkspaceId $WorkspaceID -Query $query
$kqlQuery.Results.TimeGenerated

The output will either be null if a record wasn’t found, or the dateTime of the user’s latest Global Reader role activation. $kqlQuery.Results will contain the full log entry.

The idea behind this KQL query is to report on users with eligible Azure AD administrative roles never being activated in PIM. Why have an eligible role if it’s not being used, right? Anyways, this was just to get you started with KQL for extracting Azure AD log data. Dive into the links I posted at the start of the blogpost to learn more, thanks for reading!

Be sure to provide any feedback on Twitter or LinkedIn.

The modern way of connecting programmatically is via Microsoft Graph. By assigning Graph permission scopes to workload identities, you can grant access like send email, read and/or write email, calendar, contacts etc. However, assigning these permission scopes means that the workload identity receives permissions to all mailbox resources in the organization, which is far from least-privilege.

To circumvent this and scope permissions down to one or a few specific mailboxes, set up an application access policy in Exchange Online. The supported Graph permission scopes for this policy is:

• Mail.Read
• Mail.ReadBasic
• Mail.ReadBasic.All
• Mail.ReadWrite
• Mail.Send
• MailboxSettings.Read
• MailboxSettings.ReadWrite
• Calendars.Read
• Calendars.ReadWrite
• Contacts.Read
• Contacts.ReadWrite

Let’s look at how to set this up.

• The scenario
• Create a Logic App and grant Graph application scope
• Create a shared mailbox and a mail-enabled security group
• Create the application access policy in Exchange Online
• Configure the Logic App to send mail

The scenario

To showcase this policy, we will create a scheduled Logic App which will send mail via Microsoft Graph. The Logic App authenticates to Graph using a managed identity. The policy will allow the Logic App to send mail from a specific shared mailbox, but not from other mailboxes in the organization.

We will need the following resources:

• A shared mailbox which the Logic App will send mail from.
• A mail-enabled security group. This group will contain mailbox objects that the policy will scope down access to.
• A Logic App with a system assigned managed identity.

Create a Logic App and grant Graph application scope

Create a consumption-based Logic App with a HTTP or recurrence trigger, enable system assigned managed identity from the Identity blade. Make a note of the Object (principal) ID as we will need it for later.

Once the managed identity has been created, we need to grant it the Send.Mail application scope in Microsoft Graph in order to allow it to send mail via Graph. This can be completed using the Microsoft Graph Powershell SDK, or by using the AzureAD Powershell module.

Note: As already mentioned, granting Send.Mail application scope to a workload identity allows it to send mail as anyone in the organization, which is why it is important to scope down the access with an Exchange Online policy. This is also true for any other mailbox application scope permissions in Graph.

In the script below, make sure to add the correct Object (principal) ID as noted down earlier for the managed identity.

Granting Mail.Send application scope with Microsoft Graph Powershell SDK:

# Add the correct 'Object (principal) ID' for the Managed Identity
$servicePrincipalObjectId  = "15ca046b-ee0f-426e-858e-949b5f826596"

# Add the correct Graph scope to grant
$graphScope = "Mail.Send"

Connect-MgGraph -Scope AppRoleAssignment.ReadWrite.All
$graph = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
$graphAppRole = $graph.AppRoles | ? Value -eq $graphScope

$appRoleAssignment = @{
    "principalId" = $servicePrincipalObjectId
    "resourceId"  = $graph.Id
    "appRoleId"   = $graphAppRole.Id
}

New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $servicePrincipalObjectId -BodyParameter $appRoleAssignment | Format-List 

If you want to use the AzureAD Powershell Module instead:

# Add the correct 'Object (principal) ID' for the Managed Identity
$servicePrincipalObjectId  = "15ca046b-ee0f-426e-858e-949b5f826596"

# Add the correct Graph scope to grant
$graphScope = "Mail.Send"

Connect-AzureAD
$graph = Get-AzureADServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" 
$graphAppRole = $graph.AppRoles | ? Value -eq $graphScope
New-AzureADServiceAppRoleAssignment -Id $graphAppRole.Id -PrincipalId $servicePrincipalObjectId -ResourceId $graph.ObjectId -ObjectID $servicePrincipalObjectId 

Create a shared mailbox and a mail-enabled security group

Using Azure Cloud Shell, it’s easy and quick to connect to Azure and Exchange Online with Powershell. The following Powershell code will create a shared mailbox, a mail-enabled security group, and add the shared mailbox as a member in the mail-enabled security group. The group is required when creating the Exchange Online policy later.

Edit the configuration in the script to set correct names and email addresses for the objects.

# Mailbox and group configuration
$sharedMailboxName = "Logic App Notifications"
$sharedMailboxEmail = "la-notifications@tenant.onmicrosoft.com"
$mailSecurityGroupName = "DL Graph Scope Group WL Mailsender LogicApp"
$mailSecurityGroupEmail = "dl-graphscopegroup-wl-mailsender-la@tenant.onmicrosoft.com"

# Connect to EXO
Connect-ExchangeOnline

# Create shared mailbox
$sharedMailboxObject = New-Mailbox -Shared -Name $sharedMailboxName -DisplayName $sharedMailboxName -Alias ($sharedMailboxName.Replace(' ','')) -PrimarySmtpAddress $sharedMailboxEmail

# Create mail-enabled security group
$mailSecurityGroupObject = New-DistributionGroup -Name $mailSecurityGroupName -Alias ($mailSecurityGroupName.Replace(' ','')) -Type Security -PrimarySmtpAddress $mailSecurityGroupEmail

# Add the shared mailbox as member of the group
Add-DistributionGroupMember -Identity $mailSecurityGroupObject.Identity -Member $sharedMailboxObject.Identity

# Output to console
$sharedMailboxObject | Select-Object -Property ExternalDirectoryObjectId
$mailSecurityGroupObject | Select-Object -Property PrimarySmtpAddress 

Make a note of the ExternalDirectoryObjectId of the shared mailbox, and the PrimarySmtpAddress for the mail-enabled security group as we need those values for later. ExternalDirectoryObjectId of the shared mailbox is needed in the Logic App when sending mail via Graph, and PrimarySmtpAddress for the mail-enabled security group is needed when creating the policy in Exchange Online.

Create the application access policy in Exchange Online

The following Powershell code will create a new application access policy in Exchange Online. The policy will be scoped to the mail-enabled security group created earlier, and targeted to the Logic App’s managed identity.

Note: It is the actual app id of the service principal, and not the object (Principal) id which must be targeted for the policy to work. This is why the Powershell code looks up the service principal object.

In the script below, make sure to add the correct Object (principal) ID as noted down earlier for the managed identity. It requires an Exchange Online Powershell session, use Azure Cloud Shell for easy access.

# Policy configuration
$servicePrincipalObjectId = "15ca046b-ee0f-426e-858e-949b5f826596"
$mailSecurityGroupAddress =  "dl-graphscopegroup-wl-mailsender-la@tenant.onmicrosoft.com"
$policyDescription = "Restrict this app's permissions to members of distribution group $($mailSecurityGroupAddress)"

# Fetch Service Principal object
$servicePrincipalObject = Get-AzADServicePrincipal -ObjectId $servicePrincipalObjectId
New-ApplicationAccessPolicy -AppId $servicePrincipalObject.AppId -PolicyScopeGroupId $mailSecurityGroupAddress -AccessRight RestrictAccess -Description $policyDescription

Everything is now set up in Exchange Online. According to this article on Microsoft Docs it can take more than one hour for the policy to become effective. While waiting you can run the following Powershell code to test the policy to see that it should work according to plan, AppId is the managed identity’s app id, and Identity is the mail address for a mailbox which is in the scoped mail-enabled security group created earlier.

Test-ApplicationAccessPolicy -Identity "la-notifications@tenant.onmicrosoft.com" -AppId $servicePrincipalObject.AppId 

In the output, AccessCheckResult should be Granted.

If you now change Identity to a mailbox which is not in the scoped mail-enabled security group, the output for AccessCheckResult should be Denied. As expected, the policy only grants access to the managed identity for the shared mailbox already in the scoped mail-enabled security group, and not for some other mailbox in the organization.

Configure the Logic App to send mail

After you have waited a few hours for the Exchange Online policy to start working, go to the Logic App designer and create a new action workflow step:

• Operation: HTTP
• Method: POST
• URI: https://graph.microsoft.com/v1.0/users/<shared mailbox object id>/sendMail
• Add new parameter: Authentication
• Authentication type: Managed identity
• Managed identity: System-assigned managed identity
• Audience: https://graph.microsoft.com

Set the correct shared mailbox ObjectId, as noted down earlier, in the URI address. This is the mailbox that mail via Graph will be sent from.

Then add the following contents to Body, make sure to set the correct recipient address etc:

{
  "message": {
    "subject": "Graph test mail",
    "body": {
      "contentType": "Text",
      "content": "Does this work?"
    },
    "toRecipients": [
      {
        "emailAddress": {
          "address": "admin@tenant.onmicrosoft.com"
        }
      }
    ]
  },
  "saveToSentItems": "false"
}

It should look like this:

Save the Logic App and run it. The expected result from the HTTP action workflow step should be status code 202 Accepted. This means that the operation was allowed and the mail should be received in the mailbox of the user it was sent to.

Now, by changing the ObjectID in the URI to an id for a mailbox user which is not a member of the mail-enabled security group scoped in the Exchange Online policy, saving and running the Logic App again, the expected result from the HTTP action workflow step should be status code 403 Forbidden.

{
  "error": {
    "code": "ErrorAccessDenied",
    "message": "Access to OData is disabled."
  }
}

This means the Exchange Online policy works, as it only allows the managed identity to send mail via Graph as a mailbox which is a member of the scoped mail-enabled security group.

Now you know how to scope Graph mailbox permissions for workload identities down to specific mailboxes, thanks for reading!

Be sure to provide any feedback on Twitter or LinkedIn.