Microsoft Graph API Support

[jiasli]

According to https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview:

Azure Active Directory (Azure AD) Graph is deprecated. To avoid loss of functionality, migrate your applications to Microsoft Graph before June 30, 2022 when Azure AD Graph API endpoints will stop responding to requests.

We need to switch Azure CLI to use Microsoft Graph API instead.

[jiasli]

Call Microsoft Graph API with az rest

As Microsoft Graph REST API v1.0 is now GA, we can call it directly with az rest to achieve the same effect as az ad commands, including all latest features from Microsoft Graph. It can automatically authenticate to Microsoft Graph.

Examples

Update redirectUris for an Application

Originally posted at #9501 (comment). We call the Update application API. The GUID part in the following URLs are the object ID of the application.

# Get the application
az rest --method GET --uri 'https://graph.microsoft.com/v1.0/applications/b4e4d2ab-e2cb-45d5-a31a-98eb3f364001'

# Update `redirectUris` for `web` property
az rest --method PATCH --uri 'https://graph.microsoft.com/v1.0/applications/b4e4d2ab-e2cb-45d5-a31a-98eb3f364001' --body '{"web":{"redirectUris":["https://myapp.com"]}}'

Add owners to a service principal

Originally posted at #9250 (comment). We call the servicePrincipal: Add owner API.

appId=93dde3da-9fca-47dd-aee2-409b402ffed3
spObjectId=$(az ad sp show --id $appId --query objectId --output tsv)

# Get the object Id for the current user
ownerObjectId=$(az ad signed-in-user show --query objectId -o tsv)

# This applies to both user and service principal as owners
az rest -m POST -u https://graph.microsoft.com/beta/servicePrincipals/$spObjectId/owners/\$ref -b "{\"@odata.id\": \"https://graph.microsoft.com/beta/directoryObjects/$ownerObjectId\"}"

# To add a user as an owner
az rest -m POST -u https://graph.microsoft.com/beta/servicePrincipals/$spObjectId/owners/\$ref -b "{\"@odata.id\": \"https://graph.microsoft.com/beta/users/$ownerObjectId\"}"

# To add a service principal as an owner
az rest -m POST -u https://graph.microsoft.com/beta/servicePrincipals/$spObjectId/owners/\$ref -b "{\"@odata.id\": \"https://graph.microsoft.com/beta/servicePrincipals/$ownerObjectId\"}"

Remarks

• The above commands are for Bash which Azure Cloud Shell uses
• In both PowerShell and CMD terminal, double quotes " in the JSON body (as contents) need to be escaped by \, even if the JSON body is surrounded by single quotes ': '{\"key\":\"value\"}'. For more info, please see Quoting Issues

[phil-holden]

A comment made by @jiasli in issue #9250 suggests that it should be possible to add a Service Principal as the Owner of an Application using the MS Graph API as follows.

az rest --method post --uri https://graph.microsoft.com/V1.0/applications/$appObjectId/owners/$ref --headers Content=Type=application/json --body "{\"@odata.id\":\"https://graph.microsoft.com/V1.0/directoryObjects/$spObjectId\"}"

this currently returns a Bad Request

{
  "error": {
    "code": "Request_BadRequest",
    "message": "The reference target 'Application_xxx' of type 'Application' is invalid for the 'owners' reference.",
    "innerError": {
      "request-id": "bdf80192-becb-43d5-9447-e0e2a91d7d68",
      "date": "2020-05-27T01:25:14"
    }
  }
}

xxx in the response above is the $spObjectId

Is this still a supported scenario using the MS Graph API?

az ad app owner add --id $appObjectId --owner-object-id $spObjectId

returns a similar result.

[jiasli]

Hi phil-holden, this error The reference target 'Application_xxx' of type 'Application' is invalid for the 'owners' reference. indicates xxx is an application object ID, not a service principal object ID.

If you are using Azure CLI, retrieve the service principal object ID with

# Use appId 46eb4122-bd2b-4f54-af7b-6d79b46ee31a
$ az ad sp show --id 46eb4122-bd2b-4f54-af7b-6d79b46ee31a --query objectId --output tsv
8aaa6158-7450-4407-ba08-61377f23d05f

If you are using Azure Portal, retrieve the service principal object ID with

Please notice that this issue is only for tracking purpose. For specific issues, you may create a new issue or reply to #9250.

[phil-holden]

Thanks Jiashuo Li (@jiasli), works well when you have the right id!

[Tbohunek]

Jiashuo Li (@jiasli) Thanks man! It solved our problem too! I was ripping my hair for 2 weeks now.

