I am looking for an API that would allow me to do the following: given a business subscription for Office365 and Admin level access, I would like to receive events about file and folder changes.
Example events I am interested it:
Billy uploaded a cat1.jpg to /drives/123/cats on %datetime%
Sally created a file.txt in /drives/123/work_in_progress on %datetime%
Jay shared a data.csv in /drives/123/data with bob#example.com on %datetime%
I've looked at activities API and webhooks subscription but not sure if these are the right ones for the purpuses.
Can someone please suggest APIs I can use to get such audit trail data from Office365/OneDrive?
Depending on the scale, Webhooks and Deltas are excellent candidates for this.
Where you'll likely run into challenges is if you're attempting to centrally audit across an entire organization. These endpoints are scoped to a single user/directory/drive/etc. so they are less than ideal for organization-wide auditing.
For broader/top-level auditing, I would instead look at the Office 365 Management Activity API. This API includes the ability to audit SharePoint File Operations.
Related
I have been trawling the internet and clicking myself blue in the face! Hopefully someone has a definitive answer.
I want to have one Group (in either of Azure AD, Microsoft Teams or Azure DevOps). This group must have access to a DevOps project and a Team site. When I change the membership of the group, the membership must change for both the Team and the DevOps project. I want to avoid the overhead of managing the groups for both separately.
Is this at all possible? Thanks.
This is a really good question, and the answer is not obvious at all. Ironically we had the same exact problem in Microsoft Teams - when a user was added or deleted from the underlying Office 365 Group (which is mastered in Azure AD), it would take up to an hour, sometimes more, to be reflected in Teams, which has its own copy of the member list.
There is a way to do it, and it's how Teams does it: it relies on a relatively new feature in Microsoft Graph called subscriptions. You can find the documentation for it here: https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0.
Essentially what you want to do is create a subscription to the group: POST https://graph.microsoft.com/v1.0/subscriptions with the right message body and your endpoint will be called whenever there's a membership change in the group. Your endpoint won't know what changed, just the event and some IDs - you will likely have to make a separate call to retrieve the actual data (unless the IDs alone are sufficient).
There's a sample on GitHub that illustrates how to use Microsoft Graph subscriptions including more details on how to subscribe to group notifications specifically.
One thing to be aware of is that to use these APIs, your application will require fairly elevated permissions: Group.Read.All which means it has the ability to read not only the team/group members, but all of its messages too (among other things), for every group in your Office 365 tenant. We are working with the MS Graph team to support a less-privileged, per-group permission approach, but even after that's released for Teams Graph APIs, support for that will have to be added to the subscriptions APIs I just mentioned and that may not happen for a while.
I'm interested in getting data (metadata and content of files) out of Microsoft Teams into my application using REST APIs. I have looked at Office 365 APIs and Graph APIs but, I could not find supporting documentation for Microsoft Teams.
Teams API is now added to beta endpoint in Microsoft Graph. In documentation, you can find it together with Groups. Post, Channel and Chat Thread are available.
For example, documentation for "channel" resource is here:
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/channel
Microsoft Teams REST API is now included into MS Graph API
https://learn.microsoft.com/en-us/graph/api/resources/team?view=graph-rest-1.0
At the time of writing this answer there are not too many APIs around Teams. However more are being added and they are in Beta (sending messages, adding apps to team, uploading team image, and more).
https://learn.microsoft.com/en-us/graph/api/resources/team?view=graph-rest-beta
It is not recommended to use Beta APIs in production environment as they might change.
It is also worth of mentioning that Teams are actually Office365 Groups.
Please take a look at Graph API
https://learn.microsoft.com/en-us/graph/api/resources/team?view=graph-rest-1.0
https://learn.microsoft.com/en-us/graph/api/resources/team?view=graph-rest-beta
Expand "Teamwork" at left side, you can get all Teams related API
We do not have Teams APIs available at this time. Our extensibility options are limited to experiences within the Teams application.
The Microsoft Graph API is constantly changing and we're currently using the following to monitor/interact with our Microsoft Teams application:
https://learn.microsoft.com/en-us/graph/api/resources/teams-api-overview
It gives access to the following (at the time of writing this):
We also monitor the general usage via the reports section in the Graph API:
This gives access to:
Device Usage:
Get details about Microsoft Teams device usage by user.
Get the number of daily unique users by device type.
Get the number of unique users by device type over the selected time period.
User Usage:
Get details about Microsoft Teams user activity by user.
Get the number of Microsoft Teams activities by activity type. The activities are performed by Microsoft Teams licensed users.
Get the number of users by activity type. The activity types are number of teams chat messages, private chat messages, calls, or meetings.
https://learn.microsoft.com/en-us/graph/api/resources/microsoft-teams-device-usage-reports?view=graph-rest-1.0
I want to monitor employees interactions inside companies. In the case the company is using Gmail, I was thinking about using https://developers.google.com/admin-sdk/email-audit/.
But i still have some questions regarding the "lawful" purpose and I'm wondering if Email Audit is the right API if my purpose is to monitor in real-time emails knowing there will be at least 10 000 emails/day to monitor.
If you check the Usage Limits and Quotas:
Limits and quotas protect the Google infrastructure from an automated process that uses the Email Audit API in an inappropriate way. Excessive requests from an API might result from a harmless typo, or may result from an inefficiently designed system that makes needless API calls. Regardless of the cause, blocking traffic from a specific source once it reaches a certain level is necessary for the overall health of the Google Apps system. It ensures that one developer's actions cannot negatively impact the larger community.
To answer you question, if your goals falls under this description - Google Apps Email Audit API Developer's Guide:
The Google Apps Email Audit API allows Google Apps administrators to audit a user's email, email drafts, and archived chats. In addition, a domain administrator can retrieve account login information and download a user's mailbox. This API can be used only for lawful purposes in accordance with your Customer Agreement.
Then the answer would be yes, it is the appropriate API to use. If you are thinking about the 10000 emails/day, you might want to check if it is reasonable to ask for quota increase.
Hope this helps!
In Mandrill, if you create a new API key and do not limit its API calls, whoever you give that key to can use it to log into the web interface with full access - billing information, account information, the works.
After playing around, it looks like you can disable the web interface login functionality by ticking "Only Allow This Key To Use Certain API Calls" and then selecting at least one API call. Doesn't matter which one.
So I can give full access to the account, or completely disable their ability to log in. Is there any way to customize this further? I would like to be able to limit users to the outbound/inbound UI, or at least prevent them from having the ability to charge many thousands of dollars to the attached credit card. For clarification, my use case is to distribute API keys to contractors or vendors so that all email gets sent through a single account.
I have found very little official Mandrill documentation on this. The only thing that seemed relevant is that if you have a Mailchimp account, you can instead send users there and use the "View Mandrill Reports" functionality. I don't have Mailchimp (nor do I need it), so this seems like an unnecessary hacky workaround.
Different levels of access, other than limiting API calls for API keys isn't currently possible as described in the Mandrill KB here. If someone has access to the web interface, they have access to the account as a whole. This may, of course, change in the future, and would be documented on the blog and in the KB.
I believe you could also restrict access to the web interface by setting up two-factor authentication?
I'd like to deploy a Office 365/Exchange Online management portal in the WAWS(Windows Azure WebSite) which could create new user/group/mailbox or change some property of specific user, etc. Is it possible to deploy this kind of web application in the WAWS environment? Should I call PowerShell and Office365 cmdlet in the ASP.NET environment? Or there are any better way to do this?
As the #Matt alludes to in his comment, there is already a web-based management portal for both of these. However, since you ask this question, I'm going to assume that you want additional functionality/customization.
The short answer is yes, you can.
User accounts in Office 365 are, behind the scenes, accounts in Azure Active Directory. So, for creating users, contacts, security groups and adding licenses, you will need to use the Azure Active Directory Graph API:
Getting Started With Windows Azure Active Directory Graph
For managing Exchange Online, you will probably want to use the Exchange Web Services Managed API 2.0. You'll probably only need this if you need to create distribution groups or manage individual users' contact folders (mailboxes for users get created when you assign an Exchange license from Azure Active Directory).
Get started with EWS Managed API client applications
Update: the Office 365 APIs were recently announced, and are now in Preview. They are a RESTful API, which can be used to manage (for now), mail, contacts and calendar items. Depending on your use case, this may be easier to deal with than the EWS Managed API 2.0.
Using the Mail, Calendar, and Contact REST APIs to work with emails, calendar items, and contacts