Possible URL construction issue in Office 365 module - Tenant ID vs Client ID

[Gabriel Diaz]

Hi team,

I am experiencing an issue with the Office 365 integration on Wazuh 4.x (running on Ubuntu/Debian). The module connects successfully, but it is not retrieving any events (empty results).

After enabling debug mode, I noticed a potential discrepancy in how the API URL is being constructed. According to Microsoft's Management Activity API documentation, the URL should follow this format: https://manage.office.com/api/v1.0/{tenant_id}/activity/feed/...

However, my ossec.log shows the following (IDs redacted for security):

DEBUG: Office 365 API subscription URL: 'https://manage.office.com/api/v1.0/<MY_CLIENT_ID>/activity/feed/subscriptions/start?contentType=Audit.AzureActiveDirectory'

It seems the module is placing the Client ID (Application ID) in the path where the Tenant ID is expected.

I have verified my ossec.conf and both IDs are correctly placed in their respective tags under <api_auth>. I also tried using the domain name instead of the Tenant ID, but the URL construction remains the same.

Questions:

1. Is this a known regression or a specific behavior for certain environments?

2. Has anyone else encountered the Client ID being used in the API path instead of the Tenant ID?

3. Am I missing a specific configuration tag to force the correct URL structure?

Any guidance would be greatly appreciated.

Best regards.

[Stuti Gupta]

Hi,

This behaviour is not expected. The Office 365 Management Activity API requires the tenant ID in the API path. The base URL can change depending on the Office 365 environment (commercial, GCC, GCC High, etc.), but the value in the path should still be the tenant ID, not the client ID.

If your log shows the client ID in that position, the next steps are:

Make sure the value in <tenant_id> is the Directory (tenant) ID from Azure and not the application ID or domain name. You can check this in Azure:
Azure portal > App registrations > Your application > Overview > Directory (tenant) ID

Check the Office 365 configuration block in /var/ossec/etc/ossec.conf and ensure the values are correctly placed:

<ossec_config>
  <office365>
    <enabled>yes</enabled>
    <interval>1m</interval>
    <curl_max_size>1M</curl_max_size>
    <only_future_events>yes</only_future_events>
    <api_auth>
      <tenant_id><YOUR_TENANT_ID></tenant_id>
      <client_id><YOUR_CLIENT_ID></client_id>
      <client_secret><YOUR_CLIENT_SECRET></client_secret>
      <api_type>commercial</api_type>
    </api_auth>
    <subscriptions>
      <subscription>Audit.AzureActiveDirectory</subscription>
      <subscription>Audit.General</subscription>
    </subscriptions>
  </office365>
</ossec_config>

Make sure the <api_type> value matches your Microsoft 365 environment:
commercial
gcc
gcc-high
https://documentation.wazuh.com/current/cloud-security/office365/monitoring-office365-activity.html#activity-api-operations-based-on-plans
This setting determines which API endpoint Wazuh uses.

After confirming the configuration, restart the manager so the module reloads the values: systemctl restart wazuh-manager

Review /var/ossec/logs/ossec.log after the restart and confirm whether the Office 365 module is using the correct tenant ID when constructing the API URL.

If the correct tenant ID is configured but the log still shows the client ID being used in the API path, then the issue would require deeper investigation. In that case, shre 
The <office365> configuration block, hiding sensitive data
Sharing the relevant debug logs
cat /var/ossec/logs/ossec.log | grep  Office
This would help to identify why the module is requesting incorrectly.