4.2 Enabling and Connecting Azure Resources

Enabling and Connecting Azure Resources

Introduction

Subsection 4.1 mapped the architecture. This subsection puts it into practice: enabling Defender plans for your Azure subscription, configuring auto-provisioning to deploy monitoring agents automatically, connecting specific resource types, and verifying that protection is active. The goal is a fully connected Azure environment where every resource is visible to Defender for Cloud and protected by the appropriate Defender plan.

Enabling Defender plans at the subscription level

Defender plans are enabled per Azure subscription in Environment Settings (Defender for Cloud → Environment settings → select your subscription → Defender plans). Each plan has an on/off toggle and, for some plans, a tier selection (P1 vs P2 for Servers).

When you enable a plan, protection begins immediately for existing resources of that type. New resources deployed after plan enablement are automatically covered. You do not need to individually register each resource — plan enablement at the subscription level covers all resources in that subscription.

Auto-provisioning: deploying monitoring agents

CWP threat detection requires monitoring agents on the resources being protected. For virtual machines, this means the Azure Monitor Agent (AMA) or the MDE sensor (for Defender for Servers). Auto-provisioning automatically deploys these agents to new and existing VMs without manual installation.

Navigate to Defender for Cloud → Environment settings → your subscription → Auto provisioning. Enable the provisioning of the agents relevant to your enabled plans. For Defender for Servers, this includes the MDE sensor (provides endpoint detection) and the Azure Monitor Agent (provides log collection for security event analysis).

How auto-provisioning works. When you enable auto-provisioning for an agent type, Defender for Cloud creates an Azure Policy assignment that evaluates all VMs in the subscription. VMs that do not have the agent installed are flagged as non-compliant. The auto-provisioning mechanism then deploys the agent using a VM extension. This process runs continuously — any new VM deployed in the subscription is evaluated and provisioned within minutes.

Auto-provisioning for specific plans:

Defender for Servers auto-provisions the MDE sensor (the same sensor from Module 2, but deployed through Defender for Cloud rather than through Intune or GPO) and the vulnerability assessment extension (which scans the VM’s software inventory for known CVEs). When auto-provisioning deploys the MDE sensor, the VM appears in both the Defender for Cloud inventory and the MDE device inventory — providing both cloud security posture assessment and endpoint detection and response.

Defender for SQL auto-provisions the SQL Server extension that enables SQL-level threat detection (query analysis for SQL injection, anomalous access pattern detection).

Defender for Containers auto-provisions the Defender sensor (a DaemonSet in AKS) and the Azure Policy extension for Kubernetes (which enforces pod security standards).

Discovering unprotected resources

Even after enabling Defender plans and auto-provisioning, some resources may remain unprotected — VMs that failed agent provisioning, resources in subscriptions where plans are not enabled, or resource types that do not have a corresponding Defender plan.

Defender for Cloud’s asset inventory (Defender for Cloud → Inventory) shows every resource in your connected subscriptions with its protection status. Filter by “Defender for Cloud” → “Unmonitored” to see resources that are not covered by any Defender plan. These represent your blind spots — resources where an attacker could operate without generating security alerts.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Find unmonitored resources in Sentinel
SecurityRecommendation
| where TimeGenerated > ago(1d)
| where RecommendationDisplayName has "should be enabled"
    or RecommendationDisplayName has "agent should be installed"
| extend ResourceName = tostring(Properties.resourceDetails.ResourceName)
| extend ResourceType = tostring(Properties.resourceDetails.ResourceType)
| extend Severity = tostring(Properties.severity)
| project TimeGenerated, Severity, RecommendationDisplayName,
    ResourceName, ResourceType
| order by Severity asc

Verifying protection coverage

After enabling plans and configuring auto-provisioning, verify coverage:

Check 1: Secure Score. Has your Secure Score improved since enabling plans? Newly enabled plans may add recommendations that initially lower your score (more recommendations discovered = more items to fix), but agent deployment recommendations should resolve as auto-provisioning completes.

Check 2: Resource coverage map. Defender for Cloud → Defender plans → Coverage shows the percentage of each resource type that is protected. Target 100% coverage for production workloads. Development and test workloads may have lower coverage based on your risk tolerance.

Check 3: Agent health. For VMs, check that the monitoring agent is reporting. Defender for Cloud → Inventory → filter by “Monitored by” to see which VMs have active agents. VMs showing “Not monitored” need investigation: did auto-provisioning fail? Is the VM’s network blocking agent communication? Is the VM powered off?

