Obsolete systems in Active Directory: inventory, isolate and keep an exceptions register

Why an obsolete system is a risk to the whole domain

A machine past end of support no longer receives security fixes: vulnerabilities discovered after the end-of-support date stay open indefinitely. But the problem goes beyond the machine itself. As a domain member, it handles identities: it caches credentials, it takes part in authentication protocols, it trusts the same domain controllers as critical servers. An attacker who gains a foothold on an old server is already inside, in a position to try to harvest secrets or pivot.

Old systems also stand in the way of general hardening: they are often the stated reason for keeping weakened protocols alive, such as old TLS versions, RC4 encryption for Kerberos or NTLM. A single obsolete system can thus delay the modernisation of the entire domain.

Inventory from the directory

Active Directory itself provides a first inventory. Every computer object carries the operatingSystem and operatingSystemVersion attributes, populated by the machine when it authenticates. A filter on these attributes gives a list of server and client systems by version. Two precautions:

• these attributes are only reliable if the object is still in use: cross-reference them with the lastLogonTimestamp attribute to rule out dormant objects, which call for clean-up rather than isolation;
• some devices (appliances, non-Windows systems joined to the domain) populate these fields loosely: the directory inventory must be reconciled with the device management inventory.

At the end of the exercise, you have a named list of the machines involved, their likely role and their last activity. That is the starting point for every decision.

Deciding: migrate, retire or isolate

For each system identified, three outcomes are possible.

1. Migrate to a supported version: this is always the goal, even when it looks distant. An application reputed to be incompatible is often less so than feared once the project is under way.
2. Retire: many of these machines are no longer genuinely used and can be decommissioned. That is the best result.
3. Isolate when keeping the system is unavoidable in the short term: this is a risk-reduction measure, not a solution.

Isolating properly

Isolating is not just "putting it in a separate VLAN". Serious isolation combines several measures: strict network filtering allowing only the essential application flows, a ban on opening privileged sessions on these machines so that sensitive credentials are never exposed there, removal of high-level administrative accounts from their local administrators, and heightened monitoring. Where possible, placing these systems in dedicated organisational units makes it easier to apply specific policies and to review them periodically. The guiding idea: if the machine falls, the attacker must stay confined to it.

Keeping an exceptions register

Every obsolete system that is kept should be the subject of a formal exception, recorded in a register. For each entry: the machine, the business justification, the accepted risk, the compensating controls in place, a named owner and a review date. This register turns a creeping accumulation into explicit, dated decisions. It makes the debt visible, puts it in front of the people who own it, and prevents a "temporary" exception granted five years ago from being forgotten. It is also something most compliance frameworks expect.

What an audit checks

• The inventory of end-of-support systems, drawn from the directory and reconciled with device management.
• Any domain controllers running an unsupported operating system.
• Weakened protocols kept alive because of these systems.
• The isolation measures actually in place, beyond mere network separation.
• The absence of privileged credentials exposed on these machines.
• An up-to-date exceptions register, with an owner and a review date.