Entra ID + Kerberos Basics

To bridge this back to your traditional hardware and Active Directory roots, you can think of Microsoft Entra ID as moving identity from local "servers and cables" up into the Management and Control Planes of the cloud. It is effectively a global, multi-tenant directory fabric that operates at a much higher abstraction layer than a traditional Active Directory Forest.

However, to keep your AZ-700 notes completely accurate, there is a massive architectural shift in how Entra handles this compared to traditional AD DS. They are fundamentally different animals under the hood.

Here is the exact breakdown of how Entra acts like a "higher plane" and why it doesn't use standard Forest mechanics.

1. The Core Shift: Flat Database vs. Hierarchical Tree

In traditional AD DS (Active Directory Domain Services), everything is built on a hierarchical structure:

You have a Forest, which contains Trees, which contain Domains, which contain Organizational Units (OUs).
It relies on a protocol called LDAP to query that tree, and Kerberos/NTLM to authenticate users.

Microsoft Entra ID throws the entire tree structure out the window.

It is a completely flat structure based on a massive, cloud-scale database (built on graph database technology).
There are no OUs, no Sub-Domains, and no Forest trusts inside Entra ID.
It doesn't use LDAP or Kerberos natively. Instead, it speaks the language of the modern web: HTTP/HTTPS protocols using OAuth 2.0, OpenID Connect, and SAML.

2. Why Tech Jobs Ask for a "Combo" (The Hybrid Reality)

When you see job descriptions asking for experience with both traditional AD DS and Microsoft Entra ID, it’s because 90% of enterprises live in a Hybrid Identity middle-ground. They can't just flip a switch and delete their local domain controllers overnight.

To bridge this gap, Microsoft created an identity replication tool (an SDN-like synchronization pump) called Microsoft Entra Connect:

Plaintext

Traditional AD DS (On-Premises / VM) Microsoft Entra ID (Cloud Fabric)

[ Hierarchical Tree Structure ] [ Flat Global Identity Fabric ]

[ Speaks: LDAP, Kerberos, OUs ] [ Speaks: HTTPS, OAuth, SAML ]

? ?

???????????????? [ Entra Connect ] ??????????????

(Syncs Users & Hashes)

How the combo works: Your user accounts, security groups, and passwords are still mastered in the traditional AD DS Domain Controller (either on a physical server or a VM).
The Sync: Entra Connect copies those objects and projects them up into the flat Entra ID cloud fabric.
The Result: The user gets a single identity. They use their traditional password to log into a local desktop (via Kerberos), but that same identity allows them to securely log into the Azure Portal or Office 365 over the web (via HTTPS/OAuth).

3. Entra Domain Services (The True "AD DS in the Fabric" Abstraction)

Because you are focusing heavily on how Azure abstracts hardware functions into software-defined services (like the NAT Gateway and Bastion), Microsoft did the exact same thing for Active Directory.

If an enterprise has legacy cloud VMs that absolutely must be joined to a domain to use Group Policies or LDAP, but they don't want the hassle of managing, patching, and backing up physical Domain Controller VMs, they turn on a service called Microsoft Entra Domain Services (Entra DS).

The Abstraction: Microsoft spins up two invisible, fully managed Domain Controllers deep inside the Azure fabric and hooks them directly into your VNet.
The Result: You get a traditional Active Directory domain footprint (complete with OUs, Group Policies, LDAP, and Kerberos) without ever seeing, building, or managing the actual Windows Server operating systems running them. It is pure "Directory-as-a-Service."

Summary for your Notes

When tech jobs ask for Entra, they are looking for someone who understands how to manage the handoff between these two worlds:

Traditional AD DS: Manages the internal OS environment, local user workstations, network file shares, and local Group Policies using traditional hardware/VM perimeters.
Microsoft Entra ID: Manages the identity at the cloud fabric layer. It acts as the modern Zero Trust gatekeeper, evaluating who you are, what device you are on, and where you are connecting from before letting you pass through the SDN layers to reach resources like your private VNets.

It is completely logical that you associate Kerberos with Linux and Unix systems. Kerberos was born in the open-source academic world long before Microsoft adopted it.

When Microsoft was designing Windows 2000 to replace the aging Windows NT 4.0, they realized their old proprietary authentication protocol (NTLM) was too weak, unscalable, and unsuited for modern enterprise networks. They looked at the open-source world, saw Kerberos, and decided to adopt it as the foundational identity bedrock for Active Directory.

Here is the history of who built it, how Microsoft integrated it, and exactly where it hides inside your Active Directory architecture.

1. Who Wrote Kerberos?

Kerberos was created at MIT (Massachusetts Institute of Technology) in the 1980s as part of Project Athena (a joint project between MIT, DEC, and IBM to create a unified computing environment across the campus).

The primary authors were Steve Miller and Clifford Neuman. They named the protocol after Cerberus, the three-headed dog from Greek mythology that guards the gates of Hades. The "three heads" represent the three components required for the protocol to work:

The Client (The user trying to log in).
The Server (The target resource, like a file share or VM).
The Key Distribution Center (KDC) (The trusted middleman).

MIT released Kerberos as an open standard. Because it was open-source and highly secure, it quickly became the default authentication mechanism for Unix, Linux, and macOS enterprise environments.

2. Is it an Optional Extra or Built-in Default in AD?

It is a strict, non-optional, out-of-the-box built-in default.

The moment you run the commands to promote a Windows Server VM to a Domain Controller (installing the AD DS role), Kerberos is automatically installed, configured, and turned on. You cannot deploy Active Directory without it. It is the primary mechanism Windows machines use to talk to each other inside a domain.

If Kerberos breaks or is stopped on a Domain Controller, Active Directory effectively ceases to function.

