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
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.
https://graph.microsoft.com/v1.0/me/sendMail
I am trying to call sendMail in graph and received error:
Graph explorer (official site) needs permission to access resources in your organization that only an admin can grant. Please ask an admin to grant permission to this app before you can use it.
I understand that I need to ask an admin, but I don't know who to ask or what the procedure is like. My tenant is "Microsoft"
Thanks for any input!
The application requires one or more permissions which only Global Admin can consent for. There are some permissions for which standard users can provide consent but if the application needs high-level permission with which any changes can be made to the directory, the above message is displayed and only the Global Administrator can consent to those permissions.
So you would need to contact Global Administrator to provide consent. for microsoft.com tenant, you can open a request here. Please refer to a similar question it may help you
You have granted the application permission without the admin consent. The easiest way is to redirect the user to the administrator consent endpoint, then log in with the administrator account, and click the Accept button to grant the administrator consent for your application.
You need to request the URL in your browser:
https://login.microsoftonline.com/{tenant_id}/adminconsent?client_id={client_id}
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.
My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.
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.