Do the PIM Cmdlets support conditional access?

[brwilkinson]

I have the following error when Acrs is enabled.

Do we know if the PIM activation will support conditional access?

I have the following exception:

'RoleAssignmentRequestAcrsValidationFailed'

FullyQualifiedErrorId : RoleAssignmentRequestAcrsValidationFailed,Microsoft.Azure.PowerShell.Cmdlets.Resources.Authorization.Cmdlets.NewAzRoleAssignmentScheduleRequest_CreateExpanded
ErrorDetails          : &claims={"access_token":{"acrs":{"essential":true, "value":"urn:microsoft:req1"}}}

via:

        $ScheduleRequest = @{
            Name                      = New-Guid
            Scope                     = $Scope
            PrincipalId               = $PrincipalId
            RoleDefinitionId          = $RoleDefinitionId
            RequestType               = if ($Deactivate) { 'SelfDeactivate' }else { 'SelfActivate' }
            ExpirationType            = 'AfterDuration'
            ScheduleInfoStartDateTime = Get-Date -Format o
            ExpirationDuration        = $duration
            Justification             = $Justification
            # LinkedRoleEligibilityScheduleId = $Name
        }
        New-AzRoleAssignmentScheduleRequest @ScheduleRequest |
            ForEach-Object {
                $_ | Select-Object PrincipalDisplayName, PrincipalId, ScopeType, ScopeDisplayName, Scope, 
                Status, Name, RoleDefinitionId, RoleDefinitionDisplayName, @{n = 'Start'; e = { $_.ScheduleInfoStartDateTime.ToLocalTime() } },
                @{ n = 'End'; e = { $_.ScheduleInfoStartDateTime.ToLocalTime().AddTicks([System.Xml.XmlConvert]::ToTimeSpan($_.ExpirationDuration).Ticks) } }
            }

[JustinGrote]

According to this community cmdlet at least, that's the message that means your conditional access policy failed, so theoretically it does.
https://www.powershellgallery.com/packages/AzSK/4.7.0/Content/Framework%5CCore%5CPIM%5CPIMScript.ps1

BTW I've done a lot of this legwork already:
https://github.com/justingrote/jaz.pim

[brwilkinson]

The AzSK was a great Module that was widely used, including for Security Scanning Taks, plus managing PIMv2, however Is not compatible with Pimv3, that I am aware, plus 'AzSk' has also be deprecated now.

i assume it can work, however either I am missing something or the new cmdlets are missing something, I will have to take some time to dig into the source code, so wanted to ask here first. I assume something important for conditional access is being left from the request. One of the requirements is coming from a managed/registered application, which AZ PowerShell is and works for MFA, however the Acrs rules also ensures you are coming from a particular protected environment. i.e. a PAW/SAW type of environment.

[JustinGrote]

If you're getting the error it probably means that the rule is in effect, you can probably look at your sign in logs under the conditional access tab to confirm.

[brwilkinson]

I reviewed the sign in logs, didn't see anything.

[brwilkinson]

This is the rule

[string]$Role = 'Owner'
[string]$RuleFilter = 'AuthenticationContext_EndUser_Assignment'

    $PolicyId = Get-AzRoleManagementPolicyAssignment -Scope $Scope |
        Where RoleDefinitionDisplayName -EQ $Role | foreach PolicyId
    
    Write-Warning "PolicyId is [$PolicyId] for Role [$Role]"
    Get-AzRoleManagementPolicy -Scope $Scope | where Id -eq $PolicyId | 
        foreach EffectiveRule | Where Id -eq $RuleFilter

[brwilkinson]

So I tried the REST api directly and also have the same error. So I will have to figure out to make that work.

https://docs.microsoft.com/en-us/rest/api/authorization/role-assignment-schedule-requests/create

the body that i am passing

{
  "properties": {
    "scheduleInfo": {
      "expiration": {
        "type": "AfterDuration",
        "duration": "PT15M"
      },
      "startDateTime": "2022-05-22T16:34:04.9236928-07:00"
    },
    "roleDefinitionId": "/subscriptions/<guid redacted>/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635",
    "principalId": "<guid redacted>",
    "requestType": "SelfActivate",
    "justification": "observability"
  }
}

400 response

{
  "error": {
    "code": "RoleAssignmentRequestAcrsValidationFailed",
    "message": "&claims=%7B%22access_token%22%3A%7B%22acrs%22%3A%7B%22essential%22%3Atrue%2C%20%22value%22%3A%22urn:microsoft:req1%22%7D%7D%7D"
  }
}

&claims={"access_token":{"acrs":{"essential":true, "value":"urn:microsoft:req1"}}}

