Is there a way to tell PIM activation from user added permanently to role?

[scorgatelli]

I cannot find a way to distinguish between PIM activations of a previously assigned eligible role and a user being assigned a permanently active role for the following events:

• User Assigned Privileged Role
• User Added to Admin Role
• User added to Azure Active Directory Privileged Groups

In either case (either PIM activation or user permanently added as active) the initiator is always reported as MS-PIM.

My goal is to have incidents created for any new role assignments (either active or eligible), but not for PIM activations (or at least have a different event type to easily distinguish them). Is there any way to accomplish this?

Thank you!

[github-actions]

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

[v-rbajaj]

Hi @scorgatelli, we do have similar analytical rules, are you looking for something like these?
https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Azure%20Active%20Directory/Analytic%20Rules/PrivlegedRoleAssignedOutsidePIM.yaml
https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Azure%20Active%20Directory/Analytic%20Rules/UserAssignedPrivilegedRole.yaml
https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Azure%20Active%20Directory/Analytic%20Rules/PIMElevationRequestRejected.yaml

[scorgatelli]

There are problems with each of these for my use case (I do have them all enabled):

• Privileged Role Assigned Outside PIM - This would be useful, but I have never seen this alert, so I don't know what the trigger would be. It is definitely not triggered when I manually assign a user to an active role (as opposed to eligible).
• User Assigned Privileged Role - I'm currently using this rule. The problem is that all role assignments appear to be initiated by PIM so I cannot tell if it was a PIM activation of a previously assigned eligible role or a new active role assignment without digging into the logs for each alert.
• PIM Elevation Request Rejected - This is a useful rule, but doesn't solve my use case (being able to differentiate PIM activations of previously assigned eligible roles vs a user being assigned a new active role)

[rahul0216]

Hey @scorgatelli,

There is this rule to detect User addition to Privileged group,
https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Azure%20Active%20Directory/Analytic%20Rules/UseraddedtoPrivilgedGroups.yaml

You can tweak rule "User Assigned Privileged Role" to filter PIM assignments,

You can refer this doc for additional activities https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-audit-activities for your use case.

[scorgatelli]

Thanks for the feedback!

I dug into the User Added to Privileged Groups rule and noticed a couple things. It looks for both "Add member to role" and "Add member to role in PIM requested (permanent)", however:

1. From what I can see it will never match on the second operation because it tries to get the modified group name from the modifiedProperties associated with the User target resource. This is true only for "Add member to role". For "Add member to role in PIM" (and other events logged by the PIM service) it is associated with the Role target resource and does not contain the Role.WellKnownObjectName property (only displayName, RoleDefinitionOriginId, and TemplateId)

| mv-apply TargetResource = TargetResources on 
  (
      where TargetResource.type =~ "User"
      | extend TargetUserPrincipalName = tostring(TargetResource.userPrincipalName),
               modProps = TargetResource.modifiedProperties
  )
| mv-apply Property = modProps on 
  (
      where Property.displayName =~ "Role.WellKnownObjectName"
      | extend DisplayName = trim('"',tostring(Property.displayName)),
               GroupName = trim('"',tostring(Property.newValue))
  )

2. It misses other role operations like "Add member to role in PIM requested (timebound)" and "Add eligible member to role in PIM requested (permanent)"

As it currently stands, if I filter out the PIM assignments, pretty much all role assignments will be excluded.

[scorgatelli]

I have updated the "User Assigned Privileged Role" rule to the following logic so it can handle role assignments via PIM and differentiate them from PIM activations (by commenting out the MS-PIM where clause). I prefer the "User Assigned Privileged Role" rule over the other two rules since it handles all admin roles and ServicePrincipals. I disabled the other two rules, but I think they have similar issues and could stand updating as well.

The main differences are that I added additional AADOperationTypes to handle assignments via PIM and a new mv-apply to handle the case where the role name is in a different location. One potential downside to this approach is that it can result in duplicates since a role assignment request would be logged by PIM and again by Core Directory when complete. I don't see a way to overcome this currently.

Currently, I'm looking for role assignment requests to ensure I don't miss anything, but if that becomes noisy it could be updated to match on completions instead.

AuditLogs
| where Category =~ "RoleManagement"
| where AADOperationType in ("Assign", "AssignEligibleRole", "CreateRequestGrantedRole", "CreateRequestPermanentEligibleRole", "CreateRequestPermanentGrantedRole")
| where ActivityDisplayName has_any ("Add eligible member to role", "Add member to role")
| mv-apply TargetResourceSubject = TargetResources on 
  (
      where TargetResourceSubject.type in~ ("User", "ServicePrincipal")
      | extend Target = iff(TargetResourceSubject.type =~ "ServicePrincipal", tostring(TargetResourceSubject.displayName), tostring(TargetResourceSubject.userPrincipalName)),
               subjectProps = TargetResourceSubject.modifiedProperties
  )
| mv-apply TargetResourceRole = TargetResources on 
  (
    // mimic modifiedProperties so we can use the same logic to get the role name regardless of where it comes from
    where TargetResourceRole.type in~ ("Role")
    | extend roleProps = pack_array(bag_pack("displayName","Role.DisplayName", "newValue", TargetResourceRole.displayName))
  )
| mv-apply Property = iff(array_length(subjectProps) > 0, subjectProps, roleProps) on 
  ( 
    where Property.displayName =~ "Role.DisplayName"
      | extend RoleName = trim('"',tostring(Property.newValue))
  )
| where RoleName contains "Admin"
| extend InitiatingApp = tostring(InitiatedBy.app.displayName)
| extend Initiator = iif(isnotempty(InitiatingApp), InitiatingApp, tostring(InitiatedBy.user.userPrincipalName))
// Uncomment below to not alert for PIM activations
//| where Initiator != "MS-PIM"
| summarize by bin(TimeGenerated, 1h), OperationName,  RoleName, Target, Initiator, Result
| extend TargetName = tostring(split(Target,'@',0)[0]), TargetUPNSuffix = tostring(split(Target,'@',1)[0]), InitiatorName = tostring(split(Initiator,'@',0)[0]), InitiatorUPNSuffix = tostring(split(Initiator,'@',1)[0])

[rahul0216]

@scorgatelli, These are great suggestions and appreciate deep dive on alerts.
I would suggest to create a separate rule according to your use case and raise the PR to include in solution.
We'll look into these suggestions and update the rules if needed.

[v-rbajaj]

Hi @scorgatelli, can you please look into the above comment?

[scorgatelli]

Thank you. I am working on creating a pull request for the new rule.