I'm trying to query 365 SharePoint list data from MS Graph.
I've setup the app via portal.azure.com and I gave it application permissions to everything that is required for User, Mail, Sites and Groups. I gave it permissions on the MS Graph and SharePoint sections within the permissions.
I can query for Users and their calendar information but when it comes to Sites I get the following.
Image of Api response
We have the Azure AD Premium P1 subscription for Education.
I tried using the same tenant ID, Client ID and secret in Postman and I get similar results.
I tried to query for the same data via myself logged into Graph Explorer and I get the data I'm expecting.
How can I query for the data from SharePoint via the app credentials for all sites and all data in my tenant
Thank you.
Users may be unable to access multiple Microsoft 365 services, any service that leverages Azure Active Directory (AAD) may be affected. Microsoft is working on this issue actively.
Microsoft 365 Service health status
Related
im trying to access my onedrive from an azure ML script , both using same account ( though the azure one is personal while the onedrive one is work ) . The connection succeeds but then gives a 400 error...any idea why ? thanks
----------------
Authenticated!
Client Error: 400 Client Error: Bad Request for url: https://graph.microsoft.com/v1.0/drive/root | Error Message: Tenant does not have a SPO license.
--------------
from O365 import Account
credentials = ('client id xxxx 6fb8a4', 'secret value xxxxx v6Hyoa2K')
account = Account(credentials,auth_flow_type='credentials',tenant_id='87xxxxx8-3db7f7',main_resource='myemail#email.com')
storage = account.storage()
if account.authenticate():
print('Authenticated!')
my_drive = storage.get_default_drive()
root_folder = my_drive.get_root_folder()
# iterate over the first 25 items on the root folder
for item in root_folder.get_items(limit=25):
if item.is_folder:
print(list(item.get_items(2))) # print the first two element on this folder.
Client Error: 400 Client Error: Bad Request for url: https://graph.microsoft.com/v1.0/drive/root | Error Message: Tenant does not have a SPO license.
The error you are getting for that you need to notice the couple of things. Please check the points stated in this stackover flow reference which says,
Office 365, Azure Active Directory, EMS (Enterprise Mobility Suite), personal Outlook, personal OneDrive, and other Microsoft cloud services are all accessible through the developer portal or API known
as Microsoft Graph. The API is free to use, but in order to access the
data it hides, you must have those services, some of which may be free
and others of which you may have to pay for.
Regarding integrating Office 365 into your current tenant. I believe
you used a Microsoft Account to join up for Azure. For that tenant,
you can still buy or acquire Office 365. You may have to add a
new Azure AD user to your tenant (not a Microsoft Account) and give
them company admin privileges. Whether it asks if you already have a
tenant or account, login in with the AAD account you just generated.
You should then be able to sign up for Office 365. And there you have it an Azure AD tenant with both an Azure AND an Office 365
subscription.
Solution : You must be using an Office 365 Home license for you azure ad tenant. For SharePoint Online you need an Office 365 Business account .
You need a license that include all the OneDrive service (Operation). So, recommendation is Office 365 Business Essentials which is the cheapest and has Microsoft Graph functionality - more than just upload/manipulate Excel files in OneDrive in future.
So from the above conclusion, you can't use the Microsoft Graph API to access OneDrive data(read and upload) without having SharePoint Online (which only comes with the business licenses).
Reference:
SO thread by Allen Wu
I am running into an issue with having the user data for the mobilePhone attribute update and show up for our users' contact cards which run on the SPO/Delve platform. Does anyone know of a way to have the data sync?
To update Azure AD mobile phone attribute to SharePoint online, try making use of below steps:
Make sure to have the below modules installed before running the
PowerShell script
Azure Active Directory (AD) Module
SharePoint Online Module
MS Online Services Sign-in Assistant
Office365 CSOM package
The user must be a global admin on the SharePoint User Profile Application as well as a Service Admin on the Azure tenant.
To connect to PowerShell, make sure the user account must not be configured to MFA.
To get all users, make use of below query,
$AzureADUsers = Get-MSolUser -All
To overwrite existing values, make use of below query,
$overwriteExistingSPOUPAValue = "True"
To know how to do it in detail, please find below reference by Raymond Tishenko
Sync Mobile Phone from Azure Active Directory to SharePoint Online using PowerShell (tishenko.com).
After executing the script, you can see that values are successfully copied from Azure Active Directory to SharePoint.
I am using Azure Graph API Explorer. I want to query the apps list in a tenant. I am user in tenant_x (where user was originally created) as well as admin in tenant_y (created later with my user). I understand that when I log in I go directly in the origin tenant (so tenant_x) therefore Graph Explorer does not allow me to query tenant_y. So as admin of tenant_y I have added a new user in tenant_y. I log in now with that user but still I am not able to query the applications that are in tenant_y. So how can I query apps in tenant_y? Is there a way? thanks.
The API I am calling (with new user log-in) to first retrieve all applications:
https://graph.microsoft.com/beta/applications
Response is:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#applications",
"value": []
}
Of course I have apps in that tenant.
Based on our communication, you have used a personal account as guest of tenant_y to query the apps list in tenant_y.
Unfortunately, Microsoft Graph Explorer will not recognize your personal account as a guest user. It will still treat it as a personal account.
So it will query the apps list for the personal account rather than tenant_y.
So now you have two choices:
Create a new user in tenant_y by following add a new user and
then use this new user to log into Microsoft Graph Explorer to query
the apps list.
Implement Get access on behalf of a user and make sure that you
call {your tenant} endpoint rather than common endpoint while
requesting the access token. And you should use another tool (for
example Postman) instead of Microsoft Graph Explorer.
Update:
You can modify the permissions in Microsoft Graph Explorer like this：
Click on the "modify permissions" under your username in Microsoft Graph Explorer and check the Directory.Read.All permission.
Today that's possible if you pass the tenant query string parameter like this:
https://developer.microsoft.com/en-us/graph/graph-explorer?tenant=mydomainname.onmicrosoft.com
Note that you need to logout before going to this URL with the tenant query string. It'll ask you to login again. After login you can issue queries against the other tenant you have access to (not your home tenant where your account was originally created on).
If you get a 401 while running the specific query, make sure you grant the required permissions on "Modify permissions" tab and click the Consent button in each required permission. After that your query should return a 200 success result.
Graph Explorer today does not support signing in to the tenanted endpoint. A tenanted endpoint is used in the following format
https://login.microsoftonline.com/{tenantId}/V2.0
Once your user account from tenant_x is made a guest user in tenant_y, to effectively query tenant_y using your guest user account, an app (like Graph explorer) has to sign you in the other tenant. Instead Graph Explorer uses the /Common endpoint, which will always sign you in your home tenant (tenant_x).
The only available workaround is to develop a application quickly and sign-in to a tenant of your choice and run Apis in it.
Graph explorer is a tool to help developer's discover and learn about the Graph Api and thus might shy away from introducing too much complexity. But it does not hurt to ask for this feature at their Github repo.
Recently Microsoft published the Microsoft Search API (beta) which provides the possibility to index external systems by creating a MS Graph search custom connector.
To achieve this I created 2 Search Custom Connectors:
one according to Microsoft Graph Search Connector Sample from GitHub
and one on my own, step by step according to the official MS instructions
Create the Connector app in Azure
Add app registration (Single tenant)
Add required API permissions and give admin consent
Add a client secret
Get access token (via Postman)
Get the required parameters from app registration
Submit a login request to get the (bearer) token
Create a new connection (via Postman)
Registering a schema (via Postman)
Add items to the search index (via Postman)
Both variants worked well so far but if I now try a search (for example via Bing (activated for our O365 tenant, or in the Microsoft Search Center, logged in as the appropriate account) no results from the custom connectors are shown.
Via Graph Explorer, logged in as the appropriate account and using the query https://graph.microsoft.com/beta/search/query, I get an http status 500 ("InternalServerError", "The call failed, please try again."): Screenshot from Graph Explorer
Under > Microsoft 365 admin center > Microsoft Search > Connectors both connectors are displayed but there is displayed neither any status nor any successful synchronisation: screenshot from MS 365 Search admin center
I know the Microsoft Search API in still in preview but I wonder if it works at all?
Is there any possibility to trigger the synchronisation manually?
Or at least find out what's going wrong here?
Did you create a new Result Type and Vertical as well in the Search center?
I followed the steps mentioned in the sample and the search works for me in Office 365.
Regarding the synchronization, I don't think that is available in the Search center as of now because there is no option to edit the connection or set any synchronization schedule. However, I'm still exploring other options to synchronize as its quite new to me.
As a follow-up question to REST API to manage users on skype for business, I would like to understand how the Sharepoint Server User API differs from MS Graph API for Users. The Graph documentation indicates that we could use it to manage Sharepoint users the same way we would Office 365 users. However, there are standalone Sharepoint installations (like versions e.g. 2007, 2010, etc.,) which don't fall under Office 365 plans.
The Graph API Docs linked above says the User resource represents an "Azure AD user account". However, the Sharepoint User doc says it represents a "user in Microsoft SharePoint Foundation." Are these users entirely different from each other?
All we're looking to do is manage users for our clients some of whom have subscriptions to Office 365 and some who just use standalone Sharepoint setup. We are not bothered about application specific features like Accessing the sharepoint files, sites or even managing Word documents, Excel sheets, etc., So, does the Graph API support managing users in such cases as well?
That API is only for SharePoint 2013+
The user management REST API linked in your question is specifically for SharePoint 2013, and presumably works in SharePoint 2016 as well. This is regardless of whether the SharePoint environment is on premises or in the cloud.
Office 365 is currently a subset of SharePoint 2013/2016 in terms features and functionality.
Note that SharePoint 2007 and 2010 will not have this API.
SharePoint users and Azure AD accounts are not synonymous
Consider that SharePoint and AD can exist independently of each other.
SharePoint does not need to use Azure Active Directory for authentication. It can use a traditional on-premises or cloud-hosted Active Directory, or theoretically (starting with version 2010) can use any claims-based authentication provider aside from Active Directory.
SharePoint 2007 and 2010 could also support simple forms based authentication as well as custom authentication providers, but as noted previously, neither of those versions of SharePoint expose the REST API in question.
AD = Authentication; SharePoint User = Authorization
Azure AD is a claim provider. A claim provider is used for authentication; when you log on to SharePoint, SharePoint relies on Active Directory to determine that you are who you say you are. A user's SharePoint account is used for authorization; the SharePoint account is granted access to content within SharePoint on a site by site basis.
Information in AD vs information in SharePoint
When using Azure AD for authentication, there are usually some areas of overlap between the data in SharePoint and the data in AD.
SharePoint's user profile service is usually set up to synchronize data from Active Directory to SharePoint, so that AD serves as the master data set for things like user display name and title. However, not all information is necessarily sync'd from AD to SharePoint, and additional information can be tacked on to SharePoint user profiles.
Group Membership in AD vs Group Membership in SharePoint
In Azure AD, a user can be a member of multiple groups. Groups can include both Active Directory groups (which can be nested) and Office 365 (SharePoint) groups (which cannot be nested).
A SharePoint user can only be a member of SharePoint groups, since SharePoint does not keep track of membership of Active Directory groups. That said, a user may have access to content in SharePoint indirectly due to an Active Directory group having been granted access.
AD User Scope vs SharePoint User Scope
Unless you're working directly with the user profile service, when you work with SharePoint users programmatically, they need to be retrieved from a specific site in SharePoint. This is because each site collection has its own set of groups which cannot be used on other site collections within the SharePoint farm, so group membership is tracked only on a site-by-site basis.
Note that this means that a user's lookup ID number (which is different from their login name) may vary between site collections. This also means that a user's collection of groups will vary depending on the site from which the user object was retrieved.
An Azure AD user has no such silos.