3. Where Does Kerberos Reside Inside Windows AD?

In the Linux world, Kerberos runs as a standalone daemon (krb5kdc). In Windows Active Directory, Microsoft completely integrated the Kerberos Key Distribution Center (KDC) into the core OS engine.

It resides explicitly within two places on your Domain Controller:

A. Inside the LSASS Process (The Software Layer)

On every Windows Domain Controller, Kerberos runs inside the Local Security Authority Subsystem Service (lsass.exe). This is the core protected memory space in Windows that handles all security policies and authentication.

Inside LSASS, a specific dynamic link library named kdcsvc.dll (Key Distribution Center Service) wakes up and listens on UDP and TCP Port 88.
Whenever a Windows client boots up on the subnet and requests a login ticket, it sends a packet straight to Port 88 on the Domain Controller to talk to this service.

B. Tied to the NTDS.dit Database (The Data Layer)

Kerberos requires a central database of every user's secret key (their password hash) to issue tickets. Instead of maintaining a separate text file or database like Linux often does, Microsoft hooked the Kerberos KDC directly into the main Active Directory database file: ntds.dit.

Every time you create a user account in Active Directory, AD automatically generates the specific Kerberos cryptographic keys for that user and stores them natively inside that single database.

How it Works in an AD Subnet (For your Notes)

To tie this back to your networking labs, here is the quick execution path when a Windows client on a subnet wants to access another machine:

The Handshake (Port 88): You log into your workstation. The workstation contacts the Domain Controller's KDC service over Port 88.
The Ticket Issuance: The KDC verifies your password hash against the ntds.dit database and hands your machine a TGT (Ticket Granting Ticket).
Accessing Resources: When you try to access a shared folder or run a remote management command on another VM in the subnet, your machine presents that Kerberos ticket to the target VM.

The target VM decrypts the ticket locally, verifies you are who you say you are, and grants access—all without ever needing to ask the Domain Controller to check your password again. This reduces network traffic immensely compared to older legacy protocols.

So, while Linux users still use standard MIT or Heimdal Kerberos config files (/etc/krb5.conf), Microsoft simply took that exact same academic protocol, wrapped it inside the Windows lsass.exe binary, and used Port 88 to handle the heavy lifting inside the Active Directory fabric!

A very important distinction for your AZ-700 notes because it separates infrastructure authorization from operating system authorization:

The underlying Azure fabric (the SDN virtual switch, the edge routers, and the portal) does not use Kerberos at all. In fact, the Azure fabric is completely blind to Kerberos traffic.

Instead, Azure uses modern web identity standards (OAuth 2.0 and OpenID Connect) handled by Microsoft Entra ID to authorize your requests to access the cloud infrastructure.

Here is exactly how the two protocol layers split the work when you connect from the outside world.

The Two Separate Layers: Azure Fabric vs. Guest OS

To make sense of this, you have to look at your environment as two completely separate worlds: the Cloud Infrastructure Layer (managed by Azure) and the Guest Operating System Layer (managed inside your VM).

Plaintext

[ YOU (Outside Azure) ]

? 1. Authenticates via HTTPS / OAuth 2.0

??????????????????????????????????????????????????????????

? AZURE INFRASTRUCTURE FABRIC (Entra ID / Portal) ?

? - Grants access to start Bastion or change a VNet. ?

? - Does NOT know or care about Kerberos. ?

??????????????????????????????????????????????????????????

? 2. Passes encrypted console traffic inside the VNet

??????????????????????????????????????????????????????????

? YOUR VIRTUAL MACHINE / SUBNET (Inside the Guest OS) ?

? - Windows Server VM runs the local KDC (Port 88). ?

? - Authenticates your desktop session via Kerberos. ?

??????????????????????????????????????????????????????????

Layer 1: Accessing the Azure Fabric (Entra ID)

When you sit at your local workstation outside of Azure and open the Azure Portal, or run a deployment command in WSL2, you are interacting with the cloud fabric.

The Protocol: This layer runs entirely over HTTPS.
The Authorization: Azure uses Microsoft Entra ID to verify who you are. It checks your credentials, processes your Multi-Factor Authentication (MFA), and checks your Role-Based Access Control (RBAC) permissions.
The Mechanism: Entra ID issues you an encrypted JSON Web Token (JWT) via OAuth 2.0. This token says to the Azure fabric: "Steve is authorized to open a Bastion session to this VM." Kerberos is never touched here because Kerberos cannot travel natively or securely over standard public web connections without complex VPN tunnels.

Layer 2: Inside the Guest OS (Active Directory & Kerberos)

Once the Azure fabric validates your Entra ID token, it opens the door for you (for example, spinning up an Azure Bastion browser window). Now, you are looking at the actual Windows login screen of your Virtual Machine.

This is where control is handed off entirely to the Guest Operating System:

The Azure fabric steps back and simply acts as the dumb virtual pipe moving the pixels to your screen.
When you type your domain password into that Windows login prompt, now the Windows OS inside the VNet wakes up and uses Kerberos.
The VM's local network interface talks to your Domain Controller VM over internal VNet Port 88, checks the ntds.dit database, and issues a Kerberos ticket to log you into the Windows desktop environment.

Why the Fabric Keeps Them Separate

Microsoft intentionally designed the Azure SDN fabric to be completely decoupled from the OS identity protocols like Kerberos.

Because the fabric doesn't care about Kerberos, you can run Linux VMs, Windows Workgroups, Kubernetes clusters, or an Active Directory Forest inside the exact same VNet space. The Azure fabric simply handles the outer wrapper (authorizing who can access the network infrastructure via Entra ID), while leaving the inner wrapper (authorizing who can log into the servers) completely up to whatever OS protocols you choose to run inside your subnets.