>
    Strata Copilot
    Forward Logs to Microsoft Sentinel
    Focus
    Download PDF
    Focus
    1. Home
    2. Strata Logging Service
    3. Strata Logging Service Administration
    4. Log Forwarding from Strata Logging Service
    5. Forward Logs to Microsoft Sentinel
    Download PDF
    Strata Logging Service

    Forward Logs to Microsoft Sentinel

    Table of Contents

    Forward Logs to Microsoft Sentinel

    Forward logs directly to Microsoft Sentinel using the Azure Monitor Log Ingestion API, without requiring a GZIP decompression proxy.
    Where Can I Use This?What Do I Need?
    One of these:
    Configure Strata Logging Service to forward logs to Microsoft Sentinel using the Azure Monitor Log Ingestion API. This method replaces the legacy Data Collector API.
    This procedure describes one method for ingesting logs. For a comprehensive integration guide and alternative deployment methods, refer to the official Microsoft documentation.
    1. Sign In to the hub.
    2. Select the Strata Logging Service instance that you want to configure for HTTPS forwarding.
      If you have multiple Strata Logging Service instances, click the Strata Logging Service tile and select an instance from the list of those available.
      If you are using Strata Cloud Manager to manage Strata Logging Service, click System SettingsStrata Logging ServiceLog Forwarding to manage devices onboarded to your Strata Logging Service instance.
    3. Select Log ForwardingAdd to add a new HTTPS forwarding profile.
    4. Enter a descriptive Name for the profile.
    5. Enter the Azure Data Collection Endpoint url which should also include the stream/table  and api-version to stream data to a HTTPS forwarding profile.
      The URL entered must begin with https. At the end of the top-level domain, you can specify a port number. The default port is 443.
    6. (Optional) Authenticate your https server. Click + to upload a certificate. You can upload:
      • a self-signed certificate if you do not want to use a publicly signed certificate.
      • the private Root CA and intermediate CAs (If an intermediate CA exists). Do not upload the certificate issued for the syslog server—only CA certificates are needed to verify the chain from the syslog server.
      Only do this if you installed a private CA-signed, self-signed certificate on your receiver, or the public CA is not in the list of trusted CAs. The file containing the certificates must be in PEM format.
    7. (Optional) Enable client authentication.
      Do this if company or regulatory policy requires client authentication when forwarding logs to your server.
      1. Download the certificate chain.
      2. Upload the certificate chain to your server.
        Refer to the documentation for your server management software to find out how to do this.
    8. Configure Client Authorization.
      Do this if you're forwarding logs to a cloud HTTPS receiver, or if your HTTPS server requires a username and password.
      1. Select the TypeMicrosoft Sentinel Authorization (Recommended) of client authorization and enter the necessary credentials.

    Authenticate SLS API calls to Azure

    1. Provision a Service Principal: To authenticate SLS API calls to Azure, you must provision a service principal. Reference the Microsoft documentation to Create an Azure Entra ID Service Principal and obtain a client secret.
      Under the Redirect URI configuration, leave the type and URL fields completely blank. This is a non-interactive machine-to-machine connection; a redirect path is not required, even if your organization uses a custom or federated Identity Provider (IdP).
    2. Assign Ingestion Roles: The App Registration requires permissions to push data into Azure Monitor. In the Azure Portal, assign the Monitoring Metrics Publisher role to your App Registration. You can scope this role to your resource group or directly to the Data Collection Rule (DCR) once created. Reference the Microsoft documentation to Assign Azure roles using the Azure portal.
    3. Identify your Data Collection Endpoint (DCE): The DCE serves as the base ingestion URL for incoming logs. Ensure you have an active DCE located in the same Azure region as your Log Analytics Workspace. Reference: Data collection endpoints in Azure Monitor.
    4. Create the Custom Log Analytics Table: When integrating with Azure Log Analytics, you must account for naming restrictions. Azure Log Analytics tables do not support hyphens in column names. To avoid requiring a sample JSON payload during portal configuration, use the Azure CLI to instantly create your destination table with its predefined columns.
      To define your data schemas during deployment, you must configure your table structures using an authorized interface.
      • SQL Commands: To configure tables via SQL commands, reference the specific data type structures outlined in Data Types within the Technical Considerations section of this guide.
      • Alternative Methods: To create tables using Azure Resource Manager templates or REST APIs, refer directly to the Microsoft Azure documentation.
      Here is an example of how you can run the command in your Azure Cloud Shell or local Azure CLI terminal.
      Feel free to swap out the columns, table name, resource group, or workspace with your own actual values—just remember that if you are creating a custom table, Azure Log Analytics requires the name to end with _CL (Custom Log).
      az monitor log-analytics workspace table create \
  --resource-group "YourResourceGroupName" \
  --workspace-name "YourWorkspaceName" \
  --name "target_table_name" \
  --columns TimeGenerated=datetime X_Forwarded_ForIP=string SourceAddress=string DestinationAddress=string SourcePort=int DestinationPort=int Protocol=string Action=string RuleName=string \
  --plan Analytics \
  --retention-time 30
    5. Create a Data Collection Rule: The Data Collection Rule (DCR) processes the pipeline by mapping incoming JSON data streams to your Sentinel workspace.
      1. In the Azure Portal, create a new DCR using the Custom platform type.
      2. Ensure the DCR region matches your workspace, and select your existing DCE on the Basics tab.
      3. On the Resources tab, associate your Log Analytics Workspace.
    6. Configure Schema and Transformation: On the Collect and Deliver tab of your DCR, select Custom Text Logs or Logs Ingestion API as your data source, specify your PaloAltoTraffic_CL table, and open the Transformation Editor. Apply the following KQL transformation to map the mandatory timestamp and route hyphenated fields. All other standard fields defined in the table will automatically pass through:
      Example Transformation: 
      source
