We're getting a 400 error with the message "Tenant does not have a SPO license" when we try to access the Sharepoint-endpoints in the Microsoft Graph v1.0 API.
We've registered our Azure AD app and assigned Application Permissions (as opposed to Delegated) for the relevant endpoints, as we need to access the endpoints server to server (ie. outside the context of an authenticated user).
The tenant is connected to an Office 365 Business subscription, that we can assign to users, but the tenant in this case is the directory itself and we don't see how we can assign a subscription to that.
It seems there is precious little information available regarding this, and most of it applies to the delegated permissions scenario.
Any help would be greatly appreciated.
If you have purchased an O365 Business subscription, you may still need to be assign SPO (SharePoint Online) license for specific AAD user/ O365 user.
Use your admin account to log into O365 admin center and select a user and assign SPO license.
After clicking on "Edit", you can choose a SharePoint license to assign it to the user.
Related
I'm not able to access any tabs in AAD. What could be the issue?
Please check if below points can be worked around in your case.
Buttions or options being greyed out maybe because , you may not have had global admin rights/user administrator rights on the azure AD tenant. There are a few roles which can create users within the directory. You may not have any roles within the directory which permit the operations.
Reference: github issue.
Even in Azure AD free edition ,one should be able to create the users if you have proper roles .
On completion of the first 30 days of Microsoft Azure’s free trial,
your ‘Free Trial’ Azure Subscription will be disabled. To fix this,
the subscription needs to be changed to the ‘Pay-As-You-Go’ plan
instead of the ‘Free Trial’ plan which it is currently on.
For example :For applications under Enterprise application, one of the following roles: Global Administrator, Cloud Application
Administrator, Application Administrator, or owner of the service
principal.
You can check Azure AD built-in roles, and by checking the
description of role , assign the required one to manage identity .
You can Assign Azure AD roles to users to manage the identities
if you have global or role administrator rights. Approach the
admin to assign the roles .Also see custom roles in Azure AD
if needed.
Please check if this issue in - Microsoft Q&A can relate .
If issue still remains you can raise a support request in troubleshoot+support blade.
We have an application which parses the Audit Logs emitted by Azure AD. More specifically we are parsing the 'Update application' log to detect when a new Role has been added to an Application (see example below).
We would like to find out more information about the "DirectAccessGrantTypes" and "ImpersonationAccessGrantTypes" fields. If someone can point us to documentation for this that would be great.
[{"EntitlementEncodingVersion":2,"EntitlementId":"654a4f1f-1b7f-4354-a6d6-fcf7346af0ec","IsDisabled":true,"Origin":0,"Name":"Data Manager","Description":"Manager for test app","Definition":null,"ClaimValue":"DataManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"3d03256d-cf0c-4553-b8af-98d7ebbee1f2","IsDisabled":false,"Origin":0,"Name":"Application Manager","Description":"Admin for test app","Definition":null,"ClaimValue":"ApplicationManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"88d0d3e3-b661-4760-aea3-f4548db1ff96","IsDisabled":false,"Origin":0,"Name":"Read","Description":"Allow users to add a admin consent","Definition":null,"ClaimValue":"Read","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[],"ImpersonationAccessGrantTypes":[{"Impersonator":29,"Impersonated":20}],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]}]
From article > View reports & logs in entitlement management - Azure AD | Microsoft Docs
When Azure AD receives a new request, it writes an audit record, in
which the Category is EntitlementManagement and the Activity is
typically User requests access package assignment. In the case of a
direct assignment created in the Azure portal, the Activity field of
the audit record is Administrator directly assigns user to access package, and the user performing the assignment is identified by the
ActorUserPrincipalName.
Application Impersonation is basically an administrator-managed, not user-managed permission.
Impersonate access grants logs gives information ex:count., of users given consent by the admin to access the application to impersonate user.
ImpersonationAccessGrantTypes gives count or info of access grants by admin on behalf of user whereas DirectAccessGrantTypes gives info about the users who directly access the application ,as they are already assigned by admin.
Reference:
Multiple Client applications authorisation to WebApi (microsoft.com)
I have registered an app in AAD and as a admin I want to provide permission for user to read or access the data of particular group list not all group available in my MS team account. How can be achieve this any idea?
No. Azure AD app doesn't provide such a feature that scopes Microsoft Graph application permissions to specific Microsoft Teams/Groups.
The client credential flow is used to as an authorization grant typically when the client is acting on its own behalf. When you give Group.Read.All or Files.Read.All or other similar application permissions, it means the client has access to all the files/groups across the entire tenant.
You can achieve this by implement the business logic in your code. For example, providing a configuration file which includes the particular groups'/teams' object ids. And then restrict the access for users to only these groups/teams by checking if the object ids (which users are trying to access) are in the configuration file.
When I log onto the Microsoft Graph Explorer with my Microsoft account and run the following query https://graph.microsoft.com/v1.0/users/ I get the correct user returned.
On Azure AD (using the same login) I created an application with a key and when I sign in through c# using Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredentials with a token for resource https://graph.microsoft.com and run the same query I get a completely different user. They are out of sync and I'm baffled.
Any ideas? Should I create a new Azure account as I've had the Azure account from day 1 and I'm only doing this now to test for a client request.
Don't create a new Azure account. When you are using Graph Explorer, are you signed in with a user from your Azure AD tenant? If not, Graph Explorer will default to use a demo tenant for your queries.
Also (if you have more than one tenant) you need to make sure that you select the correct tenant as part of the token acquisition (from https://login.microsoftonline.com/{tenantId | tenantDomain}. If you want the results to match between Graph Explorer and your app, the tenant the signed-in user belongs to (for Graph Explorer case) and the tenant used by your app needs to be the same.
UPDATE based on comment below:
I think I know what's going on here. In graph explorer, you are signing in with your personal account - and it's showing you profile data of that personal account, including the unique ID for this account in the Microsoft Account system. In this case you aren't signing into an Azure AD tenant at all. Microsoft Graph supports access from both personal and commercial accounts.
Now, additionally, I'm guessing when you signed up for an Azure subscription, you used this personal account. When you do that, it creates an Azure AD tenant, and creates a guest user in that tenant that is (linked to) your personal account - this account is also configured as an admin account. This mechanism allows you to sign in with your personal account (authenticated by the Microsoft Account system) into an Azure AD tenant, because the personal account maps to this guest user in your tenant. In your application, you are getting an app token to your Azure AD tenant. When you query the tenant for users, you don't see any user with the same id or email address as you did with graph explorer. However if you actually look at the userPrincipalName, you'll see it should be a mangled form of the original email address of your personal account. This indicates that this Azure AD user account in your tenant is a guest/external user (similar to a foreign principal).
Hope this helps,
I am using a visualstudio account in Azure. i have created a new user and given admin access to the active directory to this user. I also added this user as the owner to the subscriptions i had.
I now login as this into the new portal. I can see the subscription that i have. However i do not see the icon for Azure ActiveDirectory. Therefore i try to login to the old portal. This time I get stopped by a "No subscriptions found" prompt which does not let me for farther.
What is going on? why is there such discrepency between the two sites?
The classic (i.e. old) site only works with the old access model (service admin and co-admin), and requires at least one subscription to get into the site. The new site uses the fine-grained RBAC model (owner, contributor, etc...), and does not require any subscription just to get in to the site.
Adding a user as an 'Owner' in the new Azure portal does not make them a co-administrator, and thus, does not give them access to the classic portal:
The owners you added through the Azure portal cannot manage services in the Azure classic portal.
In order for your new user to get into the classic Azure portal, they need to have service admin or co-admin access to an Azure subscription. You can do one of the following:
Add the new user as a co-admin to your existing subscription (you would do this in the classic portal)
Make the new user the service admin for the subscription
Transfer the entire subscription to the new user (which also makes the new user the account admin)