Is there a query or data element accessible using the Graph API that will allow you to distinguish a shared mailbox from a normal user in o365? I normally want to only sync users if they have certain licenses but also include shared mailboxes (which do not require a license).
A User and a Mailbox are two different things. A User is an account managed by Azure Active Directory, a Mailbox is an email destination managed by Exchange Online.
If you're asking how to determine which users have access to a given mailbox, this is not available through Microsoft Graph. You would need to use a different mechanism to determine a mailboxes configuration; the most common being Exchange Web Services or PowerShell (which is most likely using EWS behind the scenes).
Related
I have multiple Office365 private groups that I created using Outlook. I would like to be able to list, add and remove users using a Python script (or any other language). I am familiar with Microsoft graph API, and I have used it before.
I tried to use the graph API to manage the groups, but the permissions required to manage the group (Group.ReadWrite.All, GroupMember.ReadWrite.All) need an administrator's consent to be used. I cannot get admin consent within my organization, so is there another way to achieve this?
Microsoft Graph API has support to retrieve mail rules for individual mail boxes. Is there any API to get the list of rules configured by Admin for the organization?
https://graph.microsoft.com/v1.0/users/user-id/mailFolders/inbox/messagerules
Not that i am aware of using Microsoft Graph API. At this point Graph API supports only individual mailboxes. The closest one i can see is that you can application permission to query other mailboxes as well. But it won't tell or get you the list of rules configured by admin for the organization. Being said that you can consider filing an uservoice so that it can be considered to be implemented. As an alternate you can use from Exchange PowerShell (something like Get-Trasportrule).
I am working on a service that logs into JIRA and performs few operations that are not associated with a particular user. Right now, I'm using a virtual account and authenticating the JIRA by the accounts username and password. The use case requires a significant number of such services to be created. The current solution will be messy to maintain, because I need to keep a track of service level logs, which will require creation of a large number of virtual accounts, whose management is difficult. Is there a service account like concept in JIRA that allows a service to perform authentication as an application like on Google cloud?
Their reference about the REST API.
I played with it once, remember it requires API key or token maybe.
Service or daemon authentication to the Microsoft Graph grants access to a limited number of functions.
For example, to be able to work with Planner and tasks, you have to be logged in as a user. In other case, we can't access most of user details, we can't access user's files and so on.
Why service or daemon must have more permissions then now? In our case, service should automatically create Planner tasks and Calendar events for specific users or groups according to automatically registered events. Sometimes it should also create or add or read files in OneDrive of this user. Also automatically, of course. Due to Microsoft Graph restrictions, it is easier to use additional 3rd-party service to track tasks, or even write our own. The same situation with files.
Microsoft Graph looks like a powerful API, but due to its access restrictions it becames unusable when you need to made something automatically, without any user actions.
What is the reason for most of these restrictions?
Is there any walkarounds?
Office 365 works perfect with deamon applications but not in your usecase. It works great for modifying a user' calendar for instance. See here https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-1.0&tabs=cs
Apart from that, if you want to have something changed in the graph api. The best way to let Microsoft know is to create an item on UserVoice. This is to let users influence what features they need, maybe you can express your wishes there. https://microsoftgraph.uservoice.com/forums/920506-microsoft-graph-feature-requests
I am developing a python app running on embedded linux to access office365 calendar via the EWS interface. I plan on using impersonation to access data.
I have registered my app with azure AD and retrieved the endpoints which contain a tenant id. But I have learned that using the common endpoint seems to work just fine in refreshing the access token.
what are the advantages or limitations in using the tenant id instead of just using common?
Take a look at http://www.cloudidentity.com/blog/2014/08/26/the-common-endpoint-walks-like-a-tenant-talks-like-a-tenant-but-is-not-a-tenant/. The common endpoint does late binding to the tenant based on the users login details. The article does add "For line of business applications you do NOT want to late bind the tenant, in fact you want to ensure that the caller comes from your specific tenant and no other! In that case, use of common is not appropriate."