Keeping a Spare Active Directory Running in the Cloud What This Divisional Actually Claims

This application covers a backup method for the system that decides who is allowed to log in to a company’s computers. Claim 1 takes a backup of a live directory service, stores it in cloud storage, stands up a complete standby directory service as virtual machines in a cloud provider’s network, and then automatically fails over to that standby when something goes wrong with the original. It was filed by Cayosoft, Inc. of Columbus, Ohio, and names Alexander Vadimovich Tsvetkov, Robert John Bobel III and Andrei Polevoi as inventors. The application is a divisional of Australian application 2023228872, and the specification states that it claims the benefit of United States provisional application 63/315,748, filed 2 March 2022.

The Problem

A directory service is the part of a corporate network that holds user accounts and decides what each account is permitted to reach. In practice, for most organisations, that means Microsoft Active Directory on premises, its cloud counterpart Entra ID, or a hybrid of the two. The specification describes it as the most widely adopted method used by business organisations to authenticate user credentials and authorise access to critical business resources, and it points out the obvious consequence: when the directory stops, everything stops, because nobody can prove who they are.

That makes the directory an attractive target. The specification states plainly that because of the financial impact of a directory outage, directory services have become a favourite target for ransomware attackers, for extortion or simply to destroy the directory itself. Less often, the same outcome arrives through data corruption or an administrator’s mistake. The cost of the outage, it says, is determined by its duration plus the cost of restoring authentication and authorisation service, so minimising restoration time minimises the cost.

The criticism of existing practice is specific and it is about process rather than product. Conventional backup and recovery software, the specification acknowledges, works well. The problem is that recovering a directory from it requires a complex orchestration of recovery steps, including the manual creation of servers, virtual servers and network settings by an administrator, for each directory server that has to be recovered. And there is a second problem underneath: with a traditional backup you do not know whether a recovery will succeed until you attempt it, in the middle of the emergency.

The document distinguishes two failure modes. A logical disaster is when all the domain controllers are still running but the schema or the directory objects are broken. A physical disaster is when the domain controllers are down, physically destroyed or encrypted. In both cases the specification notes that the whole forest may be non operational, not just specific domain controllers, which is why recovering one server at a time does not help.

What This Invention Does

Claim 1 is a computer implemented method performed at a backup device with one or more processors, and it has six steps.

It receives a backup request for a host directory service from a client device, where the client, the host directory service and the backup device are all connected over a first network protocol on a first network. It determines backup and recovery instructions for that host directory service, and the claim requires those instructions to comprise at least one cloud storage location and at least one cloud based recovery site. It generates a backup of the host directory service based on those instructions. It stores that backup in the cloud storage location, at a cloud service provider network. It configures a standby directory service inside a cloud based virtual machine environment, comprising at least one virtual machine plus corresponding network infrastructure elements provisioned in the cloud provider’s network. And then, in response to detecting an interruption event at the host directory service, it automatically initiates failover to that standby.

It is worth being precise about what has been narrowed here, because it is the interesting part. The summary section of the same specification describes an invention whose distinguishing steps include presenting a backup user interface with selectable options at the client device, and determining the backup and recovery instructions from what the user selected. Ten of the twelve figures are screenshots of that interface. None of that is in claim 1. The user interface has been moved out of the independent claim entirely and survives only as a dependent limitation, in claim 15, where the standby is automatically updated on a schedule selected from backup and recovery options at a client device.

What has been moved in instead is the cloud. Claim 1 requires a cloud storage location, a cloud based recovery site, a cloud service provider network and a cloud based virtual machine environment. The divisional is therefore not claiming the console. It is claiming a cloud hosted standby directory with automatic failover.

The dependent claims fill in the rest. Claim 5 requires the cloud provider network to reach the virtual machine environment over a second network protocol on a second network that is different from and isolated from the first, and claim 6 calls that an isolated recovery environment separated from the first network. Claim 7 requires the standby to be iteratively generated and updated over that isolated second network, and claim 8 adds that each iteration replaces the previous one. The point of the isolation is containment: the standby is built on a network that whatever compromised the production network cannot reach.

Claim 12 is where the interruption event gets defined, and it is more specific than a simple ping check. Determining that an interruption event has occurred is based on at least one of determining that irreversible schema changes occurred at the host directory service, determining that the number of irreversible object changes exceeded a threshold, or determining that a natural disaster occurred at the location of the host directory service. The second of those is a mass change detector, which is exactly the signature of ransomware working its way through a directory. Claim 11 puts it more generally, as detecting changes of objects associated with the host directory service.

Claim 9 covers what happens after the switch. Once failover is initiated, a standby event process is iteratively performed for the restored network environment, and claim 10 lists what that process may include: installing additional backup and recovery software, performing a potential threat analysis on the first network, performing a data and service consistency check, and notifying a client device. In other words, the moment you have failed over, the system starts checking whether the environment it just moved into is sound and whether the environment it left is still hostile.

Claims 2 and 3 are worth reading together with the body, because they disagree in an instructive way. Claim 2 says the backup comprises directory service data, operating system files and system configuration data, and claim 3 says the operating system files and configuration data are sufficient to restore the host directory service onto a virtual machine that has no pre installed operating system. The body text, however, argues at two separate points that the standby backups, unlike bare metal backups, may contain only directory data and metadata and not executables or other files that could be infected, so that a recovered domain controller would not contain malware even if the source was infected. Both approaches are described. The claims as filed take the broader position.

Claim 13 defines the host directory service as a set of domain controllers plus metadata corresponding to network infrastructure and additional services, and the body lists what that metadata covers: FSMO role configuration, site topology, partition information, domain controller configurations, network adaptor settings, operating system settings, security settings, directory database details, SYSVOL, DNS zones, delegations and the applications that consume directory data. Claim 17 lists the network infrastructure elements as including switches, storage and firewalls. Claim 18 is the corresponding device claim.

