login: ERROR: AADSTS700024: Client assertion is not within its valid time range

Can this be documented in the federated credentials setup steps? We are having the same issue.

Still necessary (this is fun 👍)

Thanks for your patience folks. Based on this, Azure PowerShell has released their fix and this should have bumped up the default validity of the OIDC token issued for Service principals to 1hr.

Just to call out, Azure also supports OIDC with Managed identities and the default token validation time for this flow is 24 hrs - which should suffice most of the deployment use cases. Please refer to Microsoft’s documentation at "Workload identity federation” and Configure a user-assigned managed identity to trust an external identity provider (preview) which has more details about the Azure Workload Identity Federation (OIDC) support for Managed Identities.

Kindly request you to explore this and confirm if that experience works as expected for your scenarios. Thanks.

Hello @N-Usha

I just tested this and the lifetime is still not very long, as you can in the screenshot it’s 5 mins.

Are there any specific configurations to be done? I am using version 1.4.6 of the azure/login action

But it states AzVersion is 2.10.4, is this the correct version?

Please let me know if I need to configure something differently on my yaml files.

Cheers, Sandro

There are the following 2 separate issues which we are seeing being reported here -

1. The known limitation of access-token expiry and absence of a refresh mechanism. This is one potential cause for the failure of long-running workflows which go beyond the default validity of the access-token. For the default values please check this - https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#access-token-lifetime
2. There are a few comments on workflows failing after 5 or 10 mins for the powershell case. We have noticed that azure PowerShell fetches an access token from MSAL when each cmdlet execution. For client assertion (Github token), azure PowerShell stores assertion and fetches access token using the github token when each cmdlet is executed. This is causing the workflows to fail soon after the github token expires. This behavior only applies to the powershell case. In the Az CLI login, we don’t observe this. We are following up with the respective teams to understand the problem better.

We are investigating this further and will post the updates here.

Another issue here with the token validity here, the token only being valid for 5 mins!

Using Azure/Login with Service Principal:

    subscription.go:24: cancelling subscription 1ad7747d-5335-4322-a565-392903a10534
    subscriptionDeploy_test.go:96: cannot cancel subscription: subscription 1ad7747d-5335-4322-a565-392903a10534 does not exist or cannot successfully check, cannot get subscription, DefaultAzureCredential: failed to acquire a token.
        Attempted credentials:
        	EnvironmentCredential: missing environment variable AZURE_CLIENT_ID
        	ManagedIdentityCredential: IMDS token request timed out
        	AzureCLICredential: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2022-10-31T12:44:19.4908573Z, assertion valid from 2022-10-31T11:49:11.0000000Z, expiry time of assertion 2022-10-31T11:54:11.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .

Still necessary

FWIW I was able to test this here with 1hr time between operations, using a managed identity.

Link to action: https://github.com/matsest/az-oidc-managed-identity-demo/actions/runs/3896459977/jobs/6653023616

Workflow definition: https://github.com/matsest/az-oidc-managed-identity-demo/blob/37467e85623d9472885a52293e6bf9ca20ce994e/.github/workflows/login.yaml

---

EDIT: I’ve tried the same test used OIDC with a service principal here:

Workflow: https://github.com/matsest/az-oidc-managed-identity-demo/blob/4da25b3055dd4254f247fc8f8dc308bc9af07bc6/.github/workflows/login.yaml

Action: https://github.com/matsest/az-oidc-managed-identity-demo/actions/runs/3933497855/jobs/6727259798

This worked when I tried 20m but failed when I tried 1 hr:

Hey guys,

This is a serious problem. At the moment we are able to workaround the issue by splitting longer running PowerShell scripts up into smaller parts and logging in again.

However that isn’t always possible.

Please see my better software suggestion here:

https://bettersoftwaresuggestions.com/github/github-azure-login-allow-custom-expiry-time-for-oidc-token/

Thanks @sandrochristiaan. We have it on our backlog to address the refresh issue and will have it addressed soon. Will surely keep you posted on the timelines.

