So You've Deployed Sentinel. Now What? A Guide to Data Connectors

Alright, class, take your seats. In our last lesson, you successfully deployed a shiny new Microsoft Sentinel instance. It’s sitting there, full of potential, looking clean and pristine. It's also completely useless.

A Security Information and Event Management (SIEM) tool without data is like a detective without clues. It’s just an expensive (well, if you read my last article, you know it's not for 30 days!) empty room. Today, we’re going to fix that. We’re going to talk about the lifeblood of Sentinel: Data Connectors. And yes, there will be coffee.

This is where the magic begins.

What on Earth is a Data Connector?

Data Connector is a bridge. It’s a pre-built integration that allows Sentinel to reach out to another service (like Entra ID, your firewall, or a cloud app) and pull in its logs.

Think of it this way: Entra ID is constantly scribbling notes about who is signing in. These notes are called "logs," and they get stored in tables inside Sentinel, like SigninLogs. Once those logs are in Sentinel, you can use them for everything: running KQL queries, building detection rules, and investigating those glorious incidents we all know and love (Failed Login Attempts to Azure Portal!)

The best place to start your connector journey is the Content Hub. This is Sentinel's built-in app store, packed with solutions from Microsoft and its partners. It's a treasure trove of connectors, analytic rules, playbooks, and workbooks. Go explore it now. It's free.

The Professor's Three Tiers of Connectors

I like to break down connectors into three categories, based on how much coffee you'll need to get them working.

Tier 1: The "Click-and-Go" Crew (Microsoft & Partners)

These are the easy ones. They are deeply integrated into the Azure ecosystem and are designed to be turned on with a few clicks. We're talking about things like:

• Microsoft Entra ID
• Microsoft Defender XDR
• Office 365
• Azure Key Vault

These are your bread and butter. Setting them up is usually a painless, straightforward process. You have no excuse not to enable these.

Tier 2: The "Okay, I Need to Read the Manual" Squad (Data Collection Rules)

This tier is a bit more involved. It usually requires an agent on your machines to forward logs. Think of things like:

• Syslog from Linux machines via AMA
• Windows Security Events via AMA
• Custom Logs via AMA

"AMA" stands for the Azure Monitor Agent. This usually means you'll need a log forwarder—a machine (most likely a Linux distro) that collects logs from various sources and sends them up to Sentinel. It's slightly more complex, but this is how you get rich data from your on-premises servers and other non-Azure native sources.

Tier 3: The "Okay, Bring Me a Second Coffee" League (APIs & Functions)

This is where things get really fun and you get to feel like a proper cloud wizard. This tier involves using APIs (Application Programming Interfaces) to pull data from third-party services that don't have a native connector. This often requires setting up an Azure Function (a small piece of serverless code) to handle the connection. Examples include:

• Cisco Meraki (using a REST API)
• 1Password (using an Azure Function)
• Cloudflare (using an Azure Function)

This requires a bit more knowledge—you'll be generating API keys and deploying small bits of code. But don't be scared! It’s incredibly powerful and allows you to pull in data from almost any source imaginable.

How to Actually Connect the Data (A Tale of Two Connectors)

Here's where many students make their first mistake.

Example 1: Microsoft Entra ID (The Easy Win)

1. Navigate to Data connectors in your Sentinel workspace (make sure to install the solution first from the Content hub!)
2. Search for "Microsoft Entra ID" and click "Open connector page."

1. You'll see a simple list of log types you can ingest. For a great start, check the boxes for:
   • Sign-in logs
   • Service principal sign-in logs
   • Audit logs

1. Click "Apply Changes."
2. That’s it. Seriously. Go get another coffee; you've earned it. In a few minutes, data will start flowing into the SigninLogs, AuditLogs, and AADServicePrincipalSigninLogs tables.

Example 2: Azure Key Vault (Slightly Fancier, Still Easy)

This one introduces a cool Azure concept: Azure Policy.

1. On the Azure Key Vault connector page, you'll see a section to launch an Azure Policy Assignment Wizard. Smash that blue button!

2. Set the Scope: Choose which subscription or resource group you want this policy to apply to. If money is tight, select only resources that are critical to your environment.

3. Configure the Policy: On the "Parameters" tab, you'll choose the Log Analytics Workspace you want to send the logs to (your Sentinel workspace).

Create a Remediation Task: This is the clever part. Check the box to "Create a remediation task." This tells the policy to go out and find any existing Key Vaults in your scope that aren't currently sending logs and automatically fix them by setting up the diagnostic settings. It's automation at its finest.

Click "Review + create."

Alternatively, you could do this manually for every single Key Vault by going to its Diagnostic settings blade and configuring it to send logs to your workspace, but who has time for that? Let Policy do the heavy lifting.

The "Is This Thing On?" Moment

After you've enabled your connectors, go back to the connector page in Sentinel. You should see the graph start to light up, showing that data is being received. The little status icon will turn green and say "Connected."

For the final glorious moment, click on one of the Data types (the table name link, like KeyVaultData). This will whisk you away to the Logs screen with a pre-written query. Run it, and you'll see the raw data, ready for you to hunt through.

You've done it. You have clues. The detective work can now begin!