How to use Azure AD Graph API access for service principals? - azure-ad-graph-api

I have a working Azure AD/Azure daemon application using adal4j that uses user/password authentication. Due to issues with ADFS, I wish to also be able to authenticate using a service principal (client ID/secret). This seems to work fine for the Azure (non-AD) portion of the app, as the SP roles can be defined for the subscriptions in question, however for the Azure AD part, I get:
response code 403, error: Authorization_RequestDenied: Insufficient privileges to complete the operation.
...this occurs on the first call to the Graph API - I get valid tokens from AuthenticationContext.acquireToken() using the https://graph.windows.net scope.
My account is an Owner in the directory. I've tried using the "Grant Permissions" button on the app, and have also tried fabricating a consent URL (which works) and using that to consent to the app having the necessary privileges in the directory. Neither seems to affect this.
The app is a Native app, as it is a daemon/service app, so can't participate in OAuth2 consent.
How does one access the Azure AD Graph API using a SP to authenticate? As a reminder, unchanged, the app works with (non-ADFS) user/password, and the SP works with the Azure API, just not Azure AD Graph API.
Thanks...
P.S. I've also tried this with the Azure Graph API, which Microsoft now recommends instead of the Azure AD Graph API. Same result, and similarly works with user/password creds.
Amending this to kind of take adal4j out of the picture - this seems to be more of a generic Azure AD problem. Here's an example of the problem, using curl:
Client credentials token request:
curl --request POST "https://login.windows.net/367cxxxx41e5/oauth2/token" --data-urlencode "resource=https://graph.windows.net" --data-urlencode "client_id=9d83yyyy08cd" --data-urlencode "grant_type=client_credentials" --data-urlencode "client_secret=secret"
Client credentials token response:
{"token_type":"Bearer","expires_in":"3599","ext_expires_in":"0","expires_on":"1491486990","not_before":"1491483090","resource":"https://graph.windows.net","access_token":"eyJ0zzzz2zVA"}
Azure AD REST query using client credentials token:
curl "https://graph.windows.net/367cxxxx41e5/tenantDetails" --header "Authorization: eyJ0xxxx2zVA" --header "Accept: application/json;odata=minimalmetadata" --header "api-version: 1.6"
Azure AD REST response using client credentials token:
{"odata.error":{"code":"Authorization_RequestDenied","message":{"lang":"en","value":"Insufficient privileges to complete the operation."}}}
Now, contrast that with (note the same tenant ID/app ID):
Password credentials token request:
curl --request POST "https://login.windows.net/367cxxxx41e5/oauth2/token" --data-urlencode "resource=https://graph.windows.net" --data-urlencode "client_id=9d83yyyy08cd" --data-urlencode "grant_type=password" --data-urlencode "username=bozo#clown.com" --data-urlencode "password=password"
Password credentials token response:
{"token_type":"Bearer","scope":"Directory.AccessAsUser.All Directory.Read.All Group.Read.All Member.Read.Hidden User.Read User.Read.All User.ReadBasic.All","expires_in":"3599","ext_expires_in":"0","expires_on":"1491489157","not_before":"1491485257","resource":"https://graph.windows.net","access_token":"eyJ0zzzz0EXQ","refresh_token":"AQABzzzzAgAA"}
Azure AD REST query using password credentials token:
curl "https://graph.windows.net/367cxxxx41e5/tenantDetails" --header "Authorization: eyJ0xxxx0EXQ" --header "Accept: application/json;odata=minimalmetadata" --header "api-version: 1.6"
Azure AD REST response using password credentials token:
{"odata.metadata":"https://graph.windows.net/367cxxxx41e5/$metadata#directoryObjects/Microsoft.DirectoryServices.TenantDetail","value":[{"odata.type":"Microsoft.DirectoryServices.TenantDetail","objectType":"Company","objectId":"367cxxxx41e5","deletionTimestamp":null,"assignedPlans":[{"assignedTimestamp":"2017-02-24T03:25:33Z","capabilityStatus":"Enabled","service":"SharePoint","servicePlanId":"e95byyyyc014"},...
My suspicion at this point is that the SP, created by default by Azure AD when the app was created, doesn't include the necessary permissions. I'll try creating a new SP with the rights specified. Examples of this abound, but all are focused on the target app being some mythical LOB app, not Azure AD. And, as seems usual with the half-baked portal, the CLI must be used to do this.
</snark>
Also, I've verified that anyone with Reader role should be able to execute that query. I've added both Contributer and Owner to the SP, with no effect.
Also also, FWIW, I've verified that the SP has, in theory, the Azure AD (and other) permissions I entered in the portal. I think.
PS C:\> Get-AzureADServicePrincipalOAuth2PermissionGrant -objectid 'a9f9xxxx5377'|format-list -property consenttype,resourceid,scope
ConsentType : AllPrincipals
ResourceId : c569xxxxe7f0
Scope : Member.Read.Hidden User.Read User.ReadBasic.All User.Read.All Group.Read.All Directory.Read.All
Directory.AccessAsUser.All
ConsentType : AllPrincipals
ResourceId : 3318xxxx66a5
Scope : user_impersonation
ConsentType : AllPrincipals
ResourceId : 8c0fxxxx4198
Scope : User.Read.All User.ReadBasic.All Group.Read.All Directory.Read.All Directory.AccessAsUser.All User.Read
PS C:\> get-azureadobjectbyobjectid -objectids 'c569xxxxe7f0','3318xxxx66a5','8c0fxxxx4198'
ObjectId AppId DisplayName
-------- ----- -----------
8c0fxxxx4198 00000003-0000-0000-c000-000000000000 Microsoft Graph
3318xxxx66a5 797f4846-ba00-4fd7-ba43-dac1f8f63013 Windows Azure Service Management API
c569xxxxe7f0 00000002-0000-0000-c000-000000000000 Microsoft.Azure.ActiveDirectory

According to your description, per my experience, I think the issue was caused by two reasons.
Not add api access of Windows Azure Active Directory (Microsoft.Azure.ActiveDirectory) in the Required permissions tab of your registed application in Azure AD on Azure portal as below and select the related permissions.
As references, you can refer to the other SO thread Trouble with authorization using client_credentials Azure AD Graph API or the offical document here and a helpful blog.
Not assign Contributor for this service principal. You need to run the powershell command below to do this.
New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName 'applicationID'
Or you can also refer to my answer for another SO thread Cannot list image publishers from Azure java SDK to do this via Azure CLI or just on Azure portal.
Hope it helps.

Related

Getting Error 403 Trying to update PAT on Azure Devops

Based on the doc (https://learn.microsoft.com/en-us/rest/api/azure/devops/tokens/pats/update?view=azure-devops-rest-7.1&tabs=HTTP) provided by MS, i'm trying to update my Token expiration date through the api. I made a sample request using a full access token to authenticate and passing the authorizationId of the token i want to update in the body:
My sample request using Postman
And it keeps returning Error 403, I've checked my organization policies and tried by adding or removing parameters from body but it din't work.
I've also made another request to get the list of tokens on my organization with the same token authorization and api version and that went well.
According to your screenshot you are using the Basic Auth with PAT.
Please note that you must authenticate with an Azure AD token to use this API instead of a PAT token. In order to call the API directly, you need to provide an Azure AD access token as a Bearer token in Authorization header of your request. Please see Manage personal access tokens (PATs) using REST API and Q: Can I use basic auth with all Azure DevOps REST APIs? for details.
You can follow below steps to get the AAD Bearer token:
Install the Azure Az PowerShell module.
Login with a user account which has the permission in your DevOps org (Owner or PCA) with command Connect-AzAccount
1.) Alternately login from the cloud shell with command Connect-AzAccount -UseDeviceAuthentication, you will see the following message:
2.) Then copy the url https://microsoft.com/devicelogin and open in a new tap, enter the code IVR7VRWJQ to authenticate.
3.) Login with the Azure DevOps organization owner or other PCA account. After successful login you will see the account info, then follow below steps to get the Bearer Token.
Get the Bearer token:
$token = (Get-AzAccessToken -ResourceUrl "499b84ac-1321-427f-aa17-267ca6975798").Token
$token
Copy and use the token in script or Postman to update the PAT.

Need to connect service principal with certificate to authorize using pyspark

I want to connect service principal with certificate to authorize using pyspark. I could see the code in scala in this link - https://github.com/Azure/azure-event-hubs-spark/blob/master/docs/use-aad-authentication-to-connect-eventhubs.md
I have client _id and tenant_id and certificate details. Could some please share me the code in pyspark for same?
You add the Azure AD service principal to the Azure Databricks workspace using the SCIM API 2.0. Authentication using Pyspark isn't available.
To authenticate using service principal, you need to follow below steps:
As you already have clientID and tenantID, so the service principal ID already created.
Create the Azure Databricks personal access token
You’ll use an Azure Databricks personal access token (PAT) to authenticate against the Databricks REST API. To create a PAT that can be used to make API requests:
Go to your Azure Databricks workspace.
Click the user icon in the top-right corner of the screen and click User Settings.
Click Access Tokens > Generate New Token.
Copy and save the token value.
Add the service principal to the Azure Databricks workspace
You add the Azure AD service principal to a workspace using the SCIM API 2.0. You must also give the service principal permission to launch automated job clusters. You can grant this through the allow-cluster-create permission. Open a terminal and run the following command to add the service principal and grant the required permissions:
curl -X POST 'https://<per-workspace-url>/api/2.0/preview/scim/v2/ServicePrincipals' \
--header 'Content-Type: application/scim+json' \
--header 'Authorization: Bearer <personal-access-token>' \
--data-raw '{
"schemas":[
"urn:ietf:params:scim:schemas:core:2.0:ServicePrincipal"
],
"applicationId":"<application-id>",
"displayName": "test-sp",
"entitlements":[
{
"value":"allow-cluster-create"
}
]
}'
Replace with the unique per-workspace URL for your Azure Databricks workspace.
Replace with the Azure Databricks personal access token.
Replace with the Application (client) ID for the Azure AD application registration.
Create an Azure Key Vault-backed secret scope in Azure Databricks
Secret scopes provide secure storage and management of secrets. You’ll store the secret associated with the service principal in a secret scope. You can store secrets in a Azure Databricks secret scope or an Azure Key Vault-backed secret scope. These instructions describe the Azure Key Vault-backed option:
Create an Azure Key Vault instance in the Azure portal.
Create the Azure Databricks secret scope backed by the Azure Key Vault instance.
Step 1: Create an Azure Key Vault instance
In the Azure portal, select Key Vaults > + Add and give the key vault a name.
Click Review + create.
After validation completes, click Create .
After creating the key vault, go to the Properties page for the new key vault.
Copy and save the Vault URI and Resource ID.
Step 2: Create An Azure Key Vault-backed secret scope
Azure Databricks resources can reference secrets stored in an Azure key vault by creating a Key Vault-backed secret scope. To create the Azure Databricks secret scope:
Go to the Azure Databricks Create Secret Scope page at https:///#secrets/createScope. Replace per-workspace-url with the unique per-workspace URL for your Azure Databricks workspace.
Enter a Scope Name.
Enter the Vault URI and Resource ID values for the Azure key vault you created in Step 1: Create an Azure Key Vault instance.
Click Create.
Save the client secret in Azure Key Vault
In the Azure portal, go to the Key vaults service.
Select the key vault created in Step 1: Create an Azure Key Vault instance.
Under Settings > Secrets, click Generate/Import.
Select the Manual upload option and enter the client secret in the Value field.
Click Create.
Grant the service principal read access to the secret scope
You’ve created a secret scope and stored the service principal’s client secret in that scope. Now you’ll give the service principal access to read the secret from the secret scope.
Open a terminal and run the following command:
curl -X POST 'https://<per-workspace-url/api/2.0/secrets/acls/put' \
--header 'Authorization: Bearer <personal-access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{
"scope": "<scope-name>",
"principal": "<application-id>",
"permission": "READ"
}'
Replace with the unique per-workspace URL for your Azure Databricks workspace.
Replace with the Azure Databricks personal access token.
Replace with the name of the Azure Databricks secret scope that contains the client secret.
Replace with the Application (client) ID for the Azure AD application registration.
Create a job in Azure Databricks and configure the cluster to read secrets from the secret scope
You’re now ready to create a job that can run as the new service principal. You’ll use a notebook created in the Azure Databricks UI and add the configuration to allow the job cluster to retrieve the service principal’s secret.
Go to your Azure Databricks landing page and select Create Blank Notebook. Give your notebook a name and select SQL as the default language.
Enter SELECT 1 in the first cell of the notebook. This is a simple command that just displays 1 if it succeeds. If you have granted your service principal access to particular files or paths in Azure Data Lake Storage Gen 2, you can read from those paths instead.
Go to Workflows and click the + Create Job button. Give the job a name, click Select Notebook, and select the notebook you just created.
Click Edit next to the Cluster information.
On the Configure Cluster page, click Advanced Options.
On the Spark tab, enter the following Spark Config:
fs.azure.account.auth.type.acmeadls.dfs.core.windows.net OAuth
fs.azure.account.oauth.provider.type.acmeadls.dfs.core.windows.net org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider
fs.azure.account.oauth2.client.id.acmeadls.dfs.core.windows.net <application-id>
fs.azure.account.oauth2.client.secret.acmeadls.dfs.core.windows.net {{secrets/<secret-scope-name>/<secret-name>}}
fs.azure.account.oauth2.client.endpoint.acmeadls.dfs.core.windows.net https://login.microsoftonline.com/<directory-id>/oauth2/token
Replace with the name of the Azure Databricks secret scope that contains the client secret.
Replace with the Application (client) ID for the Azure AD application registration.
Replace with the name associated with the client secret value in the secret scope.
Replace with the Directory (tenant) ID for the Azure AD application registration.
Transfer ownership of the job to the service principal
A job can have exactly one owner, so you’ll need to transfer ownership of the job from yourself to the service principal. To ensure that other users can manage the job, you can also grant Can Manage permissions to a group. In this example, we use the Permissions API to set these permissions.
Open a terminal and run the following command:
curl -X PUT 'https://<per-workspace-url>/api/2.0/permissions/jobs/<job-id>' \
--header 'Authorization: Bearer <personal-access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{
"access_control_list": [
{
"service_principal_name": "<application-id>",
"permission_level": "IS_OWNER"
},
{
"group_name": "admins",
"permission_level": "CAN_MANAGE"
}
]
}'
Replace with the unique per-workspace URL for your Azure Databricks workspace.
Replace with the Azure Databricks personal access token.
Replace with the Application (client) ID for the Azure AD application registration.
The job will also need read permissions to the notebook. Run the following command to grant the required permissions:
curl -X PUT 'https://<per-workspace-url>/api/2.0/permissions/notebooks/<notebook-id>' \
--header 'Authorization: Bearer <personal-access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{
"access_control_list": [
{
"service_principal_name": "<application-id>",
"permission_level": "CAN_READ"
}
]
}'
Replace with the unique per-workspace URL for your Azure Databricks workspace.
Replace with the ID of the notebook associated with the job. To find the ID, go to the notebook in the Azure Databricks workspace and look for the numeric ID that follows notebook/ in the notebook’s URL.
Replace with the Azure Databricks personal access token.
Replace with the Application (client) ID for the Azure AD application registration.
You can now test the job. You run jobs with a service principal the same way you run jobs as a user, either through the UI, API, or CLI.

