I'm trying to manage multiple outlook calendars using a single account as a proxy, so all other accounts share their personal calendar with this "master" account and within this one i can add, edit or delete events "for everyone".
The problem is that i can't get the account grant the Calendar.ReadWrite.Shared to the app, even though that in my app this permissions are configured as recommended.
Azure portal - app permissions:
permissions of the app in azure portal
msalconfig:
msal configuration used
The "funny" thing is, with the account used to create the app in the first place everything works, but with any other account not.
I even created another app with the intended final account and nothing. This is the, incompplete permissions, resul:
actual result
This is the desired result:
desired result
If you just want to make a proxy to modify calendars for all users, have you tried application-only Auth and grant Calendars.ReadWrite permission with application type to it? Based on this permission official comment: Read and write calendars in all mailboxes which seems to meet your requirement.
Related
TL;DR
To grant admin consent to a newly created single-tenant app I need to know its Service Principal Id. Is there a way of getting the Service Principal Id of a newly created app registration when it is not listed in the results from a call to the MS Graph API ServicePrincipals endpoint?
I am using the Microsoft Graph Beta SDK to add functionality that enables users of our application to create and maintain SDS Sync Profiles.
I have a multi-tenant app registration which, given user consent, enables me to create a single-tenant app registration in the user's tenant using the graphClient.Applications.Request().AddAsync({application}) method. The process I have works fine and the single-tenant app registration is created with the necessary permissions but these require admin consent. Currently I am sending users to the adminconsent endpoint: (https://login.microsoftonline.com/{tenantId}/adminconsent) where the user can grant the necessary permissions. This is also working fine but it requires the user to log in again, having already logged in once to grant consent to the multi-tenant app. This is clearly not great from a UX point of view so I would like to avoid the necessity of the user having to log in again if possible.
I came across this post: https://winsmarts.com/how-to-grant-admin-consent-to-an-api-programmatically-e32f4a100e9d which explains how to grant the admin consent programmatically . This involves creating an oAuth2PermissionGrant object with the scopes listed that admin consent is required for.
The issue I have is that in order to add the oAuth2PermissionGrant I need to know the Service Principal Id of the single-tenant app registration just created. However, when I make a call to the Graph API to list the Service Principals (graphClient.ServicePrincipals.Request().GetAsync()) the single tenant app registration is not listed, so I have no way of getting the Service Principal Id and thus cannot create the oAuth2PermissionGrant.
Once I grant admin consent to the permissions on the single-tenant app registration, either manually in Azure AD or via the adminconsent endpoint, the single-tenant app registration shows in the results from the call to ServicePrincipals endpoint.
Additionally, if I haven't granted admin consent, and just make a call to any Graph endpoint, and, when (having logged in again) the grant permissions page is shown, I don't tick the "consent for my organization" box, the permissions remain (as expected) in "require admin consent" status, however the single-tenant app registration now shows amongst the Service Principals list.
Sorry for the long question but any advice would be most appreciated.
Thanks
David.
However, when I make a call to the Graph API to list the Service Principals (graphClient.ServicePrincipals.Request().GetAsync()) the single tenant app registration is not listed, so I have no way of getting the Service Principal Id and thus cannot create the oAuth2PermissionGrant.
That's because a service principal is not created automatically when you create an application through the APIs or with PowerShell. Azure Portal creates it for you at the same time when using it for convenience, but the raw APIs don't do that. You need to create the service principal, the only mandatory parameter is the appId (your app id/client id) if I recall correctly. Here is the documentation page for that: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-post-serviceprincipals?view=graph-rest-1.0&tabs=http
Once the service principal has been created, you should be able to create the oauth2PermissionGrant objects that grant the permissions you want for all users in your directory.
I have created an Azure AD app registration for a cross-platform (Xamarin.Forms) mobile application for our employees. The app registration is setup to work as a single-tenant app and in order to function properly, we have specified a number of permissions to Microsoft Graph, such as "openid", "profile", and "User.Read", which have been given admin consent by our Admin. The app uses broker authentication (using ADAL) in order to sign-in users to the app via the Intune Company Portal app already installed and setup on every user's device.
Up until recently, everything worked fine until we needed to add a new Microsoft Graph permission to the app registration, namely "Group.Read.All". So, we added the new permission to our app registration as a delegated permission and had our admin provide the admin consent for all the users.
After giving consent to the new permission, our users could not login to the app since the Intune Company Portal app did not sign-in the users to the app, but instead advised them to setup their device by installing and setting up the Intune Company Portal app on their device (?!).
As I mentioned before, the devices already had Intune Company Portal installed and properly setup on their device for more than 2 years now.
So, we thought of checking the user sign-ins of the user to find out what the problem was and we found a failure event recorded with sign-in error code 530003 (Access has been blocked due to conditional access policies.) where it showed that the policy "Access Policy: Require Device Enrollment for Accessing EOL & Sharepoint from handheld devices" failed with reason "require compliant device" (under column Grant Controls).
As soon as we revoked the newly added permission "Group.Read.All" from the app registration, our users could sign-in to the app successfully.
When we tried adding other permissions like Directory.Read.All and GroupMember.Read.All, we did not have any issues with our sign-in flow via the Intune Company Portal.
Can you please advise what it is so special about the "Group.Read.All" permission that raises the Azure sign-in error code 530003, forcing the Intune Company Portal app to require the users to setup their (already setup) device, before they can sign-in to our app?
I am at my wits' end with this one.
Any ideas?
For me it is not possible to reproduce your issue due to multiple things involved.
Few suggestions that you could try at your end:
Try isolate each component and leverage graph explorer/postman to make an API call and observe behavior.
I didn't get the need to add graph permission, but as per your use case see if there is any other least privileged permission that could get your job done, add that permission and check behavior.
Check if your scenario really demanded adding permission as delegated and if this is really supported? For e.g, below image shows necessary permssion to get the properties and relationships of a group object.
If problem still persists, consider contacting Microsoft support for your specific scenario.
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'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.
As you can see from the image, it's not letting regular users login to the application. How do I bring down this access to members? This is an azure active directory application. I can login just fine with an admin user but my regular accounts gets blocked. Note, I created the application with the regular account. I don't suppose this has something to do with it?
I've granted the app all delegated permissions. No application permissions though. I'm thinking there's something in the manifest I need to alter but I'm not sure and I've never messed with this before. So any help is appreciated.
You likely need to perform admin consent for the application. There are two ways to do this in Azure AD:
In the Azure portal, you can go into the App Registrations blade, then click on the App, click on Permissions, and hit Grant Permissions.
Construct a request to Azure AD with the extra parameter &prompt=admin_consent.
For example:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=<AppID>&resource=<Resource App ID URI>&response_type=code&redirect_uri=<Redirect URI>&prompt=admin_consent