Systems and Directory Guide: Identity, Servers, Backups

Systems administration is the work of keeping the machines, the accounts and the data behind them in a state where the business can ignore them. It covers identity, the servers that host it, the monitoring that tells you something moved, and the backups that decide how bad a bad day gets. Buying the parts is easy. Running them together is the discipline.

Think of a building rather than a rack. There is a front desk that knows who works here and which doors their badge opens; everything else in the building trusts that desk. There is a locksmith who issues the keys and whose signature makes a key legitimate. There are machines in the basement that supply heat and water, boring until they stop. There is a caretaker who reads the meters every morning and notices a rising number before anyone smells smoke. And there is a fire escape that nobody uses for years and everyone needs at once, which is worth exactly as much as the last time someone checked that it opens.

This guide is the map. Each section says what one part of the estate does, where it goes wrong in the field, and where to go deeper. The parts that already have their own articles are linked where they belong: the Active Directory guide for the directory itself, Active Directory DNS for the names underneath it, joining a computer to a domain for the step that exposes both, Active Directory Certificate Services for the keys, monitoring and alerting for deciding what to watch, installing Cacti on Ubuntu and building a syslog server for actually collecting it, and the 3-2-1 rule with restore testing for the fire escape.

The Directory Is the Floor Everything Else Stands On

A directory service answers one question for every other system: who is this, and what are they allowed to do. When it exists, an employee signs in once and reaches the file share, the printer and the application without any of those three keeping its own list of users. When it does not exist, each of them keeps that list, and the lists disagree within a month.

The cost of not having one is invisible until someone leaves. With central identity, disabling the account ends access everywhere at the same moment. Without it, access ends wherever somebody remembered to look, which is never everywhere, and the leftover accounts are the ones that show up in an incident report two years later.

The Active Directory guide covers the structure itself: what domains, organisational units and groups are for, why group policy applies in the order it does, and which of the usual field failures are actually configuration rather than bugs. Read it before designing an OU layout, because an OU layout designed around the company’s org chart rather than around what you need to apply policy to is the single most common structural mistake in a small domain.

The moment where the theory meets a real machine is the domain join. Joining a computer to a domain walks through it with the failures included, because a join touches name resolution, time, network reachability and permissions at once. It is the best diagnostic in the estate: a join that fails tells you which of those four is broken, faster than any of them would on their own.

Names Come Before Identity

Domain members do not find their domain controllers by address. They ask DNS, and they ask for record types most people never look at. That is why a surprising share of Active Directory problems are DNS problems wearing a costume: group policy that never applies, a share that cannot be reached by name, a login that takes ninety seconds and then works.

The single most useful habit here is to check the resolver before anything else. A workstation that lists a public resolver, or a second resolver that does not know about the internal zone, will produce symptoms that point everywhere except at DNS. Active Directory DNS covers the records the directory depends on, what forwarders and conditional forwarders are actually for, and how a split-brain zone quietly serves two different answers to the same name.

Certificates: Identity a Machine Can Verify

A password proves a person. A certificate proves a machine, a service or a website, and it does so to another machine that has never met it. Once an estate has anything beyond the basics — an internal web application, LDAPS, Wi-Fi with 802.1X, a VPN — it needs certificates that its own devices trust.

Running your own certificate authority is not difficult to install and is easy to do badly. The parts that matter are decided before the first certificate is issued: how long the authority’s own key is valid, where it lives, what happens when it expires, and whether revocation is published somewhere the clients can actually reach. Active Directory Certificate Services covers the installation and, more importantly, the decisions around it, including the autoenrollment that makes certificates appear on domain members without anyone visiting them.

The Servers Underneath

Most small estates are mixed, and the split follows the workload rather than a preference. Identity, group policy, file services and Windows-only applications sit on Windows Server. Monitoring, log collection, proxies, and most open-source infrastructure sit on Linux, where they cost less to run and are easier to automate. Both are normal; what is not normal is running either without a named person who patches it.

