Microsoft Exchange Response Integration via API

Purpose

This guide explains how to configure the Microsoft Exchange Response integration in Logsign USO, which lets an incident responder or an automated action rule search, read, and delete mail items, and look up mailbox or contact information, directly on an on-premises Microsoft Exchange Server mailbox from inside a Logsign incident.

This integration is confirmed, from the source code, to use Exchange Web Services (EWS) through the Python exchangelib library against a mailbox server you specify by IP address, authenticating with a plain username and password (Basic or NTLM, negotiated automatically by the library). It does not use OAuth 2.0, an Azure AD app registration, or the Microsoft Graph API, and it is not built for Exchange Online. If your organization is fully on Exchange Online (Microsoft 365) with no on-premises Exchange Server or hybrid Client Access Server reachable from your Logsign deployment, this integration will not work for you; see Notes and Limits for how it relates to the other Microsoft mail integrations Logsign offers.

Logsign already ships two other, separate Microsoft mail integrations that are easy to confuse with this one:

• Microsoft Graph Mail Integration (also under Settings > Integrations > Responses) authenticates against Exchange Online / Microsoft 365 with an Azure AD app registration (tenant ID, client ID, client secret) and only exposes a single action, sending mail (SEND_MAIL). It cannot search, read, or delete mailbox content. Use it for notification/alerting actions against a Microsoft 365 tenant, not for mailbox investigation or remediation.
• Office 365 Message Trace Integration via API is a data collection poller (Settings > Data Collection), not a response/action integration. It authenticates with an Azure AD app and the Microsoft Graph message trace endpoint to pull message routing/delivery audit records into Logsign for search and correlation. It does not read mail content or take any action on a mailbox.

The integration documented here is the only one of the three that can search a mailbox's inbox, retrieve a specific message's full content (including attachments metadata), delete a message, or look up/search contacts, and it does so against on-premises Exchange Server mailboxes only, using mailbox-level credentials rather than an Azure AD app.

Prerequisites

• An on-premises Microsoft Exchange Server (Exchange 2013 or later is assumed based on the EWS/RBAC model referenced by the underlying library documentation; the exact minimum supported Exchange Server version was not verified against Logsign engineering) with its Client Access/EWS endpoint reachable over HTTPS from the Logsign server or leaf that will run this integration.
• A dedicated Exchange service account (username and password) that Logsign will use to authenticate. Do not use a personal admin mailbox account for this; see Step 1 for the exact permission this account needs.
• Network access from the Logsign integration host to the Exchange server's EWS endpoint (TCP 443, HTTPS) is required. The exact port/firewall requirement was not independently re-verified in this session and should be confirmed for your environment, though 443 is the standard EWS port.
• The email addresses (mailboxes) that incident responders will need to search, read, or act on. Each method call takes a specific mailbox address as a parameter; there is no "search all mailboxes" mode.

Step 1: Configure least-privilege access

The integration code calls Exchange with access_type=DELEGATE, not Exchange Impersonation. This was confirmed directly by reading the integration's source (automation/integration/exchange/exchange.py): every method builds an Account object with access_type=DELEGATE, never IMPERSONATION. This matters because most public Exchange/EWS guides describe granting the ApplicationImpersonation RBAC role, which is the correct approach for impersonation-based integrations but is not what this integration uses, and would not by itself grant this integration access to a mailbox it does not already have delegate rights to.

With delegate access, the Exchange administrator must explicitly grant the Logsign service account permission on each mailbox this integration needs to touch, using the standard Exchange mailbox permission model rather than an organization-wide impersonation scope. This is run from the Exchange Management Shell on the Exchange server:

Add-MailboxPermission -Identity "user@yourdomain.com" -User "svc-logsign-exchange" -AccessRights FullAccess -AutomapEnabled $false -InheritanceType All

Run this once per mailbox that Logsign needs to be able to search, read, or delete from. -AutomapEnabled $false is recommended so the mailbox does not automatically appear in the service account's own Outlook profile; it has no effect on what the API integration itself can do. FullAccess is required because the integration's delete-email method calls the standard EWS delete operation, which needs write/delete rights on the mailbox, not just read rights; Exchange does not offer a narrower built-in role (for example, read-only delegate access) that also permits deleting items through this access model. If you only need the read-oriented methods (list, get, search, lookup) for a given mailbox and want to withhold delete rights, note that as a Logsign product/engineering request; the current integration code does not support requesting a reduced permission set per method.

Do not grant the service account Organization Management, Domain Admin, or any tenant-wide administrative role. None of that is needed here; a per-mailbox FullAccess grant using the command above is the least-privilege path for this integration, confirmed against the access pattern the code actually uses.