Yes, we definitely recommend OIDC for authentication as it helps avoid transacting with cloud credentials as secrets. And we are committed to making the experience better for our customers. Thanks for your support again.

Yes. But we can’t commit to a specific timeline for this right now. We will keep you informed.

I’ll close this issue.

• If you meet an Azure PowerShell token expiration issue, please refer to comment .
• If you meet other token expiration issues, please open a new issue for it. Provide your workflow file and debug logs for further analysis.

I have this error when when the build take more that 10 min runner: ubuntu-latest and use manage identity for login into my AKS cluster

Hit this issue on Ubuntu based workflow. We login upfront, then try to do an image build (which runs for 10-15 mins), meanwhile the token is expired and Hashicorp packer fails because the token has expired. It was only valid for 5 mins.

Here is the log from that failed step:

...
peer-pod-ubuntu.azure-arm.ubuntu: output will be in this color.

==> peer-pod-ubuntu.azure-arm.ubuntu: Running builder ...
==> peer-pod-ubuntu.azure-arm.ubuntu: Getting tokens using Azure CLI
==> peer-pod-ubuntu.azure-arm.ubuntu: unable to get token from azure cli: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
==> peer-pod-ubuntu.azure-arm.ubuntu: Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
==> peer-pod-ubuntu.azure-arm.ubuntu: Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
==> peer-pod-ubuntu.azure-arm.ubuntu: Timestamp: 2023-05-17 01:01:18Z
==> peer-pod-ubuntu.azure-arm.ubuntu: Interactive authentication is needed. Please run:
==> peer-pod-ubuntu.azure-arm.ubuntu: az login
==> peer-pod-ubuntu.azure-arm.ubuntu:
Build 'peer-pod-ubuntu.azure-arm.ubuntu' errored after 1 second 393 milliseconds: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
Timestamp: 2023-05-17 01:01:18Z
Interactive authentication is needed. Please run:
az login


==> Wait completed after 1 second 393 milliseconds

==> Some builds didn't complete successfully and had errors:
--> peer-pod-ubuntu.azure-arm.ubuntu: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
Timestamp: 2023-05-17 01:01:18Z
Interactive authentication is needed. Please run:
az login


==> Builds finished but no artifacts were created.
make: *** [Makefile:25: podvm-c491ecd-amd64] Error 1
Error: Process completed with exit code 2.

The docs say that the expiry time is configurable. But they don’t say how.

This expiration time is further configurable in Azure

Has anyone found a workaround for the tokens that expire after ~1h? I guess you could detect that case and run the login action again?

Indeed just a re-login. We look at the average runtime of a workflow and put a re-login at the appropriate point in the workflow. Would be nice if the token time is configurable as part of the login action.

Chiming in here as I’ve just encountered the same issue in a GitHub Actions workflow using OIDC login with a service principal.