Most likely I am missing passing something in the body, it's just not obvious to me as yet what that is.

[dcaro]

@brfabia can you please share some insights?

[dingmeng-xue]

Hi @brwilkinson , could you try Connect-AzAccount and Invoke-AzRestMethod. Authentication part will be handled by Azure PowerShell.

[brwilkinson]

Hi @dingmeng-xue I was actually moving to the new Az Cmdlets for PIM.

so I wanted to use the new New-AzRoleAssignmentScheduleRequest cmdlet, however I get the ACR (conditional access error).

I tried the REST call directly and had the same error... which makes sense since I was using the same token (get-azaccesstoken) without the "acrs".

So I can also test REST with Invoke-AzRestMethod ... will do this tomorrow.

• Do we expect the token from Invoke-AzRestMethod to be different from the one used in New-AzRoleAssignmentScheduleRequest or get-azaccesstoken ? I guess we will find out...

[brwilkinson]

just as FYI I followed up offline with @dingmeng-xue ... with extra logs from all scenarios, working and not working. plus invoke-webrequest and also invoke-azrestmethod. The same results came from both.

Only other update was that the token from Get-AzAccessToken -ResourceTypeName MSGraph didn't have auth error.

• That was late on a Friday, so I perhaps mixed that up initially.
• It actually showed the token was not valid for this request, which makes sense.

Invoke-WebRequest: {"error":{"code":"InvalidAuthenticationTokenAudience","message":"The access token has been obtained for wrong audience or resource '499b84ac-1321-427f-aa17-267ca6975798'. 
It should exactly match with one of the allowed audiences '[https://management.core.windows.net/','https://management.core.windows.net','https://management.azure.com/','https://management.azure.com'."}}]
(https://management.core.windows.net/%27,%27https://management.core.windows.net%27,%27https://management.azure.com/%27,%27https://management.azure.com%27.%22%7D%7D)

So that was just a side step.

[charlie-swing]

@brwilkinson Did you ever find a solution for this?

[brwilkinson]

@charlie-swing No this is not resolved. I did have an idea the other day.

I am thinking we can add the additional claims on the app registration.

https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims?tabs=manifest#configure-optional-claims-in-your-application

Given the app registration for the owner of the app would live in the Microsoft Owned Tenant they would have to add the additional claims there.

I was working with @dingmeng-xue however he moved teams during the process, so we never had any chance to get to resolution.

Someone with access to the App Registration for the Azure Portal could check that configuration and match up with the same for the Azure PowerShell claims.

[ExecOrder66]

Has this been updated or fixed? We are still not able to get New-AzRoleAssignmentScheduleRequest to work on elevating an Azure subscription in powershell. We can elevate properly in the gui. The token/cache is erroring on the c1 policy, which is set to require executing from a SAW device.

New-AzRoleAssignmentScheduleRequest : &claims=%7B%22access_token%22%3A%7B%22acrs%22%3A%7B%22essential%22%3Atrue%2C%20%22value%22%3A%22c1%22%7D%7D%7D
At line:1 char:1

• New-AzRoleAssignmentScheduleRequest `

[Alex-wdy]

@VeryEarly Can you take a look at this question? CC @isra-fel

[ExecOrder66]

Any updates or follow ups? we are still unable to make this work.

[offical-DiceBet]

The error RoleAssignmentRequestAcrsValidationFailed indicates that the Role Assignment request is failing due to a missing or mismatched ACR (Authentication Context Reference) claim in the access token. Conditional Access policies using ACRs require specific claims, and PIM (Privileged Identity Management) currently doesn't natively support conditional access with ACR validation.

[offical-DiceBet]

To resolve this, ensure the access token includes the required acrs claim:

Verify your Conditional Access policy configuration.
Ensure the app or service principal is configured to pass the necessary ACR values during token issuance.
If unsupported, consider bypassing the ACR requirement for PIM role activation temporarily.

[offical-DiceBet]

Check Azure AD logs to identify token issues.
Monitor for updates to PIM that may add support for ACRs in Conditional Access.
Engage Microsoft Support if the issue persists, as this might require policy adjustments or feature workarounds.

[Offical-7kCassinoMinidep]

If the issue persists, consider reaching out to Microsoft Support. They can assist in fine-tuning policies or identifying alternative solutions to work around the problem.

[Offical-7kCassinoMinidep]

Also, don’t be shy about asking for updates on related features. Sometimes a small nudge brings big insights—or at least gets someone to notice there’s a gremlin in the code!

[brwilkinson]

seems like bots...

• 7kCasinoMinidep1az
• DiceBet1giris