Does anybody know if there is a rest API to the office 365 Security and Compliance center that can give me back any alerts raised by the Alert Policy?
It seems that there are some PowerShell cmdlets that allow the creation of new Alert Policies, but I would like to pull down the alerts generated by these policies (preferably without using PowerShell).
Maybe this is on the road-map for a future Microsoft Graph API?
Office365 security alerts are not yet supported, but this should be possible for Microsoft security products using the Public Preview of Graph Security API - aka.ms/graphsecurityapi.
Microsoft Graph Security API only has access to the following(now GA).
Microsoft Graph Security API to easily access alerts from the following security solutions:
Azure Active Directory Identity Protection,
Azure Information Protection,
Azure Security Center,
Microsoft Cloud App Security,
Microsoft Intune,
Windows Defender ATP, and
Office 365 ATP and Azure ATP (coming soon)
Related
We have a working outlook app using version 1_1 on O365. We are testing this with an exchange on prem only setup but with azure AD hybrid. The graph API functions we need work within this environment thanks to testing on graph api exporer.
When we push the manifest to exchange either via the exchange admin portal or via powershell we receive an error relating to webapplicationinfo being invalid. We have this within versionoverride 1.1 and that within versionoverride 1.0
If I remove the webapplicationinfo section which includes the scope, this will import ok, but when the app performs the function to get the auth token it fails, for which I am sure because the scope wasnt authorised.
No where i can find that says on prem is not supported. I find a lot of reference to 2016 CU3 but nothing specific to on prem. Can someone assist?
Exchange 2016 Cumulative Update 3 (CU3), released in September 2016 for Exchange on-premises servers, adds support for REST API integration with Microsoft 365. If your app uses v1.0 of the Mail, Calendar, or Contacts API, you will now also find a seamless authentication and application experience in hybrid deployments, regardless of whether the mailbox is on-premises or in the cloud, provided that the deployment meets specific requirements.
See Use REST APIs to access mailboxes in Exchange hybrid deployments (preview) for more information.
We are developing the azure B2B Application to invite and access our Asp.net application that is hosted in the Azure. I checked the example https://github.com/Azure/active-directory-dotnet-graphapi-b2bportal-web which uses the ADAL for most of the operation. In the example from the above link, the MS Graph using an access token generated from the ADAL, but Microsoft recommends using the MSAL.
My question is Which one we have to use the for MS Graph in the ASP.net Application either ADAL or MSAL.
Both of them can help in handling Ms Graph, but MSAL provides multiple benefits over ADAL including incremental consent, richer single sign-on experiences, support for personal Microsoft accounts, use of standards-based protocols and so on.
Also, MSAL has good examples available for Ms Graph and easily implemented.
I agree with Hari above. Both MSAL/ADAL capable of working with MS Graph. But here's the key differences:
Active Directory Authentication Library (ADAL) integrates with the Azure AD for developers (v1.0) endpoint, where MSAL integrates with the Microsoft identity platform (v2.0) endpoint.
The v1.0 endpoint supports work accounts, but not personal accounts. The v2.0 endpoint is the unification of Microsoft personal accounts and work accounts into a single authentication system. With MSAL you can also get authentications for Azure AD B2C as well.
So MSAL enables developers to acquire tokens from the Microsoft identity platform endpoint in order to access secured web APIs. These web APIs can be the Microsoft Graph, other Microsoft APIs, third-party web APIs, or your own web API. MSAL is available for .NET, JavaScript, Android, and iOS, which support many different application architectures and platforms.
Hope this helps.
I'm trying to help someone to ingest Office 365 Alerts with the Graph Security API. This requires SecurityEvents.ReadAll as minimum permission. The docs mention that the permission setting is done in the Microsoft Graph API Explorer (see e.g. this blog). However, the account admin insists on setting the permissions using Azure AD. The question is how that is actually done. Azure AD / Enterprise Applications / Graph Explorer apparently doesn’t list any permissions. Would anyone know how to achieve this?
Many thanks!
If you want to test Graph Security API in Microsoft Graph Explorer, your just need to set SecurityEvents.Read.All in Microsoft Graph Explorer.
If you want to call Graph Security API in your app, you should set SecurityEvents.Read.All in the app registered on Azure portal.
You could refer to Authentication and authorization basics for Microsoft Graph to learn more about how to handle the permissions and authorization to call Microsoft Graph API.
This question already has an answer here:
Does "Outlook Mail REST API" include access to corporate MS exchange server email?
(1 answer)
Closed 5 years ago.
Can the MicrosoftGraph API, specifically the WebHooks, be used for accounts on an enterprise / on-premise Exchange server as opposed to Office 365.
All the documentation I have seen for setting up the app required for OAuth authentication use Azure.
There is a "hybrid deployment" model currently in preview that allows you to traverse both on-prem and online mailboxes using Microsoft Graph. You can read about the infrastructure requirements at On-Premises Architectural Requirements for the REST API.
One note on authentication, Microsoft Graph uses OAUTH tokens to handle authentication. These tokens are issued by Azure AD but this does not mean that your entire infrastructure needs to be hosted on Azure, only that your AD be synced with an Azure AD instance using Azure AD Connect. Depending on the size of the organization you may even be able to use the Free trier of Azure AD. I highly recommend taking a look into this configuration as Azure AD is quickly becoming an assumed prerequisite for new APIs and services.
I'm trying to create an Amazon Alexa service that will take advantage of the Microsoft Graph... This is built with Node.js.
Currently when using my standard Outlook.com Microsoft Account to sign in, I get redirected to a Microsoft page that says
Microsoft account is unavailable
Microsoft account is unavailable from this site, so you can't sign in or sign up. The site may be experiencing a problem.
You can sign in or sign up at other Microsoft Sites and services, or try again later at this site.
I have been using https://login.microsoftonline.com/common/oauth2/v2.0/authorize as my authorization URL in the Alexa config account linking section. and using the Node Microsoft Graph JavaScript SDK library in my code.
I'm wondering if the Node library I'm using is the correct one? Has it been deprecated? Or is there something else going on here?
A common misunderstanding with Microsoft Graph is the separation of concerns between the API and Authentication.
You do not actually authenticate against Microsoft Graph. Instead you authenticate against the directory that holds your account, for organizational accounts this is Active Directory and for consumer accounts this the Outlook.com.
Once you have authenticated, you use the token you received back to identify yourself when calling Microsoft Graph API.
This is where you (and many others) get tripped up at first. Just as there are two concerns (Auth & API), there are also two separate SDKs. For Node.js you're looking for:
Microsoft Authentication Library (MSAL): This handles authentication for both Azure AD and Microsoft Accounts.
npm install msal
Microsoft Graph JavaScript Client Library: This is the client library for Microsoft Graph. It will provide the objects and methods you need to simplify calling the APIs.
npm install #microsoft/microsoft-graph-client
This should give you the tools you need to get started. There are some things around App Registration, OAUTH and Admin Consent that you'll likely run into as well. For these, you might find these helpful:
Microsoft v2 Endpoint Primer
v2 Endpoint and Implicit Grant
v2 Endpoint and Admin Consent
Hope this helps!