Samba AD DC Infrastructure Notebook

Purpose and Scope

This notebook is a working record of reasoning, decisions, and observations related to implementing and operating a Samba Active Directory Domain Controller (AD DC) in a small but production-critical environment. It is written first as a learning and thinking aid, second as a shared reference between collaborators, and only later—if appropriate—as the seed of formal internal documentation.

The immediate operational context is a racing simulation arcade environment, where multiple Windows 11 systems, a Linux-based control server, and supporting network services must behave predictably, securely, and with minimal overhead. The goal is not theoretical completeness, but durable understanding: why the system is shaped the way it is, what assumptions it relies on, and how to reason about failures when they occur.

This notebook deliberately avoids business-sensitive details. It focuses on infrastructure concepts, architectural constraints, and implementation logic that are broadly applicable to Samba AD deployments while remaining grounded in real operational experience.


Guiding Principles

  • Infrastructure over cleverness: Stability, legibility, and reversibility matter more than novelty.
  • Reasoning is as important as configuration: Commands without context rot quickly.
  • Compatibility is a constraint, not a flaw: Samba AD exists to satisfy Windows expectations.
  • Learning is iterative: Early entries may be partial or revised later.

Historical Orientation: Why Samba AD Looks the Way It Does

Lightweight Directory Access Protocol (LDAP) predates Active Directory by nearly a decade. Originally formalized in the mid-1990s, LDAP was designed as a flexible directory and query protocol, not a complete identity system. Early Unix deployments treated it as a shared directory substrate, often paired loosely with local authentication mechanisms.

Microsoft Active Directory, introduced with Windows 2000 (1999–2000), fundamentally changed this relationship. LDAP was retained, but subordinated to a larger, tightly integrated identity architecture built around Kerberos authentication, DNS-based service discovery, strict schema control, and policy-driven machine governance. LDAP became a supporting organ rather than the brain of the system.

Samba Active Directory Domain Controller (Samba 4, production-ready from 2012 onward) is best understood as an independent re-implementation of Microsoft Active Directory semantics. It does not reinterpret LDAP; it enforces Active Directory’s rules closely enough that Windows clients cannot distinguish it from a Windows-based DC. This historical lineage explains why direct LDAP manipulation in Samba AD is possible but hazardous, and why domain-aware tools and workflows are preferred.


System Context: Arcade Environment Overview

The target environment consists of:

  • A Linux-based server acting as:
    • Samba Active Directory Domain Controller
    • Central identity authority
    • DNS and Kerberos provider
    • Racing simulation control and orchestration node
  • Multiple Windows 11 client machines:
    • Joined to the Samba AD domain
    • Used as dedicated racing simulation rigs
    • Expected to authenticate reliably and behave consistently
  • Supporting network services:
    • Local switching and routing
    • Time synchronization
    • File and service access governed by domain identity

The architectural goal is to make identity boring: machines should join the domain cleanly, users should authenticate without friction, and failures should be diagnosable through clear layers (DNS, Kerberos, LDAP, client configuration).


What This Notebook Is (and Is Not)

This notebook is:

  • A reasoning log
  • A learning companion
  • A shared reference for collaborators
  • A seed for future internal documentation

This notebook is not:

  • A step-by-step beginner tutorial
  • A replacement for official Samba documentation
  • A public-facing marketing artifact

Planned Sections (Living Outline)

  • Identity Stack Overview: LDAP, Kerberos, DNS, and Their Roles
  • Samba AD DC Architecture and Services
  • Domain Provisioning Decisions
  • DNS Configuration and Failure Modes
  • Time Synchronization and Kerberos Sensitivity
  • Windows 11 Domain Join Behavior
  • Linux Client Integration (SSSD / realmd)
  • Common Failure Patterns and Diagnostic Reasoning
  • Operational Boundaries: What Not to Touch
  • Change Log and Revisions

Status

This document is a living notebook. Sections will be expanded, revised, or reorganized as understanding deepens and operational experience accumulates.