fix2

Author: EdB-MSFT

articles/sentinel/azure-storage-blob-connector-troubleshoot.md

@@ -0,0 +1,108 @@
+---
+title: Troubleshoot Azure Storage Blob connector issues - Microsoft Sentinel
+description: Troubleshoot Azure Storage Blob connector issues in Microsoft Sentinel.
+author: EdB-MSFT
+ms.author: edbaynash
+ms.topic: troubleshooting
+ms.date: 02/05/2026
+ms.service: microsoft-sentinel
+
+#Customer intent: As a security engineer, I want to troubleshoot Azure Storage Blob connector issues so that I can ensure seamless log ingestion into Microsoft Sentinel.
+
+---
+
+# Troubleshoot Azure Storage Blob connector issues
+
+The Azure Storage Blob connector simplifies the process of ingesting data from Azure Storage Blobs to Microsoft Sentinel.
+
+This article describes how to quickly identify the cause of issues occurring with the Azure Storage Blob connector so you can find the steps needed to resolve the issues.
+
+Learn how to [connect Microsoft Sentinel to Azure Storage Blob to ingest data](setup-azure-storage-connector.md).
+
+## Microsoft Sentinel doesn't receive data from the Azure Storage Blob connector
+
+The logs for the Azure Storage Blob connector aren't visible in the Microsoft Sentinel workspace for more than 30 minutes after the connector was connected.
+
+Before you search for a cause and solution, review these considerations:
+
+- It can take around 20-30 minutes from the moment the connector is connected until data is ingested into the workspace.
+- The connector's connection status indicates that a collection rule exists; it doesn't indicate that data was ingested. If the status of the Azure Storage Blob connector is green, there's a collection rule for one of the data types, but still no data.
+
+### Determine the cause of your problem
+
+In this section, we cover these causes:
+
+1. [The data isn't ingested to the Azure Storage Blob container.](#cause-1-the-data-isnt-ingested-to-the-azure-storage-blob-container)
+1. [The Azure Storage queue isn't receiving notifications for blob created events.](#cause-2-the-azure-storage-queue-isnt-receiving-notifications-for-blob-created-events)
+1. [The Azure Storage Blob connector permissions or networking policies aren't set properly.](#cause-3-the-azure-storage-blob-connector-permissions-or-networking-policies-arent-set-properly)
+1. [The queue message content or Azure Storage Blob data format is invalid.](#cause-4-the-queue-message-content-or-azure-storage-blob-data-format-is-invalid)
+
+> [!TIP]
+> If the health feature isn't enabled, [enable it](enable-monitoring.md).
+
+### Cause 1: The data isn't ingested to the Azure Storage Blob container
+
+The upstream system isn't successfully delivering data to the expected storage container.
+
+#### Solution: Verify data ingress on the storage account
+
+1. In the Azure portal, navigate to the storage account and review the **Metrics** to confirm ingress activity.
+1. Check that the expected storage container is receiving blobs.
+1. If the container is empty, review the upstream producing system for issues delivering data to the account.
+
+### Cause 2: The Azure Storage queue isn't receiving notifications for blob created events
+
+Event Grid system topics facilitate blob created events from the source storage account to the target storage queue. If the system topic or subscription isn't configured correctly, events won't flow to the queue.
+
+#### Solution: Verify Event Grid system topic and subscription
+
+1. Check the resource group's deployments for any failures when creating the system topic resources.
+1. If the Event Grid system topic and subscription were successfully created, review the metrics of the Event Grid subscription. Consider [enabling diagnostic logs](/azure/event-grid/enable-diagnostic-logs-topic).
+1. Verify that the subscription source maps to the correct storage account and target queue.
+1. Review the filtering criteria specified under **Additional Features** to ensure it matches expected patterns.
+1. The Event Grid subscription's metrics should show events that match the blob created criteria. If the metrics indicate **Delivery Failed Events**, review the Event Grid's diagnostic logs and continue to the next section for policy-related issues.
+
+### Cause 3: The Azure Storage Blob connector permissions or networking policies aren't set properly
+
+This issue is caused by incorrect role-based access policies applied to the storage account(s) hosting the blob container and/or the message queue, or by network security settings blocking traffic.
+
+#### Solution: Verify permissions and networking
+
+Review the [Set up your Azure Storage connector](setup-azure-storage-connector.md) documentation and ensure the following are in place:
+
+**Service principal and RBAC checks:**
+
+1. Verify that the application ID of the service principal matches the application IDs per Azure environment specified in the [Azure Storage Blob connectors API reference](data-connection-rules-reference-azure-storage.md#authentication-configuration).
+1. Verify that the service principal has the **Storage Blob Data Reader** role on the storage accounts hosting the blob container.
+1. Verify that the service principal has the **Storage Queue Data Contributor** role on the storage accounts hosting the message queues.
+
+> [!TIP]
+> Clues to failures of this kind are exposed on connectivity check issues during installation and in the `SentinelHealth` table for active connectors.
+
+**Network security checks:**
+
+If the service principal and RBAC troubleshooting doesn't surface an issue, the network security settings on the storage account(s) might be causing the problem. The network security solution for this connector relies on [Network Security Perimeter](/azure/private-link/network-security-perimeter-concepts) based protection. Review the [Enable network security](enable-storage-network-security.md) documentation to ensure all steps were followed correctly, and check the following:
+
+- If you aren't using NSP to protect the resource, check the storage account's **Networking** blade to ensure public network access is enabled.
+- Verify that the storage account isn't using selected network limits via IPv4 CIDR addresses. This approach doesn't work with the connector's IP traffic due to the documented [storage firewall limitations](/azure/storage/common/storage-network-security-limitations#restrictions-for-ip-network-rules) around IP ranges and region affinity of the caller and the account.
+- If NSP is being used to protect the account, enable the [perimeter's diagnostic logs](/azure/private-link/network-security-perimeter-diagnostic-logs) to troubleshoot. NSP rules only apply to resources in **Enforced** access mode. Alternatively, **Transition** mode doesn't apply the rules on the resource while continuing to collect telemetry on traffic patterns. Review the profile associated with the storage account(s):
+  - Check that inbound rules for the producer are in place. Check for blob write failures on the producer.
+  - Check that inbound rules for the connector are in place per the [Enable network security](enable-storage-network-security.md) documentation.
+  - Check that inbound rules include a rule for the subscription of the storage account and Event Grid system topic. Ensure the Event Grid system topic subscription is using **System Assigned** managed identity-based delivery.
+
+### Cause 4: The queue message content or Azure Storage Blob data format is invalid
+
+The blob data format or queue message structure doesn't match the expected configuration.
+
+#### Solution: Verify data format and queue messages
+
+1. Check the `SentinelHealth` table for clues about invalid messages. If the health data references invalid data, verify that the format of the blobs uploaded to storage matches the serialization and compression model set in the connector definition.
+1. Queue message format exceptions result from messages in the queue not aligning to the `EventGridSchema` for `BlobCreated` events. Check the Event Grid subscription's **Filters** section to confirm:
+   - The filter is set to **Blob Created**.
+   - The event schema is **EventGridSchema**.
+
+## Next steps
+
+In this article, you learned how to quickly identify causes and resolve common issues with the Azure Storage Blob connector.
+
+We welcome feedback, suggestions, requests for features, bug reports or improvements and additions. Go to the [Microsoft Sentinel GitHub repository](https://github.com/Azure/Azure-Sentinel) to create an issue or fork and upload a contribution.

articles/sentinel/enable-storage-network-security.md

@@ -33,10 +33,11 @@ To complete this setup, ensure you have the following permissions:
 To enable network security on the storage resources integrated with your Azure Storage connector, you need to create a Network Security Perimeter (NSP) and associate the storage account with it. Then configure the necessary rules to allow traffic from Event Grid and other relevant sources while blocking unauthorized access. Use the following steps to complete the configuration.
 
 ### Create a Network Security Perimeter
-1. In the Azure portal, search for *Network Security Perimeters*.
+1. In the Azure portal, search for *Network Security Perimeters*
+
 1. Select **Create**.
 1. Configure the following fields:
-   - **Subscription** and **Resource group**
+   - **Subscription** and **Resource group**.
    - **Name**, for example `storageblob-connectors-nsp`
    - **Region**. The region must be the same region as the storage account.
    - **Profile name**: Enter a profile name or accept the default.
@@ -45,7 +46,8 @@ To enable network security on the storage resources integrated with your Azure S
    :::image type="content" source="./media/enable-storage-network-security/create-network-security-perimiter.png" lightbox="./media/enable-storage-network-security/create-network-security-perimiter.png" alt-text="A screenshot showing the creation of a Network Security Perimeter in the Azure portal.":::
 
 ### Associate the Storage Account with the Network Security Perimeter
-1. Open your newly created Network Security Perimeter resource.
+1. Open your newly created Network Security Perimeter resource
+
 1. Select **Profiles**, then select the profile name you used when creating the NSP resource.
 1. Select **Associated resources**.
 1. Select **Add**.
@@ -59,11 +61,13 @@ Access mode is set to **Transition** by default, allowing you to validate the co
 ### Enable System-Assigned Identity on Event Grid System Topic
 
 1. From your storage account, navigate to the **Events** tab.
+
 1. Select the **System Topic** used to stream blob creation events to the storage queue.
 
    :::image type="content" source="./media/enable-storage-network-security/select-event-system-topic.png" lightbox="./media/enable-storage-network-security/select-event-system-topic.png" alt-text="A screenshot showing the Event tab for Storage Accounts in the Azure portal.":::
 
-1. Select **Identity**
+1. Select **Identity**.
+
 1. On the **System assigned** tab, set the **Status** to **On**.
 1. Select **Save**.
 1. After saving, copy the **Object ID** of the managed identity for later use.
@@ -73,25 +77,26 @@ Access mode is set to **Transition** by default, allowing you to validate the co
 
 ### Grant RBAC permissions on the Storage Queue
 
-1. Open the **Storage Account**
-1. Select **Access Control (IAM)**
-1. Select **Add**
-1. Search for and select the *Storage Queue Data Message Sender* role
-1. Select the **Members** tab and then **Select members**
+1. Navigate to your **Storage Account**.
+
+1. Select **Access Control (IAM)**.
+1. Select **Add**.
+1. Search for and select the *Storage Queue Data Message Sender* role.
+1. Select the **Members** tab and then **Select members**.
 1. In the **Select members** pane, paste the Object ID for the Event Grid system topic managed identity created in the previous step
 1. Select the managed identity and then click **Select**
-1. Select **Review + assign** to complete the role assignment
-   
+1. Select **Review + assign** to complete the role assignment   
    :::image type="content" source="./media/enable-storage-network-security/add-role-assignment.png" lightbox="./media/enable-storage-network-security/add-role-assignment.png" alt-text="A screenshot showing the assignment of the Storage Queue Data Message Sender role to a managed identity in the Azure portal.":::
 
 
 ### Enable Managed Identity on the event subscription
 
-1. Open the **Event Grid System Topic**
-1. Select the event subscription targeting the queue
-1. Select the **Additional settings** tab
-1. Set **Managed identity type** to **System-assigned**
-1. Select **Save**
+1. Open the **Event Grid System Topic**.
+
+1. Select the event subscription targeting the queue.
+1. Select the **Additional settings** tab.
+1. Set **Managed identity type** to **System-assigned**.
+1. Select **Save**.
 1. Review the Event Grid subscriptions metrics to validate messages are still successfully published to the storage queue after this update.
 
 :::image type="content" source="./media/enable-storage-network-security/set-additional-features.png" lightbox="./media/enable-storage-network-security/set-additional-features.png" alt-text="A screenshot showing the enabling of managed identity for an Event Grid subscription in the Azure portal.":::
@@ -105,16 +110,18 @@ The following rules are required to allow Event Grid to deliver messages to the
 
 Event Grid delivery doesn't originate from fixed public IPs. The NSP validates delivery using subscription identity.
 
-1. Navigate to Network Security Perimeter and select your NSP
-1. Select **Profiles** and then select the profile associated with your storage account
-1. Select **Inbound access rules** and then select **Add**
+1. Navigate to Network Security Perimeter and select your NSP.
+
+1. Select **Profiles** and then select the profile associated with your storage account.
+1. Select **Inbound access rules** and then select **Add**.
 
    :::image type="content" source="./media/enable-storage-network-security/inbound-access-rules.png" lightbox="./media/enable-storage-network-security/inbound-access-rules.png" alt-text="A screenshot showing the Inbound access rules page in the Azure portal.":::
 
-1. Enter a **Rule name**, for example `Allow-Subscription`
-1. Select *Subscription* from the **Source type** drop-down
-1. Select your subscription from the **Allowed Sources** drop-down
-1. Select **Add** to create the rule
+1. Enter a **Rule name**, for example `Allow-Subscription`.
+
+1. Select *Subscription* from the **Source type** drop-down.
+1. Select your subscription from the **Allowed Sources** drop-down.
+1. Select **Add** to create the rule.
 
    :::image type="content" source="./media/enable-storage-network-security/add-inbound-rule.png" lightbox="./media/enable-storage-network-security/add-inbound-rule.png" alt-text="A screenshot showing the creation of an inbound access rule to allow a subscription in the Azure portal.":::
 
@@ -125,20 +132,21 @@ Event Grid delivery doesn't originate from fixed public IPs. The NSP validates d
 #### Rule 2: Allow Scuba service IP ranges
 
 
-1. Create a second **Inbound access rules**
-1. Enter a **Rule name**, for example `Allow-Scuba`
-1. Select **IP address ranges** from the **Source type** drop-down
+1. Create a second **Inbound access rules**.
+
+1. Enter a **Rule name**, for example `Allow-Scuba`.
+1. Select **IP address ranges** from the **Source type** drop-down.
 1. Open the [service tag download](/azure/virtual-network/service-tags-overview#discover-service-tags-by-using-downloadable-json-files) page. 
-1. Select your cloud, for example **Azure Public** 
+1. Select your cloud, for example **Azure Public** .
 1. Select the **Download** button and open the downloaded file to get the list of IP ranges.
 1. Find the `Scuba` service tag and copy the associated IPv4 ranges.
 1. Paste the IPv4 ranges into the **Allowed Sources** field after removing any quotes and trailing commas.
-1. Select **Add** to create the rule
+1. Select **Add** to create the rule.
 
-> [!IMPORTANT]
-> Remove the quotes from the IP ranges and ensure that there's no trailing comma on the last entry before pasting them into the **Allowed Sources** field.
+   > [!IMPORTANT]
+   > Remove the quotes from the IP ranges and ensure that there's no trailing comma on the last entry before pasting them into the **Allowed Sources** field.
 
-:::image type="content" source="./media/enable-storage-network-security/scuba-ipv4-addresses.png" lightbox="./media/enable-storage-network-security/scuba-ipv4-addresses.png" alt-text="A screenshot showing a part of the ServiceTags_Public.json file with the Scuba service tag and IPv4 ranges highlighted.":::
+   :::image type="content" source="./media/enable-storage-network-security/scuba-ipv4-addresses.png" lightbox="./media/enable-storage-network-security/scuba-ipv4-addresses.png" alt-text="A screenshot showing a part of the ServiceTags_Public.json file with the Scuba service tag and IPv4 ranges highlighted.":::
 
 
 ### Validate and enforce
@@ -153,11 +161,12 @@ Consider enabling network security perimeters diagnostic logs to review collecte
 
 Once validation is successful set the access mode to **Enforced** as follows:
 1. From the Network Security Perimeter page, under **Settings**, select **Associated resources**.
+
 1. Select the storage account.
 1. Select **Change access mode**.
 1. Select **Enforced** and then **Save**.
 
-:::image type="content" source="./media/enable-storage-network-security/change-access-mode.png" lightbox="./media/enable-storage-network-security/change-access-mode.png" alt-text="A screenshot showing how to change the access mode of a storage account associated with a Network Security Perimeter in the Azure portal." :::
+   :::image type="content" source="./media/enable-storage-network-security/change-access-mode.png" lightbox="./media/enable-storage-network-security/change-access-mode.png" alt-text="A screenshot showing how to change the access mode of a storage account associated with a Network Security Perimeter in the Azure portal." :::
 
 ### Post-enforcement validation
 
@@ -169,11 +178,12 @@ Use the diagnostic logs to investigate and resolve any issues that arise. Review
 
 Setting the storage account to **Secured by Perimeter** ensures that all traffic to the storage account is evaluated against the Network Security Perimeter rules. This adds an additional layer of security by enforcing that all access to the storage account goes through the perimeter.
 
-1. Navigate to your **Storage Account**
-1. Under **Security + networking**, select **Networking**
-1. Under **Public network access**, select **Manage**
-3. Set **Secured by Perimeter (Most restricted)**
-4. Select **Save**
+1. Navigate to your **Storage Account**.
+
+1. Under **Security + networking**, select **Networking**.
+1. Under **Public network access**, select **Manage**.
+3. Set **Secured by Perimeter (Most restricted)**.
+4. Select **Save**.
 
 :::image type="content" source="./media/enable-storage-network-security/set-storage-networking.png" lightbox="./media/enable-storage-network-security/set-storage-networking.png" alt-text="A screenshot showing how to set a storage account to 'Secured by Perimeter' in the Azure portal.":::