The practical Linux work in this guide is infrastructure rather than application hosting. Installing Cacti on Ubuntu builds the graphing side, and building a syslog server on Ubuntu builds the log collection side. Together they are the caretaker’s meter room: two boxes, neither of which anyone logs into for months, that make the rest of the estate legible.

A note on virtualization, because it sits underneath all of this: almost every workload in a small estate belongs on a hypervisor rather than on its own physical server, and the exceptions form a short list rather than a percentage. Dedicated hardware earns its place for GPU-heavy work, for specialised media processing, for licence anchors that are tied to hardware, and for latency requirements strict enough to be written in a contract. If none of those four are on the table, the argument is settled in favour of virtualization.

Watching What You Run

Monitoring is not a tool you install; it is a decision about what you need to know and how soon. The decision comes first and takes longer than the installation, which is why monitoring and alerting covers it separately from either of the two builds above.

The shape of the data matters. Numbers arrive by polling and become graphs, and graphs show trends: the uplink that has touched its ceiling every afternoon for three weeks, the disk that will be full in nine days. Events arrive as they happen and show moments: a port went down, a login failed, a configuration changed at 02:14. An estate that collects only one of the two hides half of every incident, and the half it hides is usually the half that explains the other.

The rule that keeps this useful is uncomfortable: an alert that nobody acts on should be deleted or downgraded to a graph. Alerts that fire without consequence train people to ignore the channel, and a channel people ignore is worse than no channel, because it looks like coverage.

Keeping What You Run

Backups are the fire escape, and the only question that matters is whether it opens. A backup job that reports success proves that data was written. It does not prove that the data comes back, that the encryption key still exists, that the agent version can still read the format, or that the person on shift knows the procedure. Only a restore proves those, which is why restore testing is a separate discipline from backing up.

The 3-2-1 rule is the starting shape: three copies, on two kinds of media, one of them off-site. It has aged well because each number answers a different failure — deletion, media failure, and the building. What has been added since is a fourth and a fifth term for ransomware: one copy that cannot be modified once written, and zero errors on a restore test that produced evidence.

Retention belongs in the same conversation, and under GDPR it is not optional. Backups and logs that contain personal data need a retention period that is defined, written down and actually enforced. Keeping everything forever feels safe and is the opposite: it enlarges the blast radius of any breach and it is difficult to justify to anyone who asks why a former employee’s mailbox still exists four years later.

What Actually Breaks in a Small Estate

Four patterns account for most of the outages in estates this size, and none of them are exotic.

Time drift. Kerberos refuses tickets whose clocks disagree beyond a few minutes, and no error message mentions time. Authentication that worked yesterday stops today, and the investigation goes everywhere except the clock. One authoritative time source, and every device pointed at it.

One machine doing three jobs. The host that runs the domain controller, the file share and the backup target is a single point of failure that was never decided, only accumulated. Write down which service depends on which machine, and the list will point at its own worst entry.

Nobody named. Patching, backup verification and certificate expiry all fail the same way: not through disagreement but through the absence of an owner. Every recurring task in this guide should have a name attached to it, not a team.

A restore never tested. This is the failure that turns an incident into a crisis, and it is the cheapest one to prevent. A restore test costs an afternoon. Discovering that backups do not restore costs the business.

Conclusion: The Estate Is a Habit, Not a Purchase

Every section of this guide describes maintenance rather than construction. The directory is not finished when it is installed; it is correct for as long as accounts are removed when people leave. Monitoring is not finished when the graphs appear; it is useful for as long as someone reads them. Backups are not finished when the job turns green; they are real for as long as a restore has been tested recently enough to believe.

The check-up list is short, and every line is a thing you can verify this week rather than an aspiration:

• Identity: disabling one account ends access everywhere, and you can demonstrate it.
• DNS: every domain member resolves through internal servers, with forwarders pointed somewhere deliberate.
• Certificates: you know what the authority’s expiry date is, and it is not in the past.
• Servers: each one has a named person who patches it and a written note of what depends on it.
• Monitoring: every alert has an owner, and the alerts that fire are ones somebody acts on.
• Backups: three copies, two media, one off-site, one immutable, and a dated restore test with evidence.