However just to understand.. Before I made the SP1 an owner of SP2, SP1 wasn't able to update the reply urls with error

az ad app update --id <appid> --add replyUrls "http://test" --debug

https://graph.windows.net:443 "GET /<tenantid>/applications?$filter=identifierUris%2Fany%28s%3As%20eq%20%<appid>%27%29&api-version=1.6 HTTP/1.1" 200 121

Insufficient privileges to complete the operation.

This was even despite SP1 having all the permissions on SP2 via full custom role, so I figured it's because it cannot read the Directory itself to list all applications and filter them.

Now when we made the SP1 owner of SP2, it can update the ReplyURLs without having any explicit API permissions nor any custom role as above.

What are we missing? Why does it work without Directory.Read.All?

Thank you!

[jiasli]

Hi Tomáš Bohuněk (@Tbohunek),

Actually you are hitting a known issue that a Directory.Read.All permission should not be mandatory to update an application.

azure-cli/src/azure-cli/azure/cli/command_modules/role/custom.py

Lines 1068 to 1079 in 2b6fe1e

	def _resolve_application(client, identifier):
	result = list(client.list(filter="identifierUris/any(s:s eq '{}')".format(identifier)))
	if not result:
	if _is_guid(identifier):
	# it is either app id or object id, let us verify
	result = list(client.list(filter="appId eq '{}'".format(identifier)))
	else:
	error = CLIError("Application '{}' doesn't exist".format(identifier))
	error.status_code = 404 # Make sure CLI returns 3
	raise error
	return result[0].object_id if result else identifier

You can see from the code that a tenant query is mandatory before CLI can treat the --id as an object ID.

az ───→ identifierUri ───→ objectId   This doesn't work because tenant-level query is needed to search for the app
 │                             ↑
 └─────────────────────────────┘      This works because no tenant-level query is needed

This is certainly a design flaw and we plan to fix it in the Microsoft Graph integration. We are considering whether we should split identifierUris, appId and objectId to avoid confusions, but this would certainly be a BREAKING CHANGE.

For example, az role assignment create already has this fix. --assignee-object-id is used for bypassing Graph permission issues:

> az role assignment create -h
...
    --assignee                : Represent a user, group, or service principal. supported format:
                                object id, user sign-in name, or service principal name.
    --assignee-object-id      : Use this parameter instead of '--assignee' to bypass graph
                                permission issues. This parameter only works with object ids for
                                users, groups, service principals, and managed identities. For
                                managed identities use the principal id. For service principals, use
                                the object id and not the app id.

With that being said, I am not able to repro your scenario. I got Insufficient privileges to complete the operation. with both appId and appObjectId as expected:

# Owner Service Principal (not Application)
$ ownerObjectId="b0460b1a-d53a-42e8-a6a4-d9f43f0ccc73"

# Owned Application
$ appId="46eb4122-bd2b-4f54-af7b-6d79b46ee31a"
$ appObjectId="9580df2b-3c36-4a15-b909-15bb1b30b3a7"

# Add the owner
$ az rest --method post --uri https://graph.microsoft.com/V1.0/applications/$appObjectId/owners/\$ref --body "{\"@odata.id\":\"https://graph.microsoft.com/V1.0/directoryObjects/$ownerObjectId\"}"

$ az ad app update --id $appId --add replyUrls "http://test"
Insufficient privileges to complete the operation.

$ az ad app update --id $appObjectId --add replyUrls "http://test"
Insufficient privileges to complete the operation.

If an app can do tenant-level query without Directory.Read.All permission, this is definitely a security breach. 😉

Please check

1. Whether your are really using the owner application logged in with az account show
2. Whether there are remaining permissions left for the owner application

Even as an owner, the owner application still need Application.ReadWrite.OwnedBy permission to update its owned applications. For Microsoft Graph:

