Samba 4 as a Domain Controller: Deploying AD on Linux

Samba AD DC: what breaks in a domain without its own controller

Employee accounts without a domain sprawl: local users on the file server, separate databases in services, service task logins with passwords directly in configuration files.

While the team is small, this rests on the administrator's memory — at the tenth server and thirtieth employee, a class of failures appears that is treated not by configuration but by redesigning the schema.

Rights are granted by hand and kept in a table that lives separately from groups on disk. The same person is in different sets of groups on different nodes, and no one can say exactly who has access to the contracts directory.

There is no unified password policy: complexity and lifetime are set wherever someone remembered them.

The most expensive part is the single authentication node. While it is alive, logging into services is unnoticeable; when it is unavailable, work stops entirely, including systems unrelated to accounts.

There is no replica, so recovery is from a backup with manual reconciliation of records after restoration.

Deploying a domain controller on Linux, where Samba AD DC takes on this role, provides a single source of accounts, unified authentication for services, and a replica to which the domain switches without manual intervention. Below we break down how this is structured and what breaks if you leave it as is.

What a domain on Linux provides: single sign-on, rights, and fault tolerance

When accounts, groups, and rights are collected in one directory rather than spread across a dozen panels, the effect is visible in measurable terms: how much time is spent on routine and how quickly the infrastructure returns to service after a failure. A domain on Samba provides this without changing the working systems employees are used to.

• Single sign-on for employees. One set of credentials for all connected services: password reset and lockout are one operation instead of going through a dozen interfaces, which frees up hours per week for the administrator for development rather than repetitive requests.
• Centralization of access rights. Rights are granted by groups and policies: adding a new employee and revoking access upon dismissal are reflected in all systems at once, so closed access does not "come back to life" on the next login.
• Domain fault tolerance. A second controller and directory replication remove the single point of failure: a node failure does not interrupt employee login, and recovery takes minutes instead of hours of manual assembly.
• Machines and services under common management. Workstations join the domain and receive common policies, internal services receive unified credentials, and access to shared resources is by role rather than personal arrangement.
• Transparent audit. Login and change logs show who accessed resources and when: an incident is investigated by facts, not by participants' recollections.

Recovery time stops being a separate project: the directory is restored from a backup on a prepared node, and employees continue working through the second controller. We test this in drills before putting it into production.

Deployment options: dedicated server, Samba, or cloud domain

Choosing between a dedicated domain controller, Samba AD DC, and a cloud domain is decided by conditions, not preferences: whether there is a site for the server, how mixed the machine fleet is, whether group policies are needed, and who is on duty at night. Below are the applicability boundaries of each option.

Replication between sites usually comes up when launching a second office.

In a Samba domain controller, it is built in and works over standard mechanisms, but when the channel breaks, it is important to decide in advance which records are considered priority after merging, otherwise accounts diverge.

In a cloud domain, replication is handled by the provider, but login at the site depends on the channel.

Implementation stages: from network audit to handover for support

A domain is not deployed on top of a running network: first we record the current state, then design the schema, and only then configure the directory service.

The order of stages is fundamental — a skipped audit surfaces during commissioning, when changing the topology is more expensive and riskier.

1. Infrastructure audit. We collect the network diagram, list of servers and services, existing DNS zones, accounts, and service authentication requirements. The output is a list of constraints and nodes that must not be touched.
2. Domain schema. We determine the domain name, number of controllers, replication topology between sites, time synchronization order, and name resolution rules. We agree on the schema with you before configuration begins.
3. Directory service configuration. We deploy the domain controller on Linux, bring up DNS and authentication, distribute operations master roles, and set password policies and the organizational unit structure.
4. Data migration and client onboarding. We migrate users, groups, and computers, join machines to the domain, and configure permission mapping on file resources so that access does not expand.
5. Testing login scenarios. We test login from workstations and services, password changes and expiration, lockouts, trust between domains, and behavior when one controller fails.
6. Backup and recovery. We test full directory and single-object recovery on a test bench — a procedure without verification is considered non-working.
7. Handover for support. We hand over access, documentation, and procedures, train administrators, and record the domain development plan.

Each stage is closed with an artifact: a diagram, configuration, or verification report. This allows the system to be handed over to your team without verbal agreements.

What we hand over: configurations, diagrams, and procedures

The domain continues to work without us only when knowledge is recorded in artifacts rather than in correspondence with an engineer.

Therefore acceptance is not "the server responds" but a package by which the in-house team can make changes, recover from a failure, and pass verification. Below is what exactly remains with the customer.

• Infrastructure diagrams — controllers and their replicas, forward and reverse name resolution zones, trusted segments, exit points to other networks. They show what will fail together with a node.
• Access policies — binding of group policies to organizational units and nodes, a matrix of rights on file resources, and the procedure for granting and revoking privileges.
• Roles and rights — list of built-in and custom roles, who is delegated management of organizational units, who owns each group, and where to go to extend them.
• Backup procedure — what goes into the backup (directory state, configurations, keys), at what frequency, where it is stored, how recovery is verified, and in what time the domain comes up on a clean node.
• Domain documentation — topology, object composition, service accounts, their rotation procedure, change log, and points where manual edits have already been made.
• Instructions for standard operations — adding and removing a controller, transferring roles, changing a service account password, connecting a new organizational unit.
• Update and monitoring procedure — which checks are performed regularly, which events trigger alerts, and what is considered a reason for intervention.

