I have registered an application via Microsoft's AAD Portal. This application is supposed to be accessed by anyone. So I have set signInAudience: AzureADandPersonalMicrosoftAccount in my manifest.
My application needs two scopes:
User.Read
OnlineMeetings.ReadWrite
When I test the application using my Microsoft developer account (which is a part of the organisation in which this application is created), I am able to consent to both scopes.
However, when using my personal email ID, I am asked to consent only User.Read scope.
Where am I going wrong?
OnlineMeetings.ReadWrite is not supported for personal accounts: https://learn.microsoft.com/en-us/graph/api/onlinemeeting-get?view=graph-rest-1.0&tabs=http#permissions
Related
Are Azure Active Directory app roles only supported for accounts in the same tenancy?
I am trying to use Azure Active Directory to authenticate users both on my tenancy, others, and social accounts, and be able to manually assign different app-level roles.
What I would like:
Users would sign up using any of these methods, and I would see them in the 'Users and groups' blade of the Enterprise Application in Azure portal (or I could invite them). I would assign app roles (roles specific to my app, eg engineer/technician/residential user) via the 'Add user/group' button.
When logging in to my app, I retrieve the app roles via idTokenClaims.roles[]
What happens instead:
This works fine for user accounts already in my Azure tenancy. But for other Microsoft accounts (eg theirname#outlook.com or MS accounts created with any email address), the user doesn't appear in Azure portal after logging in unless I manually invite them. After inviting them (and accepting the invite), I see a user like theirname_outlook.com#EXT##mytenancy.onmicrosoft.com. I can assign app roles to this user, but their idTokenClaims.roles[] is not returned.
Other social accounts (eg Twitter, facebook) seem to not be supported at all
What else I tried
I also investigated AD B2C, which gives the developer more control over the login flow, and supports other social accounts other than MS (which looks good), but it seems that doesn't support app roles at all.
Am I trying to use the wrong tool for the job?
All I want to do is support any user to sign up to my app, and for an admin to set what their app-specific roles should be.
Update
I am using the MSAL auth library, following the instructions
https://login.microsoftonline.com/Enter_the_Tenant_Id_here should be one of the following:
If your application supports accounts in this organizational directory, replace this value with the Tenant ID or Tenant name. For example, contoso.microsoft.com.
If your application supports accounts in any organizational directory, replace this value with organizations.
If your application supports accounts in any organizational directory and personal Microsoft accounts, replace this value with common.
To restrict support to personal Microsoft accounts only, replace this value with consumers.
Because I wanted this to work with any social account, I chose https://login.microsoftonline.com/common. This shows a UI that allows you to use any organisation or personal MS account, or sign up for a personal MS account with any email address. But I noticed the objectId returned for personal accounts is different to the id when I manually invite the account in azure portal. I changed to use my TenantID instead, and that worked. Personal accounts that have been previously invited via portal can log in. Other personal accounts get an error and cant log in. App roles are now returned for these personal accounts. This now partially solves my original problem, but I still have some unsolved issues:
this method shows a slightly different UI that doesn't allow the user to sign up for a new MS account in this flow
I still can't use other oauth accounts eg Twitter/Facebook. Do these not support app roles at all?
the instructions quoted above seem incorrect, clearly it is possible to log in using "accounts in any organizational directory and personal Microsoft accounts" via TenentID, not common, once they've been invited to the app
App roles absolutely support guest accounts. But as you can see, the id token of the guest account does not seem to contain the roles claim, and it is not clear whether this is by design. But the roles claim will appear in the access token.
I think an access token you can be used, and the access token also contains user information.
I have created an multi tenant with Personal account application type and set the "user assignment required" to yes on the service principal in the tenant
But this flag is ignored by Personal accounts during Login. Is this how it is supposed to work?
Although there seems not to be an official document about this question, "user assignment required" feature should only be available to the AAD tenant rather than personal Microsoft account.
We can only assign AAD users (including guest users) to the app. But we cannot do this for a personal account.
If there is a place where we can assign personal accounts to the app, it must be a tenant internally used by Microsoft to manage personal accounts. Obviously we have no access to that tenant(if it exists).
So now that we choose “multi-tenant with Personal accounts” application type, this Azure AD application should be available to any Personal accounts. They won't be restricted by "user assignment required" feature.
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 am trying to read and write Birthday and Hiredate user properties using Microsoft graph API. I configured below app and delegated permissions.
I am getting access denied error as a normal user but working for azure admin.
Delegate
User.Read, User.ReadBasic.All, User.ReadWrite, Directory.AccessAsUser.All (admin only), Directory.Read.All (admin only), Directory.ReadWrite.All (admin only),User.Read.All (admin only),User.ReadWrite.All (admin only),
App
Directory.Read.All,Directory.ReadWriteAll (admin only),User.Read.All (admin only),User.ReadWrite.All (admin only)
Please help me which permissions needed for the app to read and write birthday and hire day properties for normal users.
You cannot have both Application and Delegated scopes active within the same token. Which are used are entirely based on the OAuth Grant you've used to obtain the token. You might find this article helpful: Application vs Delegated Scopes.
You've also chosen several scopes that require Admin Consent before they can be used within a tenant. Until you've obtained this consent, normal user's will not be able to authenticate. You might find this article helpful: v2 Endpoint & Admin Consent.
In terms of scopes, in order to read a user's profile (which holds those properties), you should only need User.Read. You can, and should, remove all of the other scopes you're requesting. When it comes to permission scopes, more is never better.
Note: both of the articles I mentioned above were written by me. Also, while they deal with the v2 Endpoint, the concepts in them apply to both AAD v1 and v2 OAuth endpoints
I am developing a multi-tenant Office 365 daemon that requires access to user calendars.
I have successfully registered in the company tenant (Tenant1) that has deployed this app using certificates and I am able to get access tokens.
Now I created a separate AAD tenant (Tenant 2) and logged in to daemon app using administrator account of Tenant 2, it prompted the Admin Consent screen and I provided consent. There was no errors returned.
When I tried to get an app token however, I am able to get a token but with blank permissions. If I call the Office 365 API using this token, I get a 401.
I was of the view that service principal objects should be created. Also I am unable to see this app in Tenant 2 app registrations.
Do all my consumers have to register this app manually in their AD tenant and modify application manifest file to add certificate details?
I am not sure about the benefit of multi tenancy if that's the case.
I found the follow in the Azure Active Directory documentation:
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
Adatum - the tenant used by the company that developed the HR app
Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
You do not need to have each tenant register your application. In fact, you shouldn't since having dozens (or hundreds) of unique App IDs floating around would only create headaches for you.
Each tenant does however need to execute the Admin Consent workflow. This will authorize the App ID you've registered on your end to access the scopes you've requested.
Generally, I recommend using the v2 Endpoint and the apps.dev.microsoft.com portal for registering your app. While you can also register your app in your own Active Directory, the portal makes it a lot easier to manage.
The general process is:
Register you application in the Registration Portal
Populate the "Application Permissions" in the Microsoft Graph Permissions section.
Launch the Admin Consent workload using https://login.microsoftonline.com/common/adminconsent?client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Get a beer
A couple of tips:
The Registration Portal only supports MSA (i.e. personal) accounts at the moment. I'd suggest creating a new Outlook.com account for this purpose so you can easily share the credentials with folks who need them internally.
If you create a shared Outlook.com account, you should also set up forwarding rules for all of the interested parties internally. This is in case something should every go wrong or change down the road and you need to recover the account.
I wrote a v2 Endpoint and Admin Consent primer that you might find helpful. They assume you're using the Authorization Code flow but the concepts remain the same for Client Credentials.