(Same for AD Graph, but due to the design flaw mentioned above, az ad app update won't work.)

To bypass the tenant-level query, you can directly use Microsoft Graph Update application to update the redirectUris.

$ az rest -m PATCH -u https://graph.microsoft.com/v1.0/applications/$appObjectId --body '{"web":{"redirectUris":["https://myapp.com"]}}' --verbose
Request URL: 'https://graph.microsoft.com/v1.0/applications/9580df2b-3c36-4a15-b909-15bb1b30b3a7'
Request method: 'PATCH'
Request headers:
    'User-Agent': 'AZURECLI/2.6.0 (DEB)'
    'Accept-Encoding': 'gzip, deflate'
    'Accept': '*/*'
    'Connection': 'keep-alive'
    'x-ms-client-request-id': '65f37202-02b9-4723-b788-3dda87354bac'
    'Content-Type': 'application/json'
    'CommandName': 'rest'
    'ParameterSetName': '-m -u --body --verbose'
    'Authorization': 'Bearer eyJ0eXAiOiJKV...'
    'Content-Length': '46'
Request body:
{"web":{"redirectUris":["https://myapp.com"]}}
Response status: 204
Response headers:
    'Cache-Control': 'private'
    'Content-Type': 'text/plain'
    'request-id': '180fda8f-739e-41ea-b540-4ea8bfe8bed4'
    'client-request-id': '180fda8f-739e-41ea-b540-4ea8bfe8bed4'
    'x-ms-ags-diagnostic': '{"ServerInfo":{"DataCenter":"Southeast Asia","Slice":"SliceC","Ring":"5","ScaleUnit":"000","RoleInstance":"AGSFE_IN_24"}}'
    'Strict-Transport-Security': 'max-age=31536000'
    'Date': 'Thu, 28 May 2020 05:05:20 GMT'
Response content:

command ran in 1.641 seconds.

Again, if you have further questions regarding this specific topic, please kindly create a new issue. I am glad to help. 😊

[Tbohunek]

Jiashuo Li (@jiasli) Thank you, this helped me find out that I was not using properly isolated CLI sessions, so adding the ReplyURL after making the SP and owner was run by wrong SP.

Now I granted the SP1 the Azure AD Graph: Application.ReadWrite.OwnedBy API permission and it works as expected.

Note that in the azure-cli 2.6.0 command it's visible that it uses the Azure AD Graph and not the new MS Graph:

az --version

azure-cli                          2.6.0
command-modules-nspkg              2.0.3
core                               2.6.0
nspkg                              3.0.4
telemetry                          1.0.4


az ad app update --id de9b193b-6b87-4ee8-954e-de1e6e6d99d9  --add replyUrls "http://test" --debug

https://graph.windows.net:443 "GET /<tenantid>/applications?$filter=identifierUris%2Fany%28s%3As%20eq%20%27de9b193b-6b87-4ee8-954e-de1e6e6d99d9%27%29&api-version=1.6 HTTP/1.1" 403 219

[jiasli]

I am glad it is working for you.

Yes, az ad is still using AD Graph API. This's what this whole issue is talking about. Since Microsoft Graph Service Principal API is GA, we recommend using az rest instead of az ad for the time being until we fully migrate az ad to Microsoft Graph.

---

However, I tried to add Microsoft Graph: Application.ReadWrite.OwnedBy to the owner application, then I am able to list all applications in the tenant using this owner application!

> az rest -u 'https://graph.microsoft.com/v1.0/applications' --query "value[].displayName"
[
  "sp19e92232ca5",
  "sp168579505de",
  "sp25f660911937e",
  ...

This is against the AAD doc https://docs.microsoft.com/en-us/graph/permissions-reference#remarks-3:

NOTE: Using the Application.ReadWrite.OwnedBy permission to call GET /applications to list applications will fail with a 403. Instead use GET servicePrincipals/{id}/ownedObjects to list the applications owned by the calling application.

[scals44]

Jiashuo Li (@jiasli) thanks for all the examples of utilizing az rest to call service principals. I'm fighting with a possible edge case now. In an attempt to categorize and programmatically rotate client secrets we're aiming to use Tags on service principal objects. For the most part, this works fine by running az commands like:
az ad sp update --id appID --add tags "tags:value"

Before I got to this point I ran into the nanosecond/microsecond Azure Portal bug with az cli and I am getting similar behavior when trying to update tags on a service principal using the above command. The client secrets were set using the "old" method, outlined below:
$servicePrincipal = New-AzureRmADServicePrincipal -ApplicationId $spn.ApplicationId $BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($servicePrincipal.Secret) $spnPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR) [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($BSTR) $SecureStringPassword = ConvertTo-SecureString -String $spnPassword -AsPlainText -Force #Apply the password to the app New-AzureRmADAppCredential -ApplicationId $spn.ApplicationId -Password $SecureStringPassword

When trying to tag service principals created this way I am finding the generic error: az : Update to existing credential with KeyId 'keyID' is not allowed.

Do you have any working examples of updating tags with the az rest method? I can't seem to get the payload correct.
az rest -m "PATCH" -u https://graph.microsoft.com/v1.0/servicePrincipals/objID --headers "Content-Type=application/json" -b '{\"tags\":\""tag:value"\"}'

Any help is appreciated, thanks!