Components, Responsibilities, and Boundaries
Purpose of This Page
This page describes the architectural structure of a Samba Active Directory Domain Controller (AD DC): what services it runs, how those services relate to one another, and which responsibilities are centralized versus delegated to clients.
The goal is to make the system legible as infrastructure. Rather than focusing on installation steps or command syntax, this overview explains what lives where, why certain roles are consolidated, and where operational boundaries should be respected to avoid destabilizing the domain.
Architectural Overview
A Samba AD DC is not a single daemon, but a coordinated service bundle that collectively implements Active Directory semantics. In a small deployment, many of these services run on the same host, but they remain conceptually distinct.
At a high level, the Samba AD DC provides:
- Centralized identity and authentication
- Directory-backed metadata and policy storage
- DNS-based service discovery
- Replication and domain state management
- Compatibility with Windows client expectations
The architecture is intentionally conservative. Samba prioritizes correctness and compatibility over modular experimentation, because Windows clients expect specific behaviors rather than flexible interpretations.
Core Services Provided by the Samba AD DC
Samba (AD DC Mode)
The Samba service itself is responsible for implementing Active Directory logic, including:
- Domain controller behavior
- LDAP directory exposure
- Integration with Kerberos
- Enforcement of AD schema and object rules
- Replication metadata handling
When Samba runs in AD DC mode, it is not merely a file server. It becomes the authoritative identity system for the domain, and many traditional Samba configuration assumptions no longer apply.
LDAP Directory Service
LDAP is embedded within the Samba AD DC as the directory and metadata store. It holds:
- User and group objects
- Computer accounts
- Domain configuration data
- Replication and trust metadata
Although LDAP is queryable using standard tools, it should be treated as an internal subsystem. Direct modification bypasses domain-aware logic and can introduce inconsistencies that surface later as authentication or policy failures.
Operational boundary:
Read freely, write cautiously, and prefer domain-aware tools whenever possible.
Kerberos Key Distribution Center (KDC)
The Samba AD DC includes a Kerberos KDC that handles:
- User authentication
- Machine authentication
- Ticket issuance for services
- Trust enforcement within the domain
Kerberos is sensitive to:
- Accurate DNS resolution
- Consistent system time
- Proper service principal registration
Because Kerberos failures tend to block access completely, the KDC should be treated as a critical-path service. Supporting services (DNS, time sync) must be reliable for Kerberos to function correctly.
DNS Service
In most Samba AD DC deployments, the domain controller also acts as the authoritative DNS server for the domain.
Responsibilities include:
- Hosting the AD domain zone
- Publishing SRV records for LDAP and Kerberos
- Resolving domain member hostnames
- Enabling automatic service discovery by clients
Active Directory assumes DNS is tightly integrated with identity. Mixing external resolvers or bypassing the domain DNS layer often leads to intermittent or difficult-to-diagnose failures.
Architectural rule of thumb:
If clients cannot find the DC, identity does not exist.
Single-Server Architecture in a Small Deployment
In a compact environment—such as a racing simulation arcade—it is common and appropriate to run all AD DC services on a single Linux host.
This architecture provides:
- Reduced operational complexity
- Centralized failure domains
- Easier monitoring and backup
- Lower hardware and licensing costs
The tradeoff is that this host becomes infrastructure-critical. Stability, careful change management, and documentation matter more than horizontal scalability at this stage.
Client Roles and Responsibilities
Windows 11 Domain Members
Windows clients are not passive consumers. They actively participate in the domain by:
- Authenticating via Kerberos
- Querying LDAP for identity metadata
- Registering DNS records
- Enforcing local policy based on domain state
Windows clients assume that Active Directory behaves exactly as specified. Samba’s architectural choices are shaped largely by these expectations.
Linux Clients (When Present)
Linux clients integrated with Samba AD typically rely on:
- SSSD or equivalent services
- Kerberos for authentication
- LDAP for identity resolution
These clients must be configured to respect the same identity boundaries as Windows systems, even though the tooling differs.
Replication and Domain State
Even in single-DC deployments, Samba maintains replication metadata and domain state structures as if additional controllers could exist.
This design supports:
- Future expansion
- Backup and restore operations
- Internal consistency checks
Administrators should be aware that domain state is not just “files on disk,” but structured data with expectations about versioning and coherence.
Operational Boundaries and Design Intent
Understanding the architecture clarifies what not to do:
- Do not treat LDAP as a general-purpose database.
- Do not bypass DNS for “quick fixes.”
- Do not ignore time synchronization.
- Do not modify schema casually.
- Do not assume Samba AD behaves like classic Samba.
Samba AD DC is intentionally opinionated because it must faithfully reproduce Active Directory behavior. Respecting those boundaries is the difference between a stable domain and a fragile one.
Summary
The Samba AD DC architecture consolidates multiple identity-critical services into a coherent system designed to satisfy Active Directory expectations. LDAP provides structure, Kerberos provides trust, DNS provides discoverability, and Samba orchestrates their interaction.
In small, production-critical environments, this architecture offers a powerful balance: enterprise-grade identity semantics delivered through a Linux-based control plane that favors transparency, stability, and long-term maintainability.
Understanding this structure is essential before making changes, diagnosing failures, or extending the system further.
Status
This page describes the current architectural understanding. It will be revised as operational experience accumulates and as additional services or clients are integrated into the domain.