Case: a domain for 300 employees without a dedicated server for the directory

The directory for 300 people lived on a single physical server with a Windows domain controller: one point of failure, a backup once a day, recovery — reinstallation and manual account reconciliation.

Adding a new employee took two to three days: request, queue, manual creation of the account and rights. Access requests came in a stream — forgotten passwords, group discrepancies, "can't get into the shared folder."

We deployed Samba AD DC on two existing virtualization nodes — no separate server for the directory was allocated at all. We configured replication between controllers, integrated DNS, and operations master roles so that the failure of any node would not break the domain.

Accounts are created from the HR system according to procedure, and rights and network resources are granted by groups through policies.

Migration without downtime

We established trust relationships between the old and new domains, migrated workstations in waves by department, and transferred profiles and data in advance. The previous controller was kept in read-only mode until there were no active logins on it — the workday never stopped.

Employee onboarding was reduced to 15–20 minutes instead of two or three days. Directory recovery — switching to the second node in minutes, not half a day of downtime for the entire office.

The share of access incidents fell by roughly a factor of four, and backups are now taken more often and verified by recovery on a test environment: rollback is not described in an instruction but practiced.

What to do if the domain is already deployed on another solution?

A deployed domain is not switched over in one evening — first it coexists with the new one.

A separate forest on Samba AD DC is brought up alongside, and forest-level trust relationships are configured between the old and new domains: two-way if resources must be accessible in both directions.

While the trust is in effect, employees work under their previous accounts, and new ones are created in parallel.

Trust relies on mutual name resolution: the old domain's zones are configured on the new controller as conditional forwarding, otherwise resources of the neighboring forest simply are not found.

The forest level is also needed because only it allows transferring the history of security identifiers — without it, rights on file resources would have to be set again manually.

Account migration proceeds in portions: first a small group, then a department, then the rest.

Together with the record, the password, group membership, and identifier from the history are transferred — the employee logs into the new domain and sees the same network folders with the same rights.

The profile and pinned settings are transferred separately so that after the transition people do not rebuild their working environment from scratch.

A seamless transition rests on the order of steps: trust, accounts, then servers and workstations.

Computers are joined to the new domain one at a time, at an agreed time, and the old domain remains operational until the last resource is migrated — this is also the rollback point: if something is discovered midway, the accounts are still in the previous domain and work does not stop.

Technical doubts before migrating a domain to Linux

Before migrating a domain to Linux, engineers usually have the same questions: will the previous workstations work, how to take backups, what happens if a node fails, will file rights be preserved, and can the team administer such a domain. We address each one.

How to back up the domain?

The directory cannot be copied hot with an ordinary archiver — the snapshot will be inconsistent. We take the database state using the standard method, store copies on separate media, and deploy the snapshot on an isolated test bench to make sure recovery actually works.

What happens if a node fails?

We deploy the domain on at least two nodes with replication: the failure of one does not interrupt user login and access to shared resources. Roles that cannot be duplicated are transferred with one command, and the node recovery procedure is described and tested on a test bench.

Will file access rights be preserved?

Rights on folders and network resources are migrated together with the data — including inheritance and granular permissions for groups. Before putting it into operation, we compare the access matrix for key directories: who reads, who writes, who has advanced rights.

Will our team be able to administer such a domain?

Management is done with familiar snap-ins and command-line utilities. Scenarios for mass account creation and policy configuration are transferred almost unchanged; we hand over documentation and knowledge transfer to your administrators.

Let's discuss the task: what will be required from you and where we start

A domain controller on Samba AD DC is not a separate server but part of the network: it handles name resolution, time synchronization, rights on file resources, and employee login.

Therefore the scope of work is estimated not on an "average cost per controller" but on your specifics. Below are the initial data we ask for in the first conversation; if something is missing, we will help collect it.

• how many users, workstations, and servers will join the domain and what growth is expected;
• how accounts are arranged now: workgroup, previous Windows controller, or separate directory;
• which services depend on authentication — file resources, mail, remote access, internal applications;
• requirements for password rules, workstation restrictions, and automatic mapping of network drives;
• domain name, name resolution zones, and who manages addressing;
• how backup is arranged and what maintenance windows are acceptable;
• access for our engineers and your security requirements.

The first step is ours: we analyze the data and assemble an implementation plan — how many controllers are needed, how to distribute roles, how to configure replication and recovery, and in what order to migrate services.

In the plan we record stages, work windows, and acceptance criteria so that it is clear what is checked at each step.

We describe domain support after launch as a separate block: response to login failure, controller recovery, and the procedure for changing rules. Describe the task — we will come back with a scope estimate and a first-stage plan.