Yossef Mohammed AliCloud & Infrastructure

Hybrid identity foundation · Linux · Bash automation

Samba Active Directory Domain Controller Lab

A guarded, script-assisted first-forest lab that connects operational AD DS experience with inspectable DNS, Kerberos, Group Policy support, signed time, verification, backup, and recovery engineering.

View GitHubReview evidence status
AuthoredGuarded Bash stages, diagram, security model, validation, backup, recovery, and teardown runbooks
Repository CI validatedStatic tests, ShellCheck, documentation, links, workflow analysis, and secret scanning
Runtime evidence pendingProvisioning, client authentication, recovery, rollback, and teardown have not been performed

01 · Scenario

Build the first DC without hiding stateful risk

The lab targets one dedicated Ubuntu 24.04 host and one disposable Windows client on an isolated LAN. It demonstrates the identity and name-resolution dependencies behind domain services while treating every numbered script as privileged infrastructure code.

  • Provision a new test forest with a reserved, non-.local namespace.
  • Keep DNS, Kerberos, LDAP, SMB, and time dependencies explicit.
  • Make reruns safe where possible and refuse mismatched existing state.
  • Separate repository checks from live service, client, restore, and teardown evidence.

02 · Architecture

Identity services inside an isolated trust boundary

The optimized SVG comes from editable Mermaid source in the repository. It shows dependencies and the manual boundary between local and encrypted offline backup.

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

Dedicated domain controller

Samba internal DNS, Kerberos, LDAP, SYSVOL, NETLOGON, and the AD database run on a host reserved for identity services.

DNS and signed time

Domain clients use the DC for service discovery. Non-domain queries use a validated forwarder, while Chrony serves LAN-scoped signed NTP.

Recovery path

An online domain backup is checksummed locally, then must be copied to encrypted offline storage and restored only in an isolated environment.

03 · Security and correctness

Safeguards around secrets, DNS, state, and reruns

Configuration as data

The root-run scripts use an allow-listed, non-evaluating parser rather than sourcing an editable configuration file as executable shell code.

Interactive credentials

Domain provisioning, sample users, and backup prompt for credentials. Password keys are rejected from configuration and secrets are not placed in process arguments.

State-aware provisioning

A matching existing domain is skipped safely; a realm or domain mismatch stops. Original host configuration is copied once before mutation.

Transactional dependencies

DNS activation restores Samba, resolver, and service state on failure. Forwarders reject loopback, link-local, multicast, unspecified, and self-referential targets.

04 · Automation

Ordered stages with explicit operator review

The sequence covers prerequisites, package installation, first-forest provisioning, DNS, time, verification, optional sample objects, and online backup. It is intentionally not an unattended installer.

scripts/
├── 10-prereqs.sh
├── 20-install.sh
├── 30-provision.sh
├── 40-dns-forwarder.sh
├── 45-time-sync.sh
├── 50-verify.sh
├── 60-create-objects.sh
├── 70-backup.sh
└── lib/common.sh

05 · Evidence matrix

CI proves repository quality—not a working domain

CapabilityAuthoredRepository CILive deployedRuntime / recovery evidence
Host and package preflightYesPassedNo evidenceRuntime pending
First-forest provisioningYesStatic checks passedNo evidenceProvisioning and rerun tests pending
DNS, Kerberos, LDAP, SMB, and signed timeYesStatic checks passedNo evidenceService and client authentication pending
Verifier and negative-test planYesPassedNo evidenceLive positive and negative tests pending
Backup and isolated restoreYesStatic checks passedNo evidenceArchive, restore, and recovery pending
Rollback and teardownRunbooks authoredDocs validatedNo evidenceRollback and teardown pending

Read the complete verification plan

06 · Recovery, teardown, and limitations

Recoverability is designed; it is not yet demonstrated

Backup

The backup stage requires an active DC, writes a new archive to a root-only directory, proves it is newer than the run marker, and creates a SHA-256 checksum. Creation is not restore evidence.

Restore

The runbook restores to a newly named DC on an isolated network, then requires database, SYSVOL, DNS, Kerberos, share, signed-time, and Windows client tests before claiming recovery.

Teardown

Destruction is not automated because the only DC is stateful and irreversible. The preferred path verifies retained evidence and backup disposition before removing exact disposable VMs and lab-only network state.

Production gaps

A second DC, replication monitoring, central logs, patching, delegated administration, firewall automation, DHCP secure updates, certificate lifecycle, and measured recovery objectives remain outside scope.

07 · Primary references

Implementation follows current vendor guidance

Technical source of truth

Inspect the complete identity lab

The repository contains the guarded Bash stages, configuration parser, architecture source, security and port model, positive and negative test plan, backup and isolated-recovery procedure, troubleshooting, teardown boundaries, and sanitized evidence checklist.

Open Samba repositoryBack to catalogue