Case study / Identity lab

Samba AD DC Lab.

Guarded Ubuntu automation for building a first domain controller in an isolated test network, with DNS, Kerberos, directory services, signed time and recovery planning kept explicit.

Status: Lab: CI validated; runtime validation pendingRole: Automation & runbooksScope: Personal lab

01 / Problem

Automate the first DC without hiding stateful risk.

A domain controller ties together identity, DNS, time and client trust. The lab targets one dedicated Ubuntu 24.04 host and one disposable Windows client, while treating each root-run stage as privileged infrastructure code.

02 / Architecture

Identity services inside an isolated boundary.

An administrator and Windows client use an isolated Ubuntu Samba domain controller providing DNS, Kerberos, LDAP, SMB and signed time, with upstream DNS and time and an operator-managed encrypted offline backup path.
The script creates a root-only local archive and checksum. Copying and encrypting the offline backup is a separate operator action.

03 / Implementation

Ordered stages, explicit operator gates.

10-prereqs → 20-install → 30-provision
→ 40-dns-forwarder → 45-time-sync
→ 50-verify → 60-create-objects (optional)
→ 70-backup (optional)

Configuration is parsed as allow-listed data instead of sourced as root-executable shell. Provisioning skips matching state and refuses a realm or domain mismatch. Credentials stay in interactive prompts rather than configuration or process arguments.

04 / Decisions & trade-offs

Safety comes before unattended execution.

  • Samba internal DNS keeps the first-DC lab focused; BIND9 DLZ and multi-DC replication remain outside scope.
  • DNS activation restores resolver, service and Samba state when activation fails.
  • No automatic firewall changes avoids locking operators out of an unknown host; the runbook carries the allow-list.
  • Teardown stays documented because destroying the only DC is irreversible and environment-dependent.

05 / Validation

Static confidence is not a working domain.

  • Repository CI validates syntax and guardsBash syntax, parser tests, documentation links, workflow structure, ShellCheck and secret patterns can be checked offline.CI validated
  • Runtime authentication is pendingNo source evidence shows live provisioning, DNS/Kerberos service behavior, a Windows join or Group Policy processing.Runtime pending
  • Recovery is designed, not demonstratedThe runbook requires isolated restore plus database, SYSVOL, DNS, Kerberos, share, signed-time and client tests.Restore and teardown pending

06 / Current status

Lab: CI validated; runtime validation pending.

Automation, verification logic and recovery runbooks are authored. A dedicated disposable host, isolated client, live service checks, restore drill and careful teardown are still required before any runtime or recovery claim.

07 / What I learned

Identity is a chain of dependencies.

DNS discovery, synchronized time and credential handling matter as much as the directory daemon. State-aware reruns and recovery evidence belong in the design from the first provisioning step.

Where would you like to go?