I am currently developing a service that would be able to sync data between workforce management systems (like Kronos WFC) and Microsoft Shifts. In order to sync the data, I have to register a Workforce Integration. I have established the necessary permissions, but I am not able to add permissions and I'm returned a message on the Azure Portal that permissions are not supported. The tenant that I'm using for development has also been whitelisted. Ideally whitelisting should be solving all problems when it comes to adding Graph API scopes, but in this instance, the whitelisting does not seem to resolve. Any ideas as to why such thing is happening?
Some Graph permissions are not allowed on applications that support Microsoft accounts authentication (e.g. Skype, Xbox, Hotmail). The WorkforceIntegration permissions are one of them.
The idea is that some O365 enterprise services are not available to consumer Microsoft accounts. Unfortunately I don't know where these permissions are documented but please comment if you find the list.
Sometimes, it could be a temporary error. You may have another try at a later time.
Please do not add too many permissions at one time. I tried to add that permission and got a success:
By the way, as Azure AD V2 supports to grant permission dynamically. You may directly add and grant permission to a new scope.
Note: I just want to show you the detailed flow, but in fact all the
following steps can be done with ADAL or MSAL.
For example:
I did not have https://graph.microsoft.com/Chat.ReadWrite permission at first. But I can request that permission dynamically through Azure AD OAuth2 authorization code flow:
A. Make a request call to
https://login.microsoftonline.com/<your_tenent_id_or_name,hanxia.onmicrosoft.com>/oauth2/v2.0/authorize?response_type=code
&client_id=88b1****-***-****-****-f64c****9f8a
&redirect_uri=https://localhost/
&scope=https://graph.microsoft.com/Chat.ReadWrite
B. Grant the permission
C. Check the permissions in Enterprise Application
You can see that a new permission was added. And then uses in the tenant can use that permission scope.
Related
TL;DR
How can I delegate my user permissions to a service principal in Azure Ad when the usual interactive way (e.g. web app with consent screen popup) is not feasible? This is because I cannot configure the MSI in the Azure Portal properly to work that way.
More detail
I want to grant an application permission to access the Graph API on behalf of a user. Usually, this is a well-documented scenario in which you create an app registration, acquire delegated user permissions by asking permission for the needed scopes, and then use these permissions in the app.
The app that needs Graph access is a background service that is to work on its own without user intervention/activity. For this use case, the common approach is to use application permissions. In my case this is not feasible, because application permissions require admin-consent and are all-or-nothing kind of permissions. There is no way this will be granted for me. Rightfully so, because its overkill.
But on the other hand that's really a pity. A pity, because I've found an example on how to assign Graph API application permissions directly to a Managed Service Identity rather than to a self-registered app. And my service (as an Azure Functions app) already has a MSI assigned to it. So this would be the perfect fit, b then again, there is no way I'll get those application permissions.
So what is the workaround? We have this one user principal which has all the required permissions we need for our background service. What I want to do is to delegate this user's permissions to the Function App/MSI. In order to do this, I used this SPA-template by the MSAL team to have something that will prompt me the permissions popup.
This however failed because the implicit oauth flow was not enabled. To remedy this, you usually need to update the app manifest in the portal. However, since this is a MANAGED service identity, and not a self-registered one, the MSI is not listed in the portal under app registrations. So I cannot set this property to true.
Doing the same via Azure CLI also failed because apparently the MSI is not identified as an app.
az ad app update --oauth2-allow-implicit-flow true --id <appId_of_MSI>
This yields the following error:
ResourceNotFoundError: Resource '<appId_of_MSI>' does not exist or one of its queried reference-property objects are not present.
It shows fine when doing this
az ad sp show --id <appId_of_MSI>
So in summary: I cannot complete the process of delegating that user's permissions interactively. Is there any other way? Maybe via CLI?
The fallback the solution is to create a separate unmanaged/self-registered app identity. But I want to really avoid this because then I would need to manage and rotate client (app) credentials again, which the MSI took care of for me.
Why o why can't I just assign fine-scoped application permissions 😒
Any help on this is greatly appreciated. Cheers.
In my experience Managed Identities don't support the scenario you are suggesting.
They do not have an app registration and in that way cannot authenticate users interactively.
I would go with your fallback solution; a normal app registration and use that to access Graph API on behalf of the user.
This is what we do in our projects at least.
App permissions -> Managed Identity if possible. Delegated permissions -> normal app registration + secret/certificate in Key Vault, retrieved with Managed Identity.
I have created Azure AD B2C Application and tried to integrate with React JS using MSAL Library , When i tried to get access token I am getting following error.
AADB2C90205: This application does not have sufficient permissions against this web resource to perform the operation
Any Help would highly appreciated.
The link provided by #Jas Suri is correct, but I need to add some more:
You need to create two applications, one representing the client application and the other representing the api application, and then use the client application to call the api application.
Next, you need to expose the api of the back-end application and record the scope name, then go to the client application to add the scope to the API permissions (you need to find it in My APIs), and grant the admin consent to the permission.
Finally, when you get the access token, you must add the scope.
You didn’t grant admin consent. Follow this:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-web-api-application?tabs=app-reg-ga
Specifically the Grant Permissions section.
I'm following a guide online to generate an access token to access Microsoft Dynamics 365 Customer Engagement: https://eax360.com/dynamics-365-online-connect-using-postman/.
All of it works fine, however I am wondering why delegated Admin permissions need to be supplied in Azure Active directory during app registration. I have seen a lot of guides explain that permissions must be delegated but the above site documents the process well. As a general rule, I thought that starting with the lowest security permissions was the norm. I am new to Azure AD so thoughts are very much welcome.
If your app will be a client which allows the authenticated user to perform operations, you must configure the application to have the Access Dynamics 365 as organization users delegated permission.
Application permission means that you want your app to access Common Data Service without a user.
So whether to use delegated permission in Azure app registration depends on your needs. It is not mandatory.
But we can see that the Application permissions in Azure app registration is gray out. This is because Microsoft provides a different way to implement it.
We need to create a Common Data Service application user an then bound it to the registered app. After that, we could connect using the application secret. See the details here: Connect as an app.
I'm getting 403 forbidden access when trying to fetch all the groups from Microsoft graph using ASP.NET Web API, and here is my code to get all the groups:
String jsonResponse = MicrosoftGraphHelper.MakeGetRequestForString (
String.Format("{0}users/{1}/memberOf",
MicrosoftGraphHelper.MicrosoftGraphV1BaseUri,
upn));
var userGroups = JsonConvert.Deser
What are the required permissions in both Delegated and Application tabs for fetching both users and groups? Do I need Application permissions since this is an API and my UI is deployed in azure separately? I'm confused with the list of permission options and with admin consents.
Firstly, here's a great read in case you haven't seen it yet.
Delegated permissions, Application permissions, and effective permissions - Microsoft Graph permissions reference.
What are the required permissions in both Delegated and Application tabs for fetching both users and groups?
You can understand the required permissions for each api by looking at relevant documentation. With the information you've shared in your question..
For users/{1}/memberOf it will be List memberOf
For getting all groups - List Groups
If it's just these two calls in your application, Directory.Read.All would be the least privilege required. In case there are other calls, look at their documentation.
Do I need Application permissions since this is an API and my UI is deployed in azure separately?
This will depend on whose context do you acquire the token to call Microsoft Graph API. Share a little more information on your code.. OAuth flow you use to acquire token and you might get better suggestions specific to your application. In general though,
If you acquire the token as a user, then Delegated permissions (Example if you acquire token by prompting the user for credentials and from a flow perspective if you're using say Authorization code or Implict grant flow)
If you acquire the token as an application, then Application permissions (Example if you use only clientId, clientSecret/certificate to acquire token using Client Credentials flow)
Admin Consent is required or not?
This depends on what permissions you finally end up deciding as required for your application.
You can see it directly in Azure portal.. when setting required permissions fro your application, each permission has a yes or no next to it to indicate whether Admin consent is required or not. Just as example see screenshot below.
Microsoft Graph Permissions Reference.. the first link I had shared has all permissions documented. Example here is one that is relevant for you.
I have an application calling the graph api in order to update my database of users to match the active directory users.
I see that every single user calling it is getting an error. 403 forbidden. I did some research and saw that the user needs to grant directory.read... so I did that and then it works.
However, I do not want to have my application request each user to grant those permissions. I believe maybe I can accomplish the same goal by granting the right permissions to the “user” behind the application. I am not really sure who that is. Does maybe the secret and the client located in my web.config play into this? The reason I think maybe yes, is because I use those credentials to initially authenticate myself to the graph api. I do. To pass the current users Microsoft info to log in...
In that scenario, you can configure the app to use App-Only permissions. In the documentation, it is referred as "Application" permission. The permissions are granted to an application. Consent is granted only once by an administrator, and users are not prompted to consent later. More: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent