calling ad sp credential list returns empty

[rezarms]

When calling az ad sp credential list it returns empty value but after renewing a password for the first time it shows the correct value.

To Reproduce

Create a spn and then call

 az ad sp credential list --id {app id}

then renew a password for the spn and call the above command again

Expected behavior
It should show the expiry date of spn before renewing the password.

After further investigation I noticed the command is calling below url:
'https://graph.windows.net/tenant/applications/{objectid}/passwordCredentials?api-version=1.6'
which is the same url for az ad app credential.

It should call
'https://graph.windows.net/tenant/serviceprincipals/{objectid}/passwordCredentials?api-version=1.6'

What's more ,if url of serviceprincipal is called it doesn't return the latest expiry date after renewing the password which is another issue.

azure-cli 2.32.0

[yonzhan]

@jiasli for awareness

[jiasli]

az ad sp credential list does the same thing as az ad app credential list. This is the designed behavior (#11458). We plan to rectify this behavior in Microsoft Graph migration (#12946).

What's more ,if url of serviceprincipal is called it doesn't return the latest expiry date after renewing the password which is another issue.

I will keep this in mind and take a look during Microsoft Graph migration.

[bmarinov]

I suspect that I am hitting this issue. The output of az ad sp credential list --id "$SP_ID" --query "[].endDateTime" -o tsv is the expiration time of the original credentials. These have been reset months ago, but im still seeing the old date.

I need to figure out in advance which cluster credentials need to be reset soon. After wrestling with the ms graph API for a while (filtering should not be that hard, right) I decided to give the updated az-cli a try.

az ad sp show --id $SP_ID

# ...
#  "passwordCredentials": [
#    {
#      "endDateTime": "2022-02-16T17:55:54.2217355Z",
#      "keyId": "...",
#      "startDateTime": "2021-02-16T17:53:08.7185779Z"
#    }
#  ],

The credentials are already reset, but all I can see are the original ones. This is not exactly ideal, any ways to get around this problem?

These docs are no longer up to date too: https://docs.microsoft.com/en-us/azure/aks/update-credentials#check-the-expiration-date-of-your-service-principal

[rezarms]

The issue is from Graph api because by using powershell you'll see the same issue.
The workaround is to use

az ad app credential 

If it's empty then use

az ad sp show

[bmarinov]

The issue is from Graph api because by using powershell you'll see the same issue. The workaround is to use

az ad app credential 

If it's empty then use

az ad sp show

Thanks, I didn't think of this. Its decent as far as workarounds go :)

[tonystz]

I encounter the same issue, is any updates?

{
  "azure-cli": "2.38.0",
  "azure-cli-core": "2.38.0",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {
    "aks-preview": "0.4.67",
    "application-insights": "0.1.13",
    "ssh": "1.0.0"
  }
}

[jiasli]

@tonystz, which issue did you encounter? az ad sp credential list missing credentials or showing credentials that shouldn't be there?

[dosmanak]

Hello. I also get empty response on az ad sp credential list --id <<sp.appId>>.

When I search for the service principal in portal, I was able to found the expiry info and obfuscated secret under AAD->Apps Registrations->Certificates and Secrets

$ az version
Azure-cli    Azure-cli-core    Azure-cli-telemetry
-----------  ----------------  ---------------------
2.38.0       2.38.0            1.0.6

EDIT:

I was able to get the information using

az ad app show --id <<app.id>> -o json --query 'passwordCredentials[].endDateTime'

or

az ad app credential list --id <<app.id>>

Where id is to be found using

az ad app list --app-id <<sp.appId>> -o tsv --query '[].id'

[jiasli]

Azure Portal can only show app's credential, not service principal's. Use az ad app credential list to get the same behavior as Azure Portal.

[yrro]

The docs for az ad sp credential say:

The credential update will be applied on the Application object the service principal is associated with. In other words, you can accomplish the same thing using "az ad app credential".

Which is not correct if az ad app credential list is managing a separate set of credentials as az ad sp credential.

[cameron-doherty]

This issue still appears to be occurring with the latest version. az ad app credential list and az ad sp credential both return empty results. The scripts mentioned here seem to be operating as intended but it is cumbersome to have to go to a specific PS 5.1 only module to get this working.

Even alternatives Get-AzAdServicePrincipal or Get-AzAdSpCredential don't seem to work as expected.

[yrro]

This issue still appears to be occurring with the latest version. az ad app credential list and az ad sp credential both return empty results. The scripts mentioned here seem to be operating as intended but it is cumbersome to have to go to a specific PS 5.1 only module to get this working.

An additional complication I have noticed while investigating this is that it takes a while after I use az ad app credential reset before the new credential shows up in the Azure portal.

With the hidden/undiscoverable nature of sp-specific credentials. the misleading documentation and the lag before changes display in the portal, Microsoft couldn't have designed a more confusing and frustrating system if they tried!