- Goal
- Why I’m Doing This
- Identifying HP Laptop #2
- An Existing Private Network: Tailscale
- Checking for Microsoft Defender
- Preparing Debian
- Adding Microsoft’s Debian Repository
- Installing Microsoft Defender for Endpoint
- The Most Important Lesson of the Session
- The Microsoft Account Discovery
- Where the Lab Stands
- Next Goal
Goal
Today’s goal was to begin bringing a second physical HP laptop into my developing Microsoft security lab.
Rather than building everything with simulated machines, I want to learn using actual computers on my home network. The larger objective is to create a small but realistic environment where I can learn how enterprise security tools discover endpoints, collect telemetry, detect suspicious activity, generate alerts, and support investigations.
This second laptop gives me another real Linux endpoint to work with.
The machine is an HP Pavilion x360 Convertible 14m-ba0xx running:
Debian GNU/Linux 13.6 (trixie)
Linux kernel 6.12.94+deb13-amd64
x86-64
Wi-Fi interface: wlp2s0
LAN address: 192.168.12.242
The hostname is currently:
ommarchy
That name comes from the laptop’s earlier Omarchy configuration, even though the system we were working from today identifies itself as Debian 13.
Why I’m Doing This
The purpose isn’t simply to install another antivirus program.
I’m trying to understand the architecture behind an enterprise security operation.
A simplified version of what I’m building looks like this:
Microsoft Defender
Security Portal
│
│
Security telemetry
│
┌─────────────┴─────────────┐
│ │
Debian Desktop Linux Endpoints
Admin / SOC │
Workstation ┌─────┴─────┐
│ │
HP Laptop #1 HP Laptop #2
Debian 13
Eventually, I want to be able to sit at the Debian desktop and investigate activity occurring on the other systems.
That means learning the distinction between several concepts that initially sound like the same thing:
installing an endpoint agent, onboarding an endpoint, licensing the endpoint, collecting telemetry, detecting activity, generating alerts, and investigating those alerts.
Today we encountered those distinctions for real.
Identifying HP Laptop #2
Before installing anything, we established exactly which machine we were working with.
hostnamectl identified the computer as an:
HP Pavilion x360 Convertible 14m-ba0xx
and confirmed Debian 13.
I then examined its network interfaces:
ip -br addr
The wireless interface was:
wlp2s0 UP 192.168.12.242/24
That gives us a concrete network identity for this endpoint.
This matters because once several machines begin producing security telemetry, knowing which physical system corresponds to which hostname, IP address, operating system, and security-agent identity becomes essential.
An Existing Private Network: Tailscale
Another useful part of the lab already exists.
I currently use Tailscale on several devices, including my Debian desktop, the original HP laptop, my iPad, and my iPhone.
That gives the lab another interesting dimension.
Eventually we’ll be able to examine legitimate Tailscale traffic and learn how security tools represent that traffic. Instead of treating every unfamiliar network connection as suspicious, I’ll need to learn what normal behavior looks like first.
That’s an important part of security monitoring: establishing a baseline.
Checking for Microsoft Defender
I first checked whether Microsoft’s Linux Defender agent was already installed:
command -v mdatp
There was no result.
That established that this machine was an unmanaged Linux endpoint from Microsoft’s perspective.
Instead of inheriting a preconfigured system, we could therefore experience the process of bringing a new Linux computer into an enterprise security environment from the beginning.
Preparing Debian
I checked several prerequisites and discovered that gpg was already installed, while curl and libplist-utils were missing.
I installed them with:
sudo apt update
sudo apt install curl libplist-utils
I subsequently installed:
sudo apt install apt-transport-https
These prepared Debian to securely retrieve and verify Microsoft’s packages.
Adding Microsoft’s Debian Repository
I downloaded Microsoft’s Debian 13 repository definition:
curl -o microsoft.list \
https://packages.microsoft.com/config/debian/13/prod.list
Inspecting it showed:
deb [arch=amd64,arm64,armhf signed-by=/usr/share/keyrings/microsoft-prod.gpg] https://packages.microsoft.com/debian/13/prod trixie main
I deliberately inspected this before trusting it.
The repository definition was then moved into Debian’s APT configuration:
sudo mv ./microsoft.list \
/etc/apt/sources.list.d/microsoft-prod.list
I also installed Microsoft’s current signing key for Debian 13.
Afterward:
sudo apt update
successfully contacted:
https://packages.microsoft.com/debian/13/prod
with no signature errors.
At that point Debian could securely install software directly from Microsoft’s package repository.
Installing Microsoft Defender for Endpoint
We installed the Linux Defender agent:
sudo apt install mdatp
APT downloaded approximately 155 MB, resulting in roughly 461 MB of installed software.
The installed Defender application version was:
101.26072.0004
This gave us a genuine Microsoft Defender for Endpoint Linux installation—not a simulated sensor or substitute security application.
The Most Important Lesson of the Session
After installation, we ran:
mdatp health
The result was extremely useful.
Defender reported:
healthy : false
licensed : false
org_id : ""
but it also reported:
cloud_enabled : true
definitions_status : "up_to_date"
and showed that real-time protection was available.
At first glance, healthy: false could look like an installation failure.
It wasn’t.
The important message was:
ATTENTION: No license found.
This taught us an important distinction:
Installing Microsoft Defender for Endpoint is not the same thing as onboarding a computer into Microsoft Defender.
The software exists on the laptop.
But the laptop doesn’t yet belong to a Microsoft Defender organization.
Conceptually we’re here:
Install agent
│
▼
mdatp
│
✓ COMPLETE
│
▼
Create / access Microsoft organization
│
○ NEXT
│
▼
Onboard endpoint
│
▼
Assign organization / licensing
│
▼
Send security telemetry
│
▼
Microsoft Defender portal
│
▼
Detect → Investigate → Respond
That discovery alone made today’s exercise worthwhile.
The Microsoft Account Discovery
When I attempted to access the Microsoft Defender security portal, we encountered another real-world enterprise concept.
My normal Microsoft account is a personal Microsoft account.
The Defender portal returned:
AADSTS500200
and explained that personal Microsoft accounts aren’t supported for this application unless they’re explicitly invited into an organization.
This exposed another important distinction:
Personal Microsoft Account
≠
Microsoft Entra Organizational Identity
Microsoft Defender for Endpoint is fundamentally an organizational security platform.
The endpoint needs to belong to an organization, and administrators access that organization through an appropriate organizational identity.
Therefore, instead of blindly creating accounts or purchasing subscriptions, we stopped.
That was intentional.
Where the Lab Stands
I now have a very useful halfway state:
HP LAPTOP #2
─────────────────────────────────
Debian 13.6 ✓
Network connectivity ✓
Microsoft repository ✓
Microsoft signing key ✓
Defender mdatp installed ✓
Security definitions ✓
Cloud capability ✓
Microsoft organization NEXT
Defender licensing NEXT
Endpoint onboarding NEXT
Telemetry NEXT
Detection testing LATER
Investigation LATER
─────────────────────────────────
Nothing is broken.
The endpoint is simply waiting to be onboarded.
Next Goal
The next session will focus on the Microsoft side rather than the Debian side.
Before spending money, we’ll determine an appropriate legitimate Microsoft organizational/Defender environment for a small learning lab.
Once that exists, we’ll obtain Microsoft’s Linux onboarding package and connect this HP laptop to the organization.
Then the really interesting part begins.
Instead of asking:
“Is Defender installed?”
we’ll be able to ask:
“What can Defender actually see?”
From there I can begin generating safe, controlled activity on our own machines, observe the resulting telemetry, examine alerts, and learn the investigation workflow used by an actual endpoint detection and response platform.
That’s much closer to the kind of hands-on security learning I wanted this lab to provide.