The service account itself should be a standard Active Directory/Exchange account that can authenticate to the Exchange server over Basic or NTLM (the integration's dependencies include requests-ntlm and ntlm-auth, and exchangelib negotiates the authentication scheme automatically). Whether the account needs a mailbox of its own to authenticate successfully, or can be a mailbox-less service account, was not verified in this session; if your first connectivity test fails with an authentication error even though the password is correct, try provisioning a mailbox for the service account as a next troubleshooting step.

Step 2: Configure the integration in Logsign

1. Log in to Logsign USO with an administrator account.
2. Go to Settings > Integrations > Responses.
3. In the search field, type Exchange (the integration is listed as MS Exchange).
4. Click Configure, then click +Device.
5. Fill in the fields listed below and click Create.

There is no separate connectivity test button described in the manifest beyond the integration's own internal test call, which authenticates and probes a fixed, non-existent mailbox address; a mailbox-not-found response is treated as a successful connection test, and any other error (typically an authentication failure) is treated as a failed test. If your device fails to save or shows a connection error immediately, re-check the Server IP format above first, since a malformed EWS URL is a common and easy-to-miss cause.

Available Methods

Once the device is configured, the following methods become available wherever Logsign lets you invoke a Response action (action rules, manual incident response, playbooks). Every method operates on a single mailbox, identified by its email address; there is no bulk or "all mailboxes" mode. There is no "block sender" or "move email to folder" method in this integration; only the methods listed below exist in the current code and manifest.

list-emails

Returns the 5 most recently received messages in the specified mailbox's Inbox, ordered newest first. The limit of 5 is fixed in the integration code and is not configurable from the Logsign UI.

get-email

Retrieves the full content of a single message by its EWS item ID, including subject, sender/recipients, body (both plain text and HTML body are returned as separate fields), read status, and attachment metadata (name, content type, size). It does not download attachment binary content, only attachment metadata.

search-email

Searches the specified mailbox's Inbox using an EWS/AQS-style query string and returns up to 5 matching messages, newest first. This is the primary method for phishing/incident triage: locating copies of a reported malicious email across a mailbox before deciding whether to delete it.

The 5-result cap applies here as well; a broad query against a mailbox with many matches will only return the 5 most recent, not a paged or complete result set.

delete-email

This action is permanent and not recoverable. The integration calls the underlying library's hard-delete operation with no options, which Exchange documentation confirms removes the item directly from the mailbox database. It does not move the message to Deleted Items, and it does not go through the Recoverable Items/dumpster folder the way emptying Deleted Items or a "soft delete" normally would. There is no undo, and Exchange-side recovery tools that rely on the dumpster will not find the item. Confirm the correct item ID and mailbox before invoking this in any automated action rule, and be deliberate about using it in manual incident response.

list-contacts

Returns every contact stored in the specified mailbox's Contacts folder. Unlike the email-listing methods, there is no result cap applied in the integration code for this method.

search-contact

Searches the specified mailbox's Contacts folder using an EWS/AQS-style query and returns matching contacts.

lookup-email

Resolves an email address against the Exchange Global Address List / directory and returns the matching display name and address, if any. This is a directory lookup, not a mailbox content search; it is typically used to confirm whether an address is a valid internal recipient before taking a further action.

Notes and Limits

• On-premises Exchange Server only, confirmed from code. The configuration schema requires a Server IP, username, and password, with no tenant ID, client ID, or OAuth scope anywhere in the manifest or code, and autodiscover is explicitly disabled (autodiscover=False). This is fundamentally different from Logsign's Microsoft Graph Mail Integration and Office 365 Message Trace integration, both of which are built for Exchange Online / Microsoft 365 through an Azure AD app registration. Do not attempt to point this integration's Server field at an Exchange Online hostname; it is not designed for that authentication model and Microsoft has been progressively restricting Basic/legacy authentication against Exchange Online regardless.
• Delegate access, not impersonation. As covered in Step 1, the code uses access_type=DELEGATE. The service account needs an explicit Add-MailboxPermission ... -AccessRights FullAccess grant on every mailbox it will be used against. There is no "impersonate any mailbox in the org" shortcut available with this integration as written; each mailbox must be granted individually.
• The underlying exchangelib version is pinned to 1.12.1, an older release of the library (per requirements.txt). Whether this version has any known compatibility issues against current/recent Exchange Server cumulative updates was not verified in this session; if you see unexpected schema or protocol errors against a very new Exchange Server build, this pinned dependency version is a reasonable first thing to check with Logsign engineering.
• list-emails and search-email always cap results at 5 items, hardcoded in the integration and reflected in the manifest's result schema (maxLength: 5). There is no page/offset parameter to retrieve additional results beyond the 5 most recent matches.
• get-email and search results do not include attachment file content, only attachment metadata (name, content type, size, content ID). There is no separate "download attachment" method in this integration.
• The connection uses TLS certificate verification disabled at the HTTP adapter level (the integration explicitly installs NoVerifyHTTPAdapter from exchangelib before making any calls). In practice this means the integration will connect even to an Exchange server presenting a self-signed or otherwise untrusted TLS certificate, trading certificate validation for connectivity convenience. This is a property of the current implementation, not a setting you can change from the Logsign UI, and is worth being aware of if your organization has a strict TLS-verification security requirement for internal service accounts.

Troubleshooting

The integration surfaces errors from the underlying EWS SOAP protocol rather than plain HTTP status codes in most cases, but authentication and connectivity failures do map onto the HTTP layer described below. The exact error codes below reflect exchangelib's and Exchange's own documented behavior; they were not re-verified against a live Exchange Server in this session.