Key Features

• A standby that exists before the outage. The method configures a complete working standby directory service as part of the backup routine, not as part of the recovery. When the failure arrives, the replacement is already provisioned and running rather than waiting to be built from a file.
• Cloud storage and a cloud recovery site written into claim 1. The independent claim requires the backup and recovery instructions to name at least one cloud storage location and at least one cloud based recovery site, and requires the standby to be at least one virtual machine with its network infrastructure in the provider’s network. The divisional is claiming the cloud hosted version specifically.
• An isolated second network. Claims 5 to 7 put the standby environment behind a second network protocol on a second network that is different from and isolated from the production one, so that the process of building and refreshing the standby does not give an attacker on the production network a path to it.
• Iterative refresh with replacement. Claim 7 has the standby repeatedly regenerated and updated, and claim 8 has each iteration replace the previous one, so the spare is kept current rather than ageing from the moment it was made.
• An interruption test based on change patterns. Claim 12 defines the trigger as irreversible schema changes, a count of irreversible object changes crossing a threshold, or a natural disaster at the host location. That middle test detects mass destructive modification rather than waiting for a server to stop responding.
• Post failover verification as a claimed step. Claim 9 requires a standby event process to run iteratively after failover, and claim 10 makes that threat analysis on the original network, consistency checking, additional software installation and notification.
• Automatic redirection of authentication traffic. Claim 4 makes the failover comprise modifying network settings to redirect authentication and authorisation requests to the standby, and claim 16 has the instructions automatically modify the host’s network settings to use the standby in its place.

Who Is Behind It

Cayosoft, Inc. is a software company based in Columbus, Ohio, specialising in management, monitoring and recovery for Microsoft directory platforms. The commercial product corresponding to this disclosure is Cayosoft Guardian Forest Recovery, which the company markets as Active Directory forest recovery delivered by keeping a validated standby forest ready to activate. Robert Bobel, the second named inventor, is the company’s founder and chief executive.

The company announced in September 2024 that it had secured a United States patent on this approach. That release contains the numbers that make the category legible. It states that Active Directory is used by 90 per cent of large organisations worldwide, that traditional native forest recovery requires an average of 21 days and over 35 complicated steps, and that an Active Directory outage costs organisations an average of 1.5 million United States dollars per day in labour costs alone. Those are the vendor’s own figures and should be read as marketing, but they describe the shape of the problem accurately enough.

On lineage, the specification is explicit. It records that the application is a divisional of Australian application 2023228872 filed 2 March 2023, and that it claims the benefit of United States provisional application 63/315,748 filed 2 March 2022, titled “Systems and methods for instant directory service recovery after a ransomware or other catastrophic outage”. That original title says more about the intent than the current one does. The priority country is the United States.

One drafting defect should be flagged. The abstract printed on the title page of this specification opens by describing a process that obtains user activity data “via a sensor in a physical environment”. There are no sensors, no users in physical environments and no activity data anywhere else in this document. It is boilerplate from an unrelated specification that was left in the abstract. The rest of the abstract, about determining that an interruption event has occurred at a host directory service, matches the actual subject matter.

Why It Matters

Forest recovery is the disaster scenario that Active Directory administrators genuinely fear, and it is fundamentally different from restoring a file server. Microsoft’s own guidance for recovering a forest is a long manual procedure involving isolating a domain controller, restoring system state, seizing FSMO roles, cleaning metadata, resetting krbtgt passwords twice, rebuilding DNS, and only then promoting replacements, with a specific ordering that has to be followed correctly under pressure. Organisations that have been through it describe it in days, not hours. The specification’s complaint that you do not know whether the recovery will work until you try it is the honest heart of the matter.

That is why the standby forest idea has become a real commercial category rather than a feature. Several vendors now sell the ability to maintain a clean, tested copy of the directory somewhere the attacker cannot reach, and to cut over to it. The competitive claims are all about how quickly the cut over happens and how confident you can be that the copy is clean.

What this divisional actually stakes out is narrower and more particular than the product marketing. It is not a claim to the idea of a standby directory in the abstract. It is a claim to a specific pipeline: backup to cloud object storage, standby provisioned as virtual machines and network infrastructure in a cloud provider account, isolation of that provisioning traffic on a separate network, and automatic failover on detection of an event defined by patterns of irreversible change. Anyone assessing this application should read those cloud limitations carefully, because they are the substance of what distinguishes the divisional from the parent.

The wider point is about where the reinfection risk sits, and the specification is unusually thoughtful about it. Restoring a compromised directory from a backup that itself contains compromised operating system files simply reinstates the problem, which is why the body keeps returning to the idea of a backup that carries directory data and metadata but not executables. That tension, between a backup complete enough to stand up a bare virtual machine and a backup clean enough to be trusted after a ransomware event, is the real engineering argument in the document, and it is not fully resolved.

Related Concepts

• Active Directory – the Microsoft directory service this method backs up and replaces during an outage.
• Domain controller – the servers that make up a directory forest and that the standby must recreate together rather than one at a time.
• Ransomware – the attack class the background names as the reason directory services became a favourite target.
• Disaster recovery – the wider discipline this method sits in, and the source of the recovery time objectives it aims at.
• Cloud computing – the provider hosted environment claim 1 requires for both the stored backup and the standby virtual machines.
• Business continuity planning – the organisational context in which the cost of directory downtime is measured and budgeted.

---

AU 2026202188 was published in the Australian Official Journal of Patents on 9 April 2026 and is open for public inspection. Patent applications represent inventions that are sought to be protected and do not necessarily reflect commercially available products.