Azure-cli: "az ad signed-in-user show" crashes for SP authentication

Created on 5 Sep 2019  路  6Comments  路  Source: Azure/azure-cli

az feedback auto-generates most of the information requested below, as of CLI version 2.0.72

Describe the bug
A clear and concise description of what the bug is.

az ad signed-in-user show crashes if signed in using Service Principal

az ad signed-in-user show --query objectId --output tsv
Resource not found for the segment 'me'.      

To Reproduce

Steps to reproduce the behavior.

az login --service-principal -u ${AZURE_CLIENT_ID} -p ${AZURE_CLIENT_SECRET} --tenant ${AZURE_TENANT_ID} && az account set -s ${AZURE_SUBSCRIPTION_ID}
az ad signed-in-user show 

Expected behavior
A clear and concise description of what you expected to happen.

Command behaves same way for SP and User signed in

Environment summary
Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)

MSI

Additional context
Add any other context about the problem here.

Azure Identity Integration Graph feature-request

Most helpful comment

@jiasli yeah, it makes sense.

However, if you use az cli in a script, it means each user has to implement their own forks for SP/user again and again in some cases. It would be great if az cli can adapt based on the current authentication since it already has all required data and knows the auth mechanism.

All 6 comments

Azure CLI internally uses Python SDK to call AAD Graph REST API "Get the signed-in user".

https://github.com/Azure/azure-sdk-for-python/blob/6aba868527568e83625103475d97c03ccd13b5e8/sdk/graphrbac/azure-graphrbac/azure/graphrbac/operations/signed_in_user_operations.py#L92

get.metadata = {'url': '/{tenantID}/me'}

https://docs.microsoft.com/en-us/previous-versions/azure/ad/graph/api/signed-in-user-operations#get-the-signed-in-user--

This API only supports user's token. For Service Principal, you may use az account show to get the Service Principal name, then use az ad show to query the detailed information: https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az-ad-sp-show

@jiasli yeah, it makes sense.

However, if you use az cli in a script, it means each user has to implement their own forks for SP/user again and again in some cases. It would be great if az cli can adapt based on the current authentication since it already has all required data and knows the auth mechanism.

Thank you for the feedback. We will consider this as a feature request.

@jiasli is there any update on this? We have the pod managed identity integrated but from the current cli implementation, there's no way for us to verify the identity form cli for the pod..., it's kind of doesn't really make sense ...

this is what CLI shows me when I wanted to verify who I am from a pod with has managed identity binded
bash-5.0# az account show { "environmentName": "AzureCloud", "homeTenantId": "$TENANTID", "id": "$SUBID", "isDefault": true, "managedByTenants": [], "name": "$SUBNAME", "state": "Enabled", "tenantId": "$TENANTID", "user": { "assignedIdentityInfo": "MSI", "name": "systemAssignedIdentity", "type": "servicePrincipal" } }
This information doesn't really tell me anything so it's hard for us to automatically check the permissions

add to S168

@jiasli is there any update on this? We have the pod managed identity integrated but from the current cli implementation, there's no way for us to verify the identity form cli for the pod..., it's kind of doesn't really make sense ...

this is what CLI shows me when I wanted to verify who I am from a pod with has managed identity binded

bash-5.0# az account show
{
  "environmentName": "AzureCloud",
  "homeTenantId": "$TENANTID",
  "id": "$SUBID",
  "isDefault": true,
  "managedByTenants": [],
  "name": "$SUBNAME",
  "state": "Enabled",
  "tenantId": "$TENANTID",
  "user": {
    "assignedIdentityInfo": "MSI",
    "name": "systemAssignedIdentity",
    "type": "servicePrincipal"
  }
}```
This information doesn't really tell me anything so it's hard for us to automatically check the permissions

@qianwens, I think this is a really good argument to include all of objectId, clientId and resourceId so that users can know who the managed identity is. I already parsed them in https://github.com/Azure/azure-cli/pull/13195, and they only need to be exposed.

Was this page helpful?
0 / 5 - 0 ratings