How to auto generate new Bearer Token in Postman for GCP Storage

I am trying to upload file from local to GCP bucket through cloud storage Rest API (https://storage.googleapis.com/upload/storage/v1/b) using Postman.
I am using Bearer Token for authorization and running $(gcloud auth print-access-token) command on GCP Shell to generate that token every time.
I need to know, how to auto generate that token from Postman while sending request ?
Is there any way to execute $(gcloud auth print-access-token) every time as a Pre-request Script within Postman ?
Thanks
I'm not very good with postman, but I think you can run pre-request to get token and reuse it in the subsequent request.
If so, you can get inspiration from the gcloud auth print-access-token command by adding the --log-http param to visualize the request performed by the CLI and to reproduce them in Postman.
EDIT 1
If you perform the request, you can see that a post is performed to this URL https://oauth2.googleapis.com/token
To reproduce the call, you can try with a curl
curl -X POST -d "grant_type=refresh_token&client_id=32555940559.apps.googleusercontent.com&client_secret=ZmssLNjJy2998hD4CTg2ejr2&refresh_token=<REFRESH_TOKEN>&scope=openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth" https://oauth2.googleapis.com/token
In this call, you need your REFRESH_TOKEN, that you can get here
cat ~/.config/gcloud/legacy_credentials/<YOUR EMAIL>/adc.json
Google Cloud Storage requires authentication as other Google APIs and one of the authentication way is providing bearer token. These bearer tokens are short lived and require regeneration.
So there are 3 ways to generate bearer tokens so you can interact with Google Storage API or other Google APIs using Postman:
Using oauth2l CLI ( Manual Regeneration of new bearer token and update of Authorization header with the new token)
This oauth2l CLI utility allows you to generate bearer tokens which can be pasted into the Authorization header in postman. You can use
Configuration of Postman with OAuth 2 and User Credentials ( Tokens can be managed via the Postman UI and expired ones cleaned up at the click of a button)
Postman can be configured to trigger the OAuth 2 flow and use a generated bearer token in all of the requests. But please make sure that all users have the correct permissions in the Google Cloud Platform project.
You will need to create OAuth 2 credentials in Google Cloud Console:
Go to APIS and Services
Then go to Credentials tab
Click on Create Credentials
Select OAuth Client ID
Fill the fields to create OAuth Client ID ( also add an Authorized redirect URI however this doesn’t need to resolve to anywhere).
The Client ID and Client Secret need to be saved in your machine.
Use Postman’s environment variable functionality to use different credentials per environment/project. In Postman create a new environment for your credentials using the cog icon at the top right.
Configure the variables accordingly: AUTH_CALLBACK_URL , AUTH_URL, AUTH_CLIENT_ID, AUTH_CLIENT_SECRET, AUTH_ACCESS_TOKEN_URL
This variable should be identical to that defined in the OAuth 2 Client ID creation menu and should be one of the following : AUTH_SCOPE
Once defined, these variables can be used in your Authorization tab in Postman. This can be configured at the collection level, the folder level or even the individual request level.
To Regenerate the Token, you can go to Authorization Tab and click on GET NEW ACCESS TOKEN
Configuration of Postman to use a pre-request script and service credentials (The pre-request script automatically regenerates the bearer token when it expires)
For this please check this Tutorial to follow the steps provided there.

How to obtain the authorization code required for User Credentials through the cURL's command line

I trying to use GCS "User Credentials" to connect to Google cloud storage using libcurl library.
"User Credentials" authentication needs Client Id & Secret key to connect to GCS, but in this process Authentication Code also needs to be generated.
I need to generate this Authentication code using cURL.
Can anyone help me ??
The Client ID you mentioned is the same as the Authentication ID and can only be generated from either the Cloud Console's Credentials Page or via the OAuth 2.0 Playground.
If you are trying to generate an Access Token (OAUTH2_TOKEN), you will need to complete an authentication flow to authorize requests as a user. Cloud Storage uses OAuth 2.0 for API authentication and authorization.
Here's what you need to do to get an authorization access token from the OAuth 2.0 Playground:
Select & authorize APIs (Cloud Storage)
Select the scope for the APIs you would like to access or input your own OAuth scopes, e.g.: https://www.googleapis.com/auth/devstorage.read_write
Then click the "Authorize APIs" button
Once you've got the Authorization Code click the "Exchange authorization code for tokens" button, you will get a refresh and an access token which is required to access OAuth protected resources.
Grab the Access Token to use in your cURL command
Then configure your request to Cloud Storage API by constructing your HTTP request like so (upload):
curl -X POST --data-binary #[OBJECT_LOCATION] \
-H "Authorization: Bearer [OAUTH2_TOKEN]" \
-H "Content-Type: [OBJECT_CONTENT_TYPE]" \
"https://www.googleapis.com/upload/storage/v1/b/[BUCKET_NAME]/o?uploadType=media&name=[OBJECT_NAME]"
You can have a look at this Cloud Storage upload example in our public docs to guide you with constructing a request and testing it out.
Hope this helps.

Azure isMemberOf api gives "Insufficient privileges to complete the operation." error when trying to access from Azure Virtual Machine

So my requirement is for the application running on Azure Machine to check if a particular Azure user logged in belongs to an assigned Azure group.
I have enabled Managed Service Identity for the said virtual machine.
MSI
I get the token for the VM by making a call to the metadata service running locally using the following command for the graph resource on the VM:
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fgraph.windows.net' -H Metadata:true
Once I get the token I make a POST request to the graph API of isMemberOf with that newly acquired token:
curl -i -H "Authorization: Bearer <token-value>" -H "Content-Type: application/json" --data '{"groupId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","memberId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}' https://graph.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/isMemberOf?api-version=1.6
I get the following response
{"odata.error":{"code":"Authorization_RequestDenied","message":{"lang":"en","value":"Insufficient privileges to complete the operation."}}}
I have assigned the resource group the VM belongs to with IAM as a owner to the resource
Am I missing something that I should have it configured or I am doing something wrong here?
So I dug around a little bit and found that Microsoft prefers us developers using Microsoft Graph rather than the Azure AD Graph
Microsoft Graph vs Azure AD Graph
I found a similar call in Microsoft Graph API to get member of information User list member of call
This call requires the following scope:
Directory.Read.All
Directory.ReadWrite.All
And these are the steps I followed:
Application would need to fetch the token for making the Microsoft graph API call.
POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
HEADER
Content-type: application/x-www-form-urlencoded
BODY:
client_id=&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=&grant_type=client_credentials
RESPONSE:
{
"token_type": "Bearer",
"expires_in": 3600,
"ext_expires_in": 0,
"access_token": "<token-value>"
}
Client secret is generated at app registration time.
Application would make the call to microsoft graph API to fetch
POST https://graph.microsoft.com/v1.0/users/{user-object-id}/checkMemberGroups
HEADERS: Authorization: Bearer {token-value}
Content-Type: application/json
BODY:
{
"groupIds":["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"]
}
RESPONSE:
200 OK - if user belongs to the group
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(Edm.String)",
"value": [
"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
]
}
404 Not found - if user does not exist
{
"error": {
"code": "Request_ResourceNotFound",
"message": "Resource 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' does not exist or one of its queried reference-property objects are not present.",
"innerError": {
"request-id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"date": "2018-05-23T02:54:47"
}
}
}
This would help application identify if the Azure user belongs to the assigned group or not.
You are calling Azure AD Graph API, not ARM API.
The IAM blade only gives access rights for the ARM API.
You'll need to assign the necessary rights to the service principal kinda manually.
I actually wrote an article on this a while back: Calling your APIs with Azure AD Managed Service Identity using application permissions.
You will need:
Your MSI service principal object id (you can see how to find this in my article)
The target service principal object id (in this case Azure AD Graph API)
Id of the app permission you want to assign (you can use e.g. https://graphexplorer.azurewebsites.net to find these, they are under appRoles on the service principal)
Once you have these, then you can run this PowerShell cmdlet (using the AAD v2 cmdlets):
Connect-AzureAD
New-AzureADServiceAppRoleAssignment -ObjectId msi-sp-id -Id app-permission-id -PrincipalId msi-sp-id -ResourceId aad-graph-sp-id
Then everything should work.