Microsoft EWS Daemon

Version: 2.5
Updated: May 9, 2024

Cloud SOAR

This integration is only for Cloud SOAR.

Process emails with EWS Daemon.

Actions

• Microsoft EWS Incoming Mail Daemon (Daemon) - Automatically retrieve emails from EWS.

Microsoft EWS configuration

Each application you want the Microsoft identity platform to perform identity and access management (IAM) needs to be registered. Registering it establishes a trust relationship between your application and the identity provider, the Microsoft identity platform.

Register an application

Registering your application establishes a trust relationship between your app and the Microsoft identity platform. The trust is unidirectional: your app trusts the Microsoft identity platform, and not the other way around.

Follow these steps to create the app registration:

1. Sign in to the Azure portal.
2. If you have access to multiple tenants, use the Directory + subscription filter
   in the top menu to select the tenant in which you want to register an application.
3. Search for and select the Azure Active Directory.
4. Under Manage, select App registrations > New registration.
5. Enter a Name for your application. Users of your app might see this name, and you can change it later.
6. Select Register to complete the initial app registration.
7. Don't enter anything for Redirect URI (optional).
   

When registration completes, the Azure portal displays the app registration's Overview pane, which includes its Application (client) ID. Also referred to as just client ID, this value uniquely identifies your application in the Microsoft identity platform.

The client ID as one aspect in validating the security tokens it receives from the identity platform.

Add credentials

Credentials are used by confidential client applications that access an API. Examples of confidential clients are web apps, or service- and daemon-type applications. Credentials allow your application to authenticate as itself, requiring no interaction from a user at runtime.

You can add client secrets (a string) as credentials to your confidential client app registration.

Add a client secret

The client secret, known also as an application password, is a string value of your app.

1. Select your application in App registrations in the Azure portal.
2. Select Certificates & secrets > New client secret.
3. Add a description for your client secret.
4. Select a duration.
5. Select Add.
6. Record the secret's value for use in your client application code - it's never displayed again after you leave this page.

Add permissions to API

1. Select your application in App registrations in the Azure portal.
2. Select API permissions > Add a permission.
3. Delegated permissions are selected by default. Delegated permissions are appropriate for client apps that access an API as the signed-in user, and whose access should be restricted to the permissions you select in the next step.
4. Application permissions are for service- or daemon-type applications that need to access API as themselves, without user interaction for sign-in or consent. Unless you've defined application roles for your API.
5. Select Add a permission, and add the following permissions (as we can see from the picture).

EWS API need to be configure these permissions

Applications are authorized to call APIs when they are granted permissions by users/admins as part of the consent process. The list of configured permissions should include all the permissions the application needs.

API / Permissions

Microsoft Graph (7)

• Mail.Read
  • Type: Delegated
  • Description: Read user mail
  • Admin: -
• Mail.Read
  • Type: Application
  • Description: Read mail in all mailboxes
  • Admin: Yes
• Mail.ReadBasic
  • Type: Delegated
  • Description: Read user basic mail
  • Admin: -
• Mail.ReadBasic
  • Type: Application
  • Description: Read basic mail in all mailboxes
  • Admin: Yes
• Mail.ReadBasic.All
  • Type: Application
  • Description: Read basic mail in all mailboxes
  • Admin: Yes
• profile
  • Type: Delegated
  • Description: View users' basic profile
  • Admin: -
• User.Read
  • Type: Delegated
  • Description: Sign in and read user profile
  • Admin: Yes

Office 365 Exchange Online (3)

• EWS.AccessAsUser.All
  • Type: Delegated
  • Description: Access mailboxes as the signed-in user via Exchange Web Services
  • Admin: -
• Exchange.ManageAsApp
  • Type: Application
  • Description: Manage Exchange As Application
  • Admin: Yes
• full_access_as_app
  • Type: Application
  • Description: Use Exchange Web Services with full access to all mailboxes
  • Admin: Yes

full_access_as_app Use Exchange Web Services with full access to all mailboxes

Once API permission are added then Admin must consent to a grant these permissions, Learn more about permissions and consent.

Important Note

When using the Microsoft EWS Daemon action within an automation rule, note that it will only pull in emails that are marked "Unread" within the respective mailbox scope. To ensure all relevant alerts are processed correctly, keep this mailbox a dedicated entity and avoid any manual reviews by other stakeholders.

Configure Microsoft EWS Daemon in Cloud SOAR

Before you can use the integration, you must configure it so that the vendor can communicate with Sumo Logic. For general guidance, see Configure Authentication for Integrations.

1. Access App Central and install the integration.
2. Select the installed integration in the Integrations page.
   Classic UI. In the main Sumo Logic menu, select Automation and then select Integrations in the left nav bar.
   New UI. In the main Sumo Logic menu, select Automation > Integrations. You can also click the Go To... menu at the top of the screen and select Integrations.
3. Select the integration.
4. Hover over the resource name and click the Edit button that appears.
   
5. In the Add Resource dialog, enter the authentication needed by the resource. When done, click TEST to test the configuration, and click SAVE to save the configuration.

For information about Microsoft EWS, see Microsoft Exchange Web Services documentation.

Category

Email Gateway

Change Log

• October 27, 2021 - First upload
• March 10, 2022 - Logo
• October 6, 2023 (v2.2) - Integration Updated
• March 4, 2024 (v2.3) - Updated code for compatibility with Python 3.12
• March 21, 2024 (v2.4) - Resolved an issue related to the Email Body
• May 9, 2024 (v2.5) - A new field has been added to the integration resource for specifying the folder or path to search within