I have successfully made a Custom App Consent Policy using New-AzureADMSPermissionGrantConditionSet and following the MS docs. I specified ClientApplicationIds and it works great.
Now I also want to specify the permissions that must match. On Permissions, the docs say:
I need help understanding (and accessing) the permission IDs in the "OAuth2Permissions property of the API's ServicePrincipal object".
What ServicePrincipal is the doc referring to? The one in the application’s Home Tenant, or one in the Tenant that is using the application? If the app has not been consented to yet, then there is no ServicePrinciple in the Tenant using the app so I have a chicken-and-egg problem.
And what are the Permissions I'm expecting to get? I'm wondering why MS didn't just let us pass the scopes as strings e.g. email, mail.read etc. I don't understand exactly what the Permissions are in this particular context.
I need help understanding (and accessing) the permission IDs in the "OAuth2Permissions property of the API's ServicePrincipal object".
The permission ID means the id of the Delegated permission of the API( i.e. oauth2Permissions defined in the API) you added in the client app registration.
For example, you created a multi-tenant client app in tenant A, you added the Mail.Read Delegated permission of Microsoft Graph, by default, there would also be a User.Read Delegated permission automatically, so there are two permissions totally in the API permissions of your client app.
Now, you want to use the custom app consent policy in tenant B, you want the user to consent the two permissions, then the -Permissions should be the id of the two permission defined in Microsoft Graph, to find it easily, just navigate to the client app in tenant A -> Manifest, then you can get the ids like below.
The complete command should be
New-AzureADMSPermissionGrantConditionSet `
-PolicyId "joy-custom-policy" `
-ConditionSetType "includes" `
-PermissionType "delegated" `
-ResourceApplication "00000003-0000-0000-c000-000000000000" `
-Permissions #("e1fe6dd8-ba31-4d61-89e7-88639da4683d","570282fd-fa5c-430d-a7fd-fc8dc98a9dca")
In another scenario, you use the custom API(created in tenant A) in the client app instead of a Microsoft API.
If so, you need to grant admin consent for the API App in tenant B first, otherwise you will get an error The app needs access to a service (\"api://tenantA/myapi\") that your organization (tenant B) has not subscribed to or enabled, or you can use the admin account to run New-AzureADServicePrincipal -AppId <appid of the API app> in tenant B, it will also work, after consent, the normal user will be able to consent the permission you defined in the policy.
Note: Sometimes, you may get an error This app may be risky like below.
This means Microsoft detects a risky end-user consent request, the request will require a step-up to admin consent instead, if you still want the user to consent the permission, you need to disable the risk-based step-up consent first, then the user will be able to consent the permission.
Here's an example for how you would get the permission IDs for three delegated permissions for Microsoft Graph, using Azure AD PowerShell:
# The appId for the client application
$clientAppId = "{client-app-id}"
# The claim values for the Microsoft Graph delegated permissions to include
$claimValues = #("User.Read", "Mail.Send", "User.ReadBasic.All")
# Get the service principal for Microsoft Graph
$resource = Get-AzureADServicePrincipal -Filter "servicePrincipalNames/any(n:n eq 'https://graph.microsoft.com')"
# Get the delegated permission IDs for the given claim values
$permissionIds = $resource.OAuth2Permissions `
| ? { $claimValues.Contains($_.Value) } | select -ExpandProperty Id
# Use these permission IDs in a condition set for a custom permission grant policy
New-AzureADMSPermissionGrantConditionSet `
-PolicyId "my-custom-policy" `
-ConditionSetType "includes" `
-ClientApplicationIds #($clientAppId) `
-PermissionType "delegated" `
-ResourceApplication $resource.AppId `
-Permissions $permissionIds
Related
I understand the process of assigning Microsoft Graph permissions to a service principal. I can take the object id of the Microsoft Graph app, then use the https://graph.microsoft.com/v1.0/servicePrincipals/<id>/appRoleAssignedTo MSGraph endpoint, like described here.
My question is: can I do the same with a regular user? That is, when calling appRoleAssignedTo, specify the object id of a user in the principalId field. Can a regular user have application permissions (like MSGraph permissions), and how do I use them afterwards?
I tried to do the above and assign the RoleManagement.ReadWrite.Directory to a user. Then I logged in with az login and ran az account get-access-token --resource-type ms-graph.
With this token I tried to do an operation that requires the RoleManagement.ReadWrite.Directory permission, like assigning a role to another user, but it fails with Insufficient privileges to complete the operation..
Users can request the scope they need when using Connect-MgGraph, for example:
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
Which is the recommended approach, as it means that for that session they will only have access to the scopes that are necessary rather than any they've previously requested
I tried to reproduce the same in my environment and got the same error as below:
Note that: Microsoft Graph API permissions can be assigned only to Service principals not users directly.
When I tried to Connect-MgGraph as a normal user, I got the error like below:
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
I created an Azure AD Application and granted API permission as below:
I generated access token by using below parameters:
GET https://login.microsoftonline.com/1810a95e-99f3-46e0-84e8-8a2aee05d830/oauth2/v2.0/token
client_id:ClientID
client_secret:*****
scope:RoleManagement.ReadWrite.Directory
grant_type:authorization_code
redirect_uri:RedirectUri
code:code
By using the above access token, I am able to assign directory role to the user successfully as below:
POST https://graph.microsoft.com/v1.0/directoryRoles/roleTemplateId=88d8e3e3-8f55-4a1e-953a-9b9898b8876b/members/$ref
Content-type: application/json
{
"#odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/UserID"
}
Reference:
Add graph api permission to user account by Harpreet Singh Matharoo
I am using the Fluent Azure SDK for .NET to try fetching the list of all service principals in the tenant.
var authenticatedContext = Azure.Authenticate(
await SdkContext.AzureCredentialsFactory.FromServicePrincipal(aadClientId, aadClientSecret, tenantId, "AzureGlobalCloud")
);
var sps = authenticatedContext.ServicePrincipals.ListAsync().GetAwaiter().GetResults();
The service principal with the AAD Client Id has Directory.Read.All API permission.
(Just to be sure I'm not missing anything : I see this permission in ServicePrincipal -> Permissions section in the Azure Portal)
But still, the following error is thrown :
Microsoft.Azure.Management.Graph.RBAC.Fluent.Models.GraphErrorException: Operation return an invalid status code 'Forbidden'
However, the callouts to get ADGroup and list of subscriptions work
var subs = authenticatedContext.Subscriptions.ListAsync().GetAwaiter().GetResults();
var sgs = authenticatedContext.Subscriptions.ActiveDirectoryGroups().GetByIdAsync(someId).GetAwaiter().GetResults();
I don't know what permissions are missing.
I test the code in my side, and use fiddler to catch the request. It seems the sdk request Azure AD graph api but not Microsoft graph api to list the service principals. So you need to add permission Directory.Read.All of AAD graph but not Microsoft graph. Please refer to the steps below:
After adding the permission, do not forget grant admin consent for it. Then you can run your code success to get the service principal.
By the way, there is a bug with AAD permission Directory.Read.All. If we add AAD permission Directory.Read.All into the registered app, then the permission can not be removed even if we remove it from the page. So you still can run the code success even if you remove the Directory.Read.All from "API permissions" tab on the page.
I'm using a service principle with permissions Application.Read.All and Directory.Read.All of Application type to authenticate to Azure and using following code to pull list of Applications in the tenant.
from azure.common.credentials import ServicePrincipalCredentials
from azure.graphrbac import GraphRbacManagementClient
from config import app
credentials = ServicePrincipalCredentials(
client_id = app["CLIENT"],
secret = app["KEY"],
tenant = app["TENANT_ID"],
resource="https://graph.windows.net"
)
graphrbac_client = GraphRbacManagementClient(credentials, app["TENANT"])
for app in graphrbac_client.applications.list():
print("\nApp:")
print(app)
print("******\n")
Any help is much appreciated
Application.Read.All and Directory.Read.All these 2 permissions requires Global Administrator consent for your directory. I would suggest to ask your Global Administrator to provide consent to your service principal.
From your description, I suppose you added the application permission Application.Read.All and Directory.Read.All of Microsoft Graph, because what you need is Azure Active Directory Graph, which does not have the Application.Read.All permission.
In your code, it uses the resource="https://graph.windows.net", which means your code calls the Azure Active Directory Graph, not Microsoft Graph, to solve the issue, just add the application permission Directory.Read.All of Azure Active Directory Graph like below.
Note : After adding the permission, don't forget to click the Grant admin consent for xxx button, otherwise your service principal will not get the permission.
There may be some delay, after half an hour, test the code, it works fine.
Trying to get an Logic App to get email message details via Graph API because the O365 Outlook Connector does not provide the output I need but Graph API does (Internet message headers).
The Outlook connector creates an API Connection for authentication and that works great.
To call Graph API I am using the HTTP action and it supports Managed Identity, so I'm wondering:
Can I grant permission such that the Managed Identity can read a certain mailbox?
Can the HTTP action use an API Connection (similar to what the Outlook connector does)?
1.Can I grant permission such that the Managed Identity can read a certain mailbox?
The managed identity is a service principal, which we can check it and its permissions in the Azure portal -> Azure Active Directory -> Enterprise applications. But we could not add new permissions in that, so we need to create a new AD App in the App registrations, add credentials to your app
, then grant the Mail.Read application permission of Microsoft Graph API, refer to this link. The permission is to call this api List messages(I suppose you want to use this api, if not, just follow the doc to find the application permission, add it.) At last, don't forget to click the Grant admin consent button.
In the logic app, use Active Directory OAuth for Authentication, https://graph.microsoft.com/ for Audience, and specific the URL, Client id, secret, etc, what need to call the MS graph api. xxx#microsoft.com is the user principal name, also is the mailbox address. I am not sure I understand the read a certain mailbox in your question correctly enough, if you mean you want to grant the permission just for only one mailbox, I will say there is no such permission in Microsft graph.
2.Can the HTTP action use an API Connection (similar to what the Outlook connector does)?
There is no pre-bulit connector for http action, you could try the Custom connectors in Logic Apps.
There is a way to add that application role permission to the Managed Identity. It is not possible to do that using the Azure Portal. You can verify in the Azure Portal that the steps below worked though. This method saves you creating a principal yourself and removes the need for client id/secret bookkeeping.
When you use Powershell, it is possible to add the Mail.Read application role permission to a managed identity, be it a system managed or user managed identity. There are other ways of performing the same steps, e.g. Azure CLI. But below is what I know works and have used.
The steps are usable for any identity and application with assignable app roles. So you can also add Sharepoint permissions to list sites, open an Excel sheet. But keep in mind that the Microsoft app roles are mostly all or nothing. It breaks the principle of least priviliged permissions.
I would love to know a generic way to avoid breaking the principle.
To assign an app role permission to a managed identity we need to know a couple of things:
the id of...
...the managed identity (e.g. "logic-app-identity")
...the application that has the application role (e.g. "Microsoft Graph")
...the id of the application role to assign to the managed identity (e.g. "Mail.Read")
And then we can assign the app role to the managed identity.
Set up some variables for readability
$managed_identity_name = "logic-app-identity"
$application_with_the_required_role_name = "Microsoft Graph"
$application_role_to_assign_name = "Mail.Read"
Use AzureAD module and login.
Use the AzureAd module from here
Import-Module AzureAd
Connect-AzureAd #shows popup to login
1. Get the managed identity id
# filter first server side, and in case of multiple results, the where ensures a single result
# -All is necessary because a managed identity is a sort of service principal
$managed_identity_id = (Get-AzureADServicePrincipal -All $true -SearchString $managed_identity_name | where DisplayName -eq $managed_identity_name).ObjectId
2. Get the application with the requested application roles
# -SearchString on "Microsoft Graph" returns two results, therefore the where clause to ensure a single result
# storing the returned object, because it contains the approles array
$application_with_the_required_role = (Get-AzureADServicePrincipal -SearchString "Microsoft Graph" | where DisplayName -eq "Microsoft Graph")
# fun fact: the ObjectId of the "Microsoft Graph" application is always: 94d0e336-e38a-4bfc-9b21-8fbb74b6b835
$application_with_the_required_role_id = $application_with_the_required_role.ObjectId
3. Get the application role id to assign to the managed identity
# the required id is now simply called Id
# fun fact: the ObjectId of the "Mail.Read" app role is always: 810c84a8-4a9e-49e6-bf7d-12d183f40d01
$application_role_to_assign_id = ($application_with_the_required_role.AppRoles | where Value -eq $application_role_to_assign_name).Id
Assign the app role to the managed identity
New-AzureADServiceAppRoleAssignment -ObjectId $managed_identity_id -PrincipalId $managed_identity_id -ResourceId $application_with_the_required_role_id -Id $application_role_to_assign_id
BONUS: verify-ish the assignment
# should list the assigned application to the identity, dig further for the specific app role
# (I don't know how :S)
Get-AzureADServiceAppRoleAssignedTo -ObjectId $managed_identity_id | fl
# and the other way around to list the identities assigned to the application
Get-AzureADServiceAppRoleAssignment -ObjectId $application_with_the_required_role_id | fl
I'm trying to enable service to service auth using AAD tokens. My plan is to validate "groups" claim in the token to make sure the caller is a member of a security group that we created.
For example, we will create group1 for readers and group2 for writers. Then based on "groups" claim, I will figure out the right access level.
I use AAD app to issue the tokens (not a user), so I need that app to be a member of the security group. Azure AD powershell doesn't seem to accept application ids as group members. How to solve this? are there any other recommended patterns when the caller is another AAD app?
Command used:
https://learn.microsoft.com/en-us/powershell/module/azuread/Add-AzureADGroupMember?view=azureadps-2.0
Error:
Add-AzureADGroupMember : Error occurred while executing AddGroupMember
Code: Request_BadRequest
Message: An invalid operation was included in the following modified references: 'members'.
RequestId: 0441a156-3a34-484b-83d7-a7863d14654e
DateTimeStamp: Mon, 11 Dec 2017 21:50:41 GMT
HttpStatusCode: BadRequest
HttpStatusDescription: Bad Request
HttpResponseStatus: Completed
At line:1 char:1
+ Add-AzureADGroupMember -ObjectId "9c2cdf89-b8d6-4fb9-9116-7749adec85c ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Add-AzureADGroupMember], ApiException
+ FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.AddGroupMember
Unfortunately, you cannot add an application as a member of Azure AD group.
Though the official document for the Powershell cmdlet Add-AzureADGroupMember doesn't make clear you cannot use Application's ObjectId as the RefObjectId, absolutely you cannot use it.
You cannot add an application as a member of Azure AD group neither.
For example, we will create group1 for readers and group2 for writers.
Then based on "groups" claim, I will figure out the right access
level.
For your scenario, I'm afraid that you couldn't achieve this for now. I understand why you need this. According to your request, my thought is assigning your application from Enterprise Application to Groups or users and manger users with different access rights. However, you cannot choose more roles for the selected group. The only one role is default access If want to define more roles for the app, you can refer to this documentation.
I also tried to use Azure AD RBAC and create new conditional access for my test app,but all don't have read only this choice.
You can also put your idea in Azure Feedback Forum, azure team will see it. Also, I will upvote your idea.
Update:
Currently, you can add a service principal to an AAD Group:
Example:
$spn = Get-AzureADServicePrincipal -SearchString "yourSpName"
$group = Get-AzureADGroup -SearchString "yourGroupName"
Add-AzureADGroupMember -ObjectId $($group.ObjectId) -RefObjectId $($spn.ObjectId)
Updated 2:
Recently, I also see lots of users want to assign roles to a service principal to let the service principal have some permissions to access to the app with a role.
I want to make clear here. Role-based authorized should be used for users, NOT applications. And it's not designed for applications. If you want to give some different permissions you may consider to assign application permissions to your service principal instead.
You can expose your Web App/API with application permissions by editing the Manifest in app registrations.
You can go to Azure portal > Azure Active Directory > App registrations > Select your App > Manifest.
In appRoles, you can insert content like this:
{
"allowedMemberTypes": [
"Application"
],
"displayName": "Access to the settings data",
"id": "c20e145e-5459-4a6c-a074-b942bbd4cfe1",
"isEnabled": true,
"description": "Administrators can access to the settings data in their tenant",
"value": "Settingsdata.ReadWrite.All"
},
Then, you can go another app registration you want to give permission > Settings > require permissions > Add > Search the application name you want to access > Choose the application permission you created before.
Therefore, your sp can obtain a token with that application permissions in token claims.
Also, for authorization from the resource, you need to add code logic to give control policy for that token with Settingsdata.ReadWrite.All claim.
Update 3
Currently, you can add the service principal to one AAD Group directly in Azure portal:
Following Update 3 in the answer of #Wayne Yang, I've successfully implemented this using C# and the MS Graph SDK.
But I think the same should be possible using Powershell and simple REST API calls.
// create new application registration
var app = new Application
{
DisplayName = principal.DisplayName,
Description = principal.Description,
};
app = await _graphClient.Applications.Request().AddAsync(app);
// create new service Principal based on newly created application
var servicePrincipal = new ServicePrincipal
{
AppId = app.AppId
};
// add service principal
servicePrincipal = await _graphClient.ServicePrincipals.Request().AddAsync(servicePrincipal);
// add service principal to existing security group
await _graphClient.Groups[groupId].Members.References.Request().AddAsync(servicePrincipal);