The workflow uses GitHub-hosted runner ubuntu-latest, hence as per the docs at the time of writing this, has Azure CLI 2.46.0 installed (see https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md#cli-tools).

The actions used are:

1. azure/login@v1
2. PowerShell script that calls the Azure CLI
3. azure/arm-deploy@v1
4. PowerShell script that calls the Azure CLI
5. azure/webapps-deploy@v2
6. PowerShell script that calls the Azure CLI
7. azure/webapps-deploy@v2

In my case, the error happened on step 6, with the following error message, showing the token has a 5-minute lifetime:

ERROR: AADSTS700024: Client assertion is not within its valid time range.
Current time: 2023-03-21T12:46:57.8394504Z, assertion valid from 2023-03-21T12:30:13.0000000Z, expiry time of assertion 2023-03-21T12:35:12.0000000Z.
Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials.

Unfortunately I don’t have timestamps showing whether the previous action took more than 5 minutes, but I can only guess it’s the case.

I’m in no position to try out using OIDC login with a managed identity at the moment. Is this still supposed to happen?

Hi @matsest . I took this issue over within the company so going to have a look at it in the upcoming days. Had a little bit of a hand over but still need to read up on the issue.

That’s great, thank you for confirming @matsest 👍🏻 I will retry this on our deployment pipelines and report on the outcome!

Keeping this from being idle 👍🏻

@N-Usha this has been addressed by Azure CLI and will addressed in Azure PowerShell v9.2 to be released on 12/6/2022.

We are having the exact same issue as @cwe1ss mentioned above a few days ago.

@BALAGA-GAYATRI, are you still involved with this issue? Any ideas on timelines? Thanks in advance.

bump again. More than one year in the making? Plenty of docs about github actions + azure using OIDC (perfect, no need to rotate credentials). And the pipeline can run for negligible < 10 minutes? https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows

https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure

Token policies, as mentioned, have no effect. No defaults changed on the tenant, and the token is valid for 1 hour… https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes#access-id-and-saml2-token-lifetime-policy-properties

Hello @N-Usha I have modified the token lifetime using the Microsoft documentation mentioned. It does not make any difference at all, deployments will fail due to the token expiring after a short period of time.

I opened a case with Microsoft on this. They have told me that the token lifetime policy will only apply to the SP token and not the assertion from the federated credentials. An auto-refresh mechanism is what is needed to fix this issue.

I do hope this to be fixed soon, since this really is a way better solution instead of using a service principal with secrets, as described in GitHub documentation: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#benefits-of-using-oidc

Can you provide a timeline on when to expect a fix? Or even an answer if it will get fixed?

Thanks, Sandro

Utmost respect for the maddest lad @dionhaefner for this comment https://github.com/Azure/login/issues/180#issuecomment-1545459942

Which allowed me to work around this issue in terraform with the following:

data "azurerm_client_config" "current" {
}

data "external" "login" {
  program = ["bash", "${path.module}/scripts/refresh.sh"]
  query = {
    client_id       = data.azurerm_client_config.current.client_id
    tenant_id       = data.azurerm_client_config.current.tenant_id
    subscription_id = data.azurerm_client_config.current.subscription_id
  }
}

#!/bin/bash
set -e

eval "$(jq -r '@sh "AZURE_CLIENT_ID=\(.client_id) AZURE_TENANT_ID=\(.tenant_id) AZURE_SUBSCRIPTION_ID=\(.subscription_id)"')"

if [[ "$ACTIONS_ID_TOKEN_REQUEST_TOKEN" == "" ]] || [[ "$ACTIONS_ID_TOKEN_REQUEST_URL" == "" ]]
then
  # This is ok, we're probably running locally
  jq -n '{}'
  exit 0
fi

# get JWT from GitHub's OIDC provider
# see https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc
jwt_token=$(
  curl "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange" \
    -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
    --silent \
  | jq -r ".value"
)

# perform OIDC token exchange
az login \
  --service-principal -u $AZURE_CLIENT_ID \
  --tenant $AZURE_TENANT_ID \
  --federated-token $jwt_token \
  -o none

az account set \
  --subscription $AZURE_SUBSCRIPTION_ID \
  -o none

jq -n '{}'

This allows me to refresh the token in the middle of a long terraform apply in a few places where I need to bust out into a null_resource or data external script and use the az cli.

module "auth_refresh" {
  source = "../../helpers/azure_auth_refresh"
}

resource "null_resource" "redirect_uris" {
  // ...
}

Are there any plans to support idTokens with a lifetime longer than 10 minutes? This constraint has sadly forced us back to using SP authentication with client secrets.

We have a scripted deployment process (i.e. runs as a single GitHub Actions step using azure/powershell@v1) that runs for longer than 10 minutes. It includes functionality towards the end that requires an access token from another service (i.e. a data plane operation), which fails as the idToken has expired.

As a tangible example of this scenario, consider using the Az.Synapse PowerShell module to make configuration changes to a Synapse Workspace that has just been provisioned by a preceding ARM deployment (lasting longer than 10 minutes).

UPDATE: When testing an equivalent repro with the recently announced preview of federated credentials for Azure DevOps, we do not see the same issue.

@JamesDawson , do you mean the toke generated by GitHub? I think it’s out of the scope of this Action. Can you raise an issue for GitHub Action Core?

I ended up just using a shell script login.sh for OIDC login (instead of the login action):

#!/bin/bash
set -e

# get JWT from GitHub's OIDC provider
# see https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc
jwt_token=$(
    curl \
        -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
        "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange" \
        --silent \
    | jq -r ".value"
)

# perform OIDC token exchange
az login \
    --service-principal -u $AZURE_CLIENT_ID \
    --tenant $AZURE_TENANT_ID \
    --federated-token $jwt_token \
    -o none

az account set \
    --subscription $AZURE_SUBSCRIPTION_ID \
    -o none

Then you can keep track of time in long-running scripts and renew the token every 50 minutes or so.

As I can see, there are 2 issues:

• The token will be expired in 5 min.
  • This is the original issue, and it’s fixed in Azure PowerShell v9.2 (released on 12/6/2022).
  • It’s also the issue BartDecker mentioned.
• The token will be expired after 50 min.
  • It’s the issue as your comment . And I reproduce it in comment.

❗❗❗Here are the notes for all: ❗❗❗Please upgrade your Azure PowerShell Modules version to the latest! NOT only the Azure Login Action but ALL actions (if your action runs any Azure PowerShell Module), e.g., Azure PowerShell Action, PowerShell scripts to run Azure PowerShell, …

@matsest , please kindly check my above question in this comment.

@YanaXu many thanks for the opportunity to reach out to you on teams.

I have retested and it indeed works as expected.

Some notes for others who run into the same problem:

• It’s not only the az version that belongs to the login step of your job which counts
• we had several steps that can’t use the latest azpwsh version but use azpwsh 7.5.0 These jobs will fail and actually need a re-login before they start.
• Our 7.5.0 jobs take less than 5 mins which make a re-login work for these steps. It could be that the jobs would fail if it takes longer than 5 mins.

Tested with a workflow consisting out of multiple steps which use : azPSVersion: “latest” for the deployment steps and “AzVersion”: “2.12.1” for the login step.

$token = Get-AzAccessToken

Hi @YanaXu Yan Xu FTE

Thanks for testing but the test is not valid for the problem. Probably $token = Get-AzAccessToken gets a new token after getting the initial OICD token.

We can have a screen sharing session if yo want. Would be nice to get to the bottom of this as there is some confusion in this discussion every now and than.

See my earlier comments here: #180 (comment)

@BartDecker , It’s better to share your workflow file and the related workflow output. If it’s not OK to share, please ping me on teams, and we can schedule a meeting. You can find my teams account (mail) on GitHub profile. Thanks.

$token = Get-AzAccessToken

Hi @YanaXu

Thanks for testing but the test is not valid for the problem. Probably $token = Get-AzAccessToken gets a new token after getting the initial OICD token.

We can have a screen sharing session if yo want. Would be nice to get to the bottom of this as there is some confusion in this discussion every now and than.

See my earlier comments here: https://github.com/Azure/login/issues/180#issuecomment-1471425657

Similar issue in another tool that was fixed by refetching the token instead of storing it: https://github.com/Azure/azure-dev/pull/1963

@dcaro

we are aware of the issue and working on it. Do you have a scenario that you can share with us that would allow us to reproduce the issue all the time.

Something like this (with configurable times to run attempts in parallel) have made it possible to reproduce it for me:

https://github.com/matsest/az-oidc-managed-identity-demo/blob/4da25b3055dd4254f247fc8f8dc308bc9af07bc6/.github/workflows/login.yaml

@isra-fel

AzVersion was “2.11.1” in my case, but the fix should be there since 2.10.4.

P.S. They did mention that This expiration time is further configurable in Azure. Could that be the reason of the error?

This is not the way to test the issue at hand… The proper way to test is to just have the login action (OIDC) and have a a job which just runs a little bit longer.

When I insert your test in between the below workflow the get-accesstoken has a validity of:

But as you can see the workflow/job fails after several minutes anyways with:

: Client assertion is not | within its valid time range. Current time: 2023-03-16T06:46:21.3974707Z, | assertion valid from 2023-03-16T06:28:41.0000000Z, expiry time of | assertion 2023-03-16T06:33:41.0000000Z

So I guess the token from get-access token is not used for the login action and subsequently not used for the running job in question. It looks like the OIDC access token has a (much) short time range.

The below issue is a structural. We test this every 2 weeks since the last months because it’s quite an issue for our setup.

This issue is idle because it has been open for 14 days with no activity.

Can you confirm the managed identities configuration as tested by @matsest is the only way to go when using long running workflows in combination with OIDC auth?

@sandrochristiaan From your screenshots it looks like you’re using Az Module 7.5.0? Please try to upgrade to 9.2 or newer (Az.Accounts 2.10.4 or newer).

@dingmeng-xue, you are performing an operation against the Azure API every 60 seconds meaning the token never gets a chance to become stale (and can therefore refresh on the next operation).

Does this still work if you increase the logic to loop every 10 minutes (or longer)?

Looking at the other comments on this issue (and my own experience with OIDC) the primary issue we are facing occurs when a synchronous operation takes longer than 5 minutes. In this scenario it appears that the token expires before the next operation can be performed, resulting in the observed error.

Thanks for your patience folks. Based on this, Azure PowerShell has released their fix and this should have bumped up the default validity of the OIDC token issued for Service principals to 1hr.

@N-Usha is it going to be possible to override this default from within the Azure/login action? Although increasing this value may be useful to cover some long lasting jobs, having this fixed at a longer expiration time feels like the wrong move from a security perspective. Providing an option for a customer to set the timeout as needed for the task being performed feels like a better approach. Do you know whether this might be possible in a future release?

Looping in @dcaro and @chasewilson from Azure PowerShell team, who are exploring a resolution for this issue in Az PS.

Just today, noticed it will fail when using CLI as well. Well, the action calls a powershell script, but in there, all the commands are CLI commands (powershell commands are not AZ-Powershell ones, only foreach, write-out, or similar ones). After going for 13 mins in a loop, it would try an

az storage blob upload --file $fileName -c $storageAccountContainer --account-name $storageAccountName -n $fileName --auth-mode login

failing with the same error

ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2022-11-11T13:57:03.8472818Z, assertion valid from 2022-11-11T13:43:07.0000000Z, expiry time of assertion 2022-11-11T13:48:07.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: c8ca033e-5187-40aa-8b7c-dc8c7762e300
Correlation ID: ed3e4dfc-4dbd-4096-9dfe-c855164bb964
Timestamp: 2022-11-11 13:57:03Z
Interactive authentication is needed. Please run:
az login

and there’s certainly no way to use az login…

Here’s my error with a sample workflow. As you can see, this does just log in and wait for 11 minutes between two calls to the Az PowerShell module.

name: 'TEST'

on:
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:

  deploy:
    runs-on: ubuntu-latest
    environment: platform

    steps:

    - uses: actions/checkout@v3

    - uses: azure/login@v1
      with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          enable-AzPSSession: true

    - name: 'Deploy Azure resources'
      uses: azure/powershell@v1
      with:
        inlineScript: |
          "Calling Get-AzVm"
          Get-AzVm
          "Sleep start"
          Start-Sleep -Seconds 660
          "Sleep stop"
          "Calling Get-AzVm"
          Get-AzVm
          "Done"
        azPSVersion: "8.2.0"

Output from azure/login:

Show output

2022-10-28T08:12:27.5734334Z ##[group]Run azure/login@v1 2022-10-28T08:12:27.5734597Z with: 2022-10-28T08:12:27.5734991Z client-id: *** 2022-10-28T08:12:27.5735275Z tenant-id: *** 2022-10-28T08:12:27.5735565Z subscription-id: *** 2022-10-28T08:12:27.5735817Z enable-AzPSSession: true 2022-10-28T08:12:27.5736072Z environment: azurecloud 2022-10-28T08:12:27.5736320Z allow-no-subscriptions: false 2022-10-28T08:12:27.5736614Z audience: api://AzureADTokenExchange 2022-10-28T08:12:27.5736859Z ##[endgroup] 2022-10-28T08:12:28.6273343Z Using OIDC authentication… 2022-10-28T08:12:28.6974981Z Federated token details: 2022-10-28T08:12:28.6975674Z issuer - https://token.actions.githubusercontent.com 2022-10-28T08:12:28.6976257Z subject claim - repo:cwe1ss/msa-template:environment:platform 2022-10-28T08:12:28.6981058Z [command]/usr/bin/az cloud set -n azurecloud 2022-10-28T08:12:30.1968287Z Done setting cloud: “azurecloud” 2022-10-28T08:12:31.7047442Z Running Azure PS Login 2022-10-28T08:12:31.7089422Z [command]/usr/bin/pwsh -Command try { 2022-10-28T08:12:31.7090020Z $ErrorActionPreference = “Stop” 2022-10-28T08:12:31.7090580Z $WarningPreference = “SilentlyContinue” 2022-10-28T08:12:31.7092921Z $output = @{} 2022-10-28T08:12:31.7094749Z $data = Get-Module -Name Az.Accounts -ListAvailable | Sort-Object Version -Descending | Select-Object -First 1 2022-10-28T08:12:31.7095423Z $output[‘AzVersion’] = $data.Version.ToString() 2022-10-28T08:12:31.7096004Z $output[‘Success’] = “true” 2022-10-28T08:12:31.7096670Z } 2022-10-28T08:12:31.7096935Z catch { 2022-10-28T08:12:31.7097400Z $output[‘Error’] = $.exception.Message 2022-10-28T08:12:31.7097661Z } 2022-10-28T08:12:31.7097962Z return ConvertTo-Json $output 2022-10-28T08:13:06.3608603Z { 2022-10-28T08:13:06.3608940Z “AzVersion”: “2.9.1”, 2022-10-28T08:13:06.3609586Z “Success”: “true” 2022-10-28T08:13:06.3609828Z } 2022-10-28T08:13:06.4372988Z [command]/usr/bin/pwsh -Command try { 2022-10-28T08:13:06.4373309Z $ErrorActionPreference = “Stop” 2022-10-28T08:13:06.4373776Z $WarningPreference = “SilentlyContinue” 2022-10-28T08:13:06.4374132Z $output = @{} 2022-10-28T08:13:06.4374559Z Clear-AzContext -Scope Process; 2022-10-28T08:13:06.4422814Z Clear-AzContext -Scope CurrentUser -Force -ErrorAction SilentlyContinue;Connect-AzAccount -ServicePrincipal -ApplicationId ‘’ -Tenant '’ -FederatedToken ‘’ -Environment ‘azurecloud’ | out-null;Set-AzContext -SubscriptionId '’ -TenantId ‘***’ | out-null; 2022-10-28T08:13:06.4423597Z $output[‘Success’] = “true” 2022-10-28T08:13:06.4423839Z } 2022-10-28T08:13:06.4510346Z catch { 2022-10-28T08:13:06.4510924Z $output[‘Error’] = $.exception.Message 2022-10-28T08:13:06.4511192Z } 2022-10-28T08:13:06.4511507Z return ConvertTo-Json $output 2022-10-28T08:13:12.5383688Z { 2022-10-28T08:13:12.5384284Z “Success”: “true” 2022-10-28T08:13:12.5384636Z } 2022-10-28T08:13:12.6247805Z Azure PowerShell session successfully initialized 2022-10-28T08:13:12.6248618Z Login successful.

Output from azure/powershell:

Show output

2022-10-28T08:13:12.6351560Z ##[group]Run azure/powershell@v1 2022-10-28T08:13:12.6351822Z with: 2022-10-28T08:13:12.6352208Z inlineScript: "Calling Get-AzVm" Get-AzVm "Sleep start" Start-Sleep -Seconds 660 "Sleep stop" "Calling Get-AzVm" Get-AzVm "Done"

2022-10-28T08:13:12.6352593Z azPSVersion: 8.2.0 2022-10-28T08:13:12.6352854Z errorActionPreference: Stop 2022-10-28T08:13:12.6353125Z failOnStandardError: false 2022-10-28T08:13:12.6353568Z githubToken: *** 2022-10-28T08:13:12.6353792Z env: 2022-10-28T08:13:12.6354008Z AZURE_HTTP_USER_AGENT: 2022-10-28T08:13:12.6354261Z AZUREPS_HOST_ENVIRONMENT: 2022-10-28T08:13:12.6354500Z ##[endgroup] 2022-10-28T08:13:12.8442153Z Validating inputs 2022-10-28T08:13:12.8710862Z [command]/usr/bin/pwsh -NoLogo -NoProfile -NonInteractive -Command Test-Path (Join-Path /usr/share az_*) 2022-10-28T08:13:13.2067027Z True 2022-10-28T08:13:13.8151481Z [command]/usr/bin/pwsh -NoLogo -NoProfile -NonInteractive -Command 2022-10-28T08:13:13.8152170Z $prevProgressPref = $ProgressPreference 2022-10-28T08:13:13.8153228Z $ProgressPreference = ‘SilentlyContinue’ 2022-10-28T08:13:13.8153764Z Expand-Archive -Path /usr/share/az_8.2.0.zip -DestinationPath /usr/share 2022-10-28T08:13:13.8154157Z $ProgressPreference = $prevProgressPref 2022-10-28T08:13:17.2987612Z Module Az 8.2.0 installed from hostedAgentGHRelease 2022-10-28T08:13:17.2989446Z Initializing Az Module 2022-10-28T08:13:17.3004255Z Initializing Az Module Complete 2022-10-28T08:13:17.3006143Z Running Az PowerShell Script 2022-10-28T08:13:17.3021054Z [command]/usr/bin/pwsh -NoLogo -NoProfile -NonInteractive -Command /home/runner/work/_temp/ec0866d1-cdc6-473a-a3a8-a984c5e898ca.ps1 2022-10-28T08:13:17.5657741Z Calling Get-AzVm 2022-10-28T08:13:21.7046544Z Sleep start 2022-10-28T08:24:21.7076491Z Sleep stop 2022-10-28T08:24:21.7077432Z Calling Get-AzVm 2022-10-28T08:24:22.1724491Z Get-AzVM: /home/runner/work/_temp/ec0866d1-cdc6-473a-a3a8-a984c5e898ca.ps1:8 2022-10-28T08:24:22.1724938Z Line | 2022-10-28T08:24:22.1725247Z  8 |  Get-AzVm 2022-10-28T08:24:22.1725542Z  |  ~~~~~~~~ 2022-10-28T08:24:22.1725993Z  | Your Azure credentials have not been set up or have expired, please run 2022-10-28T08:24:22.1726519Z  | Connect-AzAccount to set up your Azure credentials. A configuration 2022-10-28T08:24:22.1727036Z  | issue is preventing authentication - check the error message from the 2022-10-28T08:24:22.1727552Z  | server for details. You can modify the configuration in the application 2022-10-28T08:24:22.1728095Z  | registration portal. See https://aka.ms/msal-net-invalid-client for 2022-10-28T08:24:22.1728901Z  | details. Original exception: AADSTS700024: Client assertion is not 2022-10-28T08:24:22.1729401Z  | within its valid time range. Current time: 2022-10-28T08:24:21.8673176Z, 2022-10-28T08:24:22.1729874Z  | assertion valid from 2022-10-28T08:12:29.0000000Z, expiry time of 2022-10-28T08:24:22.1730344Z  | assertion 2022-10-28T08:17:29.0000000Z. Review the documentation at 2022-10-28T08:24:22.1731256Z  | https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials . Trace ID: 97fd40c6-56db-4450-81a4-5124da090800 Correlation ID: bf08574a-c5b8-414c-a061-10f576bcb360 Timestamp: 2022-10-28 08:24:21Z 2022-10-28T08:24:22.1731820Z  2022-10-28T08:24:22.2577355Z ##[error]Error: The process ‘/usr/bin/pwsh’ failed with exit code 1

The error in a more readable form:

Get-AzVM: /home/runner/work/_temp/ec0866d1-cdc6-473a-a3a8-a984c5e898ca.ps1:8
Line |
   8 |  Get-AzVm
     |  ~~~~~~~~
     | Your Azure credentials have not been set up or have expired, please run
     | Connect-AzAccount to set up your Azure credentials. A configuration
     | issue is preventing authentication - check the error message from the
     | server for details. You can modify the configuration in the application
     | registration portal. See https://aka.ms/msal-net-invalid-client for
     | details.  Original exception: AADSTS700024: Client assertion is not
     | within its valid time range. Current time: 2022-10-28T08:24:21.8673176Z,
     | assertion valid from 2022-10-28T08:12:29.0000000Z, expiry time of
     | assertion 2022-10-28T08:17:29.0000000Z. Review the documentation at
     | https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials . Trace ID: 97fd[40](https://github.com/cwe1ss/msa-template/actions/runs/3343879514/jobs/5537575948#step:4:41)c6-56db-4450-81a4-5124da090800 Correlation ID: bf08574a-c5b8-[41](https://github.com/cwe1ss/msa-template/actions/runs/3343879514/jobs/5537575948#step:4:42)4c-a061-10f576bcb360 Timestamp: 2022-10-28 08:24:21Z

EDIT: I’m using Managed identities with federated credentials!

Hi @udayxhegde . The error I get is similar to this:

ClientAssertionCredential authentication failed: A
     | configuration issue is preventing authentication - check the
     | error message from the server for details. You can modify the
     | configuration in the application registration portal. See
     | https://aka.ms/msal-net-invalid-client for details.  Original
     | exception: AADSTS700024: Client assertion is not within its
     | valid time range. Current time: 2022-10-26T06:11:15.1049397Z,
     | assertion valid from 2022-10-26T06:01:13.0000000Z, expiry time
     | of assertion 2022-10-26T06:06:13.0000000Z. Review the
     | documentation at

The action is as simple as this

 runs-on: ubuntu-latest
    steps:

    - name: Checkout self
      uses: actions/checkout@v2

    - name: Login to Azure 
      uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        enable-AzPSSession: true 
        allow-no-subscriptions: true
    
    - name: Scan eligible groups for member count
      shell: pwsh
      env:
        TENANT_ID: xyz
        STORAGE_ACCOUNT_NAME: 'pimcompliancedata'
        STORAGE_CONTAINER_NAME: 'pim-daily-scan-results'
        
      run: |
        .\scripts\scan-member-count.ps1 -storageAccountName $env:STORAGE_ACCOUNT_NAME -storageAccountContainer $env:STORAGE_CONTAINER_NAME

And the PS script being run is just calling a bunch of Get-AzAdGroupMember for all AD groups starting with a given prefix (in a foreach-object -parallel). And this happens every time the action takes more than 10 mins. Tenant settings are per default (which should make the token valid for 1 hour). OIDC federation is setup as the documentation linked above asks to do (“scenario” is “github actions deploying azure resources”).

@RenatoMartins-tomtom I totally agree, it is a bit weird the difference between reality and what is being propagated in the documentation.

I would be quite happy to just have a ‘draft’ timeline on when to expect possible work to be done on this issue 😐

Please can someone please provide a real answer on what we can expect?

Bump.

Using the alternate login method is less secure than OIDC.