Check 4: Test alert generation. Defender for Servers provides a detection test similar to MDE’s detection test (Module 2). Run a test command on a protected VM that generates a benign security alert, verifying the complete detection pipeline from agent to alert.

Log Analytics workspace and data collection rules

Defender for Cloud collects security data from protected resources and sends it to a Log Analytics workspace. By default, Defender for Cloud creates a default workspace per subscription. You can configure it to use your existing Sentinel workspace instead — this is the recommended configuration because it puts Defender for Cloud data alongside your other security data, enabling cross-source KQL queries.

Configure the workspace in Environment settings → your subscription → Auto provisioning → Log Analytics agent/Azure Monitor Agent → Configuration → select your Sentinel workspace instead of the default.

Data collection rules (DCRs) control what data is collected from VMs. For Defender for Servers, the key decision is the security event collection level: None (no Windows security events — only Defender for Cloud alerts), Minimal (critical security events only — authentication failures, process creation for known malicious patterns), Common (a broader set including successful authentications, group membership changes, and process creation), and All Events (every Windows security event — comprehensive but high data volume and cost).

For most SOC deployments, Common is the recommended level — it provides enough security event data for investigation without the cost of All Events. Adjust based on your investigation requirements: if you frequently need detailed process creation events for forensic analysis, consider All Events for production servers.

1
2
3
4
5
6
7

// Verify which VMs are sending security events to your workspace
Heartbeat
| where TimeGenerated > ago(1h)
| where Category == "Direct Agent" or Category == "Azure Monitor Agent"
| extend AgentType = iff(Category == "Azure Monitor Agent", "AMA", "Legacy MMA")
| summarize LastHeartbeat = max(TimeGenerated) by Computer, AgentType, RemoteIPCountry
| order by LastHeartbeat desc

The agent architecture: MDE sensor vs Azure Monitor Agent

Defender for Servers uses two agents, each serving a different purpose. Understanding which agent does what prevents confusion during troubleshooting.

The MDE sensor provides endpoint detection and response — the same capabilities from Module 2. It monitors process execution, network connections, file operations, and registry changes. It generates the security alerts that appear in both Defender for Cloud and MDE. The MDE sensor communicates directly with the MDE cloud service (not through the Log Analytics workspace).

The Azure Monitor Agent (AMA) collects log data and sends it to the Log Analytics workspace. It collects Windows security events, Linux syslog events, and performance data. This data is used by Sentinel analytics rules and KQL investigations. AMA does not generate alerts directly — it provides the raw log data that Sentinel queries consume.

Both agents are needed for full Defender for Servers protection: MDE for real-time threat detection and response actions, AMA for log collection that enables Sentinel investigation and custom detection rules. Auto-provisioning deploys both when Defender for Servers is enabled.

Common auto-provisioning failures and troubleshooting

Auto-provisioning does not always succeed. Understanding the common failure modes saves hours of debugging.

Failure 1: VM extension installation blocked by policy. If an Azure Policy denies the installation of VM extensions (some organisations restrict extensions for compliance reasons), auto-provisioning fails silently. The VM appears as “Not monitored” in the inventory. Resolution: create a policy exemption for the Defender for Cloud extensions (MDE, AMA, vulnerability assessment).

Failure 2: Network connectivity. The agents require outbound HTTPS connectivity to Microsoft cloud endpoints. VMs in isolated VNets without internet access (or with overly restrictive NSGs) cannot reach the agent registration endpoints. Resolution: configure service tags in the NSG to allow outbound traffic to AzureMonitor, AzureActiveDirectory, and AzureResourceManager service tags, or deploy a private link for Azure Monitor.

Failure 3: Unsupported OS version. Some older operating systems do not support AMA or MDE. Windows Server 2012 R2 requires the legacy Log Analytics agent (MMA) rather than AMA. Linux distributions without systemd may not support AMA. Check the supported OS matrix in the Microsoft documentation.

Failure 4: Resource group permissions. Auto-provisioning creates VM extensions, which requires the Contributor or VM Contributor role on the resource group. If the Defender for Cloud service principal lacks sufficient permissions, extension deployment fails. Resolution: verify the “Security Admin” role assignment at the subscription level includes the necessary permissions for extension management.

Troubleshooting workflow: When a VM shows as “Not monitored,” check in this order: (1) Is Defender for Servers enabled on the subscription? (2) Is auto-provisioning enabled? (3) Is the VM’s OS supported? (4) Does the VM have outbound connectivity? (5) Are there Azure Policy restrictions blocking extensions? (6) Check the VM’s extension status in the Azure portal (VM → Extensions) — failed extensions show error messages that identify the specific failure.

Knowledge check