| extend TimeGenerated = todatetime(TimeGenerated)
| extend X_Forwarded_ForIP = tostring(['X-Forwarded-ForIP'])
| project-away ['X-Forwarded-ForIP']
    7. Configure the Log Forwarding Profile: In the Strata Logging Service console, map the Azure credentials as follows:
      SLS FieldAzure Value
      URL (Destination)https://<DCE-Name>.<Region>.ingest.monitor.azure.com/dataCollectionRules/<DCR-Immutable-ID>/streams/Custom-PaloAltoTraffic_CL?api-version=2023-01-01
      MS Tenant IDApp Registration Directory (tenant) ID
      Client Request IDApp Registration Application (client) ID
      Client SecretApp Registration Secret Value
      Token Endpointhttps://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token
      Scopehttps://monitor.azure.com/.default

    Migrate from Data Collector API (Legacy)

    The Azure Monitor HTTP Data Collector API retires September 14, 2026. Complete your migration before this date to avoid log forwarding interruptions. If you still need the legacy web app steps during your migration window, see (Legacy) Create and Deploy a Agent Web Application.
    The Azure Monitor HTTP Data Collector API retires September 14, 2026. If you use the legacy data sink, you must update your authorization to use DCRs.
    For more reference, please see the migration guide from Microsoft.
    If you have an existing custom table:
    1. Migrate the table to ingest data into the same table using the Log Ingestion API.
    2. Create a new table to ingest data using the Log Ingestion API and delete the legacy table after verification.
    Technical Considerations
    • Case Sensitivity — Column names must exactly match the defined schema.
    • Required Fields — The TimeGenerated field (datetime) is mandatory for all tables.
    • Schema Enforcement — Azure drops any fields not explicitly declared in the table schema or accounted for in the transformation block.
    • Ingestion Confirmation — An HTTP 204 response from the DCE confirms receipt of data by the endpoint but does not guarantee successful ingestion into the destination table if a schema mismatch exists.
    • Data Types — Format boolean fields as JSON true or false. Define hexadecimal strings (e.g., Flags, ActionFlags) as strings.
    Palo Alto Field TypeExamplesAzure Data TypeNotes
    Time/Date
    receive_time, time_generated
    		datetime
    Identifiers/IPs
    src, dst, rule, sessionid
    		string
    Counts/Bytes
    bytes, packets, repeatcnt
    		longRecommended for high-volume traffic.
    Ports
    sport, dport
    		int

    © 2026 Palo Alto Networks, Inc. All rights reserved.