Since Graph is a self-documenting language, I wanted to use this to my advantage and write PowerShell functions to automatically generate cmdlets based on metadata. I've got a lot of this complete, but am having problems figuring out scopes. Is there a way to find scopes? It's not stored in the metadata and the documentation doesn't have scopes listed for everything (for instance, nothing in Excel has scopes listed).
The Graph Explorer seems to request correct permissions, so that has access to this list somewhere.
It depends on which API you are looking for.
Scopes for Azure AD Graph API is at https://msdn.microsoft.com/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes.
There is a huge list for different parts of the Microsoft Graph API at https://developer.microsoft.com/en-us/graph/docs/authorization/permission_scopes.
When you first sign in to Graph Explorer, you give it these permissions:
Based on the descriptions and the link above you can figure out what the scope name is for each of the items in the list. (E.g. the first one is Mail.ReadWrite).
When you create an application in Azure AD, you configure which applications it needs access to, and what access it needs. That results in the list which the user grants access to on first signin.
Related
I am writing a .NET desktop app that uses the Microsoft Graph API to access the contents of my OneDrive for Business storage. I am logging in to Graph using my Microsoft work/school account U1, in my organization O1. Another Microsoft work/school account, U2, in a different organization, O2, has shared a folder with me. The folder shows up in "Shared With You" when I browse my OneDrive interactively in a browser, and I can make changes to the folder there. It also shows up as a DriveItem in the returned list when my app uses the "sharedWithMe" API call documented here (with allowexternal set to true).
All good so far. The problem is when I try to actually retrieve the shared folder using the returned DriveItem. I am following the guidance in the doc page to use a call like
GET /drives/{remoteItem-driveId}/items/{remoteItem-id}
to retrieve the folder, and I have the "Files.ReadWrite.All" permission. I believe I am doing this correctly in my code, because it works fine on other items shared with me by users in my organization. However, with the folder shared by U2, this call fails with an "itemNotFound" error. I don't understand why this fails. Is this a problem with my code, or some configuration that needs to be done in my organization O1, or in their organization O2, or a combination? Or is what I'm trying to do just not possible across organizations?
I have found a couple other folks who have had similar problems, but the resolutions are inconclusive: see here, here, and here. These links have suggested a couple directions:
could this be a problem with some sharing setting on the part of organization O2? Unfortunately I don't have any control over this org. But if I can give them a clear request, preferably with some Microsoft docs to back it up, I think they would be receptive. For example, does organization O2 need to add/invite my account U1 as an external/guest user to their Azure AD? I don't know for sure if they've done that.
one of the comments suggested that my app would need to be a multi-tenant app for it to access resources in another tenant. I do not want my app to be multi-tenant in the sense of allowing people in other tenants to login to it, but I do want my account to be able to access resources in other tenants that have been shared with me. I tried changing the app registration for my app to multi-tenant, and that didn't make any difference.
in the multi-tenant vein, I found this Microsoft doc, which states "In the code of your multi-tenant app, get the authentication token for other tenants and store them in the auxiliary headers. The user or application must have been invited as a guest to the other tenants." In my code I am using Microsoft.Identity.Client.PublicClientApplicationBuilder to sign my account in and get an access token, using the authority for my tenant. It sounds like my access token is only valid for resources in my tenant - how do I get a token for another tenant in my code?
Thanks very much for any suggestions, be they pointers to docs, code suggestions, etc!
I'm trying to query the Global Address List using Microsoft Graph. I've worked with and adapted the sample code from https://github.com/microsoftgraph/console-csharp-snippets-sample.git -- however, I'm still having trouble. I've seen this article -- Global Address List Graph API -- which indicates I need to use the "/contacts" endpoint. However, I don't see how this helps me when I'm using the Microsoft.Graph library. Is there some method or collection within the Microsoft.Graph library that will allow me to read the GAL?
"GAL" is a MAPI concept that doesn't really apply to Graph. With Graph, you just read the users or contacts in your company's Active Directory. By combining both lists, you come close to what you'd see in the GAL in a MAPI client.
To do that, you would list users as doc'ed here: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/user_list
Using the library, I believe this will get you started:
client.Users.Request().GetAsync();
For contacts, it's a lot trickier with the Graph library. Organizational contacts are only supported in the beta version of Microsoft Graph, which the client library doesn't support unfortunately. (See this issue for info). Michael Mainer did a write up of how you can generate your own beta version of the library if you're interested.
The info on querying organizational contacts is found here: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/orgcontact.
As of late 2021, doesn't appear to be an easy "Export Global Address List" API from Microsoft. There appear to be manual methods (e.g. using the Exchange Admin interface) but nothing programmatic.
Below is broad strokes exercise for creating an approximation (that may be sufficient for your needs). A more accurate exercise may be to export the GAL from a official client (e.g. Outlook/Outlook Web/Exchange Admin interface). Its possible that in some cases the GAL is user specific which may make GAL export concept significantly more involved.
GAL export exercise:
APIs:
MS Graph API (available via HTTP, e.g. GET/POST)
Users
Groups
Some of the above only allowed certain properties accessible by individual record query - I needed to get the whole list then iterate through each record one by one to get all needed properties.
Exchange Powershell (available via Powershell)
Get Mailbox (for flags not exposed by Graph/Users)
Get-DistributionGroup (for flags not exposed by Graph/Groups)
Azure Functions can be used to run these queries serverless/"API-ified". Azure App Registration can be used as OAuth app that can be granted the permissions to access the above. Microsoft Graph Explorer is handy for testing Graph requests.
Put it together:
Smash the datasets together and then filter out on fields. Some flags are:
hideFromAddressLists
hideFromOutlookClients
HiddenFromAddressListsEnabled
showInAddressList,
some conditions you have to manually check for, e.g.
if no provisioned plans (i.e. unlicensed)
if no email address
etc.
In outlook I can lookup all users in my organisation, including phone number, address etc.
I guess using EWS I could do the same...
With Azure AD graph (https://graph.windows.net) I can get ALL(!) properties on all (GAL) users as well - without the option to select a smaller property subset…
In Microsoft Graph (https://graph.microsoft.com) I can get all users (GAL), but not (all) properties like phone number, title etc. without an admin allows access… Why is this different (more restricted) than the other APIs ?
ex. the permission; Directory.AccessAsUser.All (Access the directory as the signed-in user)
In Microsoft Graph user is UNABLE to consent
In Azure AD Graph - does NOT require admin
Using the /me/people (in preview) in Microsoft Graph I can get all properties on a lot of users in my organisation - but not all. And I might get some users that my nearest colleague can’t (why? - is it still buggy)
Every one tell you to use Microsoft Graph but it seems to be more restricted than the old APIs
I'd be interested to know a little more about the restrictive nature that you are describing. For the most part (with respect to Directory/Azure AD), Microsoft Graph exposes the same data secured by the same permissions model as Azure AD Graph. Please see https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference#user-permissions for more details on the available user permissions and what they allow.
What you might be seeing with Microsoft Graph is the fact that when you query the /users entity set in v1.0 (i.e. GET https://graph.microsoft.com/v1.0/users) Microsoft Graph will return only a key set of user properties by default. The user entity type is pretty big, and growing all the time - it has more than 40 properties and 25 navigation properties. Serializing and de-serializing large objects, especially when paging collections can be expensive and non-performant, both for the client and for the Microsoft Graph service. Hence we return a default set. If you want other properties then you need to use the $select parameter. For example: GET https://graph.microsoft.com/v1.0/users?$select=displayName,givenName, officeLocation,postalCode,state. This is documented here: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/user_get for example, but we are working on making some improvements to the documentation in this area too. If you want to see the full set of properties exposed by the Microsoft Graph user entity type, please look at the schema here: https://graph.microsoft.com/v1.0/$metadata.
[NOTE: $select is not supported in Azure AD Graph API, so we always return the full set].
The people API - ../me/people is about the people who you (the signed-in user) communicate with most often - it could also contain people outside of your organization. Hence, the list of people is likely specific and different for each user (even colleagues). It also is not the full directory of users in your organization.
I'd also like to get to the bottom of why you are seeing a difference in terms of consent - Directory.AccessAsUser.All always requires admin consent for web apps (for both Microsoft and Azure AD Graph).
Hope this helps,
Using PHP and the Microsoft Graph API I'm fetching a user by querying:
https://graph.windows.net/<tenant>/users/<userId>?api-version=2013-11-08
This works fine, but only returns the standard fields for the user object. According to the documentation I'm supposed to be able to use $select=* to get all the user data, like this:
https://graph.windows.net/<tenant>/users/<userId>?$select=*&api-version=2013-11-08
However this gives me the following error:
{"odata.error":{"code":"Request_BadRequest","message":{"lang":"en","value":"The ability to use the $select query option to define a projection in a data service query is disabled. To enable this functionality, set the DataServiceConfiguration. AcceptProjectionRequests property to true."}}}
How can I enable "AcceptProjectionRequests"? I find nothing about this in the documentation or in other SO-threads.
The APIs you are referencing above are Azure AD Graph which is different than the Microsoft Graph APIs. It might be worth your time to have a look at the Microsoft Graph APIs and consider transitioning away from Azure AD Graph. The general guidance from the Azure AD Graph team recommends using the Microsoft Graph instead of the Azure AD Graph. You can read more about the differences and the Azure AD guidance here.
Having said that, Azure AD Graph does not support $select (as stated in the blog posting I linked to above). Microsoft Graph does support $select for doing query projections (see Microsoft Graph or Azure AD).
Currently (as of 7/8/2016) Microsoft Graph supports most of the directory features that Azure AD Graph supports, but not all. In some cases, Microsoft Graph supports functionality that is not in Azure AD Graph (such as ability to make $select projection queries).
Per OData spec, $select=* can either return all entity properties or a default set of properties (provided the default set contains all key properties). The Microsoft Graph implementation is the latter and it will return a set of key properties. In order to get all the necessary properties you need, you will need to explicitly request the entire list you want unless they happen to be within the default set.
https://graph.microsoft.io/en-us/ seems to be built on top of the Azure AD graph - https://graph.windows.net/
I haven't found a lot of how graph.microsoft.io was built, but it seems like it is a superset of the original Azure AD API, together with the stuff to access data from Office 365 through the graph.
What stands out to me is that either they would have passed through queries from graph.microsoft.io to graph.windows.net or they would have rebuilt it all from scratch. So, I'm trying to understand how to build my own such graph. I will use Azure AD, which will enable my authentication and authorization. It will give me a graph of the users in my organization. But for custom applications that also use Azure AD for login, I would like them to be available via the graph, like how the Office 365 apps are available via the graph.microsoft.io site.
So far, to implement something similar, it seems like I can use the core Azure AD graph for a specific set of user data, and for apps that use the Azure AD instance that I provide, I can require them to implement an Odata endpoint which describes how their own data can be accessed.
Is this a good approach?
It's certainly pretty much exactly what we do, so who am I to argue. However, rather than going to Azure AD directly for the graph of users in your org, I'd encourage you to go to MS Graph for that data, as we'll be looking to add richness and functionality there rather than in the underlying AAD Graph as time marches on, and also it will enable you to link across easily to other Office apps of course.
Over time, we'd like you not to have to do this, but rather to bring your own apps' data into the Microsoft Graph in some fashion, but we are a ways away from having that facility available.