Accounts and Permissions

Cygna Forest Recovery needs no domain service account, and it stores no domain credentials. When a task needs domain rights, such as installing an agent remotely or seizing operations master roles during a recovery, you supply the credential for that task only. This topic describes every account involved, so you can prepare them before you install.

Service accounts

Service	Runs as	Notes
`CygnaDRManager`	LocalSystem	On the Manager machine.
`CygnaDRStorageAgent`	LocalSystem	Needs local administrator rights on the storage machine, because it creates and deletes local accounts and sets permissions on the vault. Don't change it to another account.
`CygnaDRDcAgent`	LocalSystem	On each domain controller and candidate machine.
`CygnaDRHostAgent`	LocalSystem	On the Isolated Recovery Host, if you have one. LocalSystem gives it the rights to manage Hyper-V on the host. No credential is stored for the host: the agent's authority to the Manager is its enrollment certificate, like every other agent, and the Manager never connects to the host.

The installers configure these accounts. You don't need to create anything.

Storage machine local groups

The storage agent creates these local groups on the storage machine. Access to staging and the vault is granted through the groups, so you never need to edit the permissions on those folders.

Group	Purpose
CygnaDR Administrators	Has write access to the vault, the staging folder, and the folder that holds the Manager's configuration backups. Add the local accounts of anyone who must be able to manage the backup files directly on the storage machine. This group must have at least one member before you can turn on the Remove BUILTIN\Administrators from the vault setting.
CygnaDR Staging Writers	Holds the local accounts that the storage agent creates for backup jobs, and nothing else. The staging share grants this group access. Membership alone grants no access to any backup.
CygnaDR Vault Readers	Holds the local accounts that the storage agent creates for restores, and nothing else. Membership alone grants no access to any backup.

Accounts created for each job

For each backup job, the storage agent creates a local account named cdr- followed by 12 hexadecimal characters, with write access to that job's staging folder only. For each restore, it creates a read-only account named cdr-r- followed by 12 hexadecimal characters. Each account is deleted when its job or restore ends. You may see these accounts in the storage machine's local users while a job is running; don't change or delete them.

Audit policy on the storage machine

The storage agent watches the staging share for connections that no backup job explains, and the vault for changes that retention did not make. It reads the storage machine's audit policy to know what the Security log can tell it, and it never changes that policy. Without the auditing below, both watches still run, but they see less: short connections to the staging share can be missed, and a change to a backup is reported without saying who made it. The Manager raises Storage machines not fully watching the staging share while the auditing the share watch needs is off.

For complete coverage, turn on success auditing for these subcategories in the storage machine's Advanced Audit Policy, in its local security policy or with auditpol:

Subcategory (success)	What it adds
Logon/Logoff > Audit Logon	Event 4624: every logon of a job's account, with its client address, however briefly its session lasts.
Object Access > Audit File Share	Event 5140: every connection to the staging share by any account.
Object Access > Audit Detailed File Share	Event 5145: the staging folder reached through another share, such as an administrative share, and the client address of a change made to the vault over SMB. This subcategory logs every access to every share on the machine, so size the Security log for it.
Object Access > Audit File System	Events 4663 and 4660: the account and process that changed a committed backup. The storage agent adds the audit entry on each committed backup's folder that these events need; it audits nothing else on the machine.

Turning on the auditing

The storage machine is not joined to a domain, so set this in its local policy. You can use a command prompt or Local Security Policy.

To turn on the auditing from a command prompt:

On the storage machine, open a command prompt as an administrator.

Turn on success auditing for the four subcategories. The subcategories are given by their GUIDs, which work in every Windows language:

auditpol /set /subcategory:"{0CCE9215-69AE-11D9-BED3-505054503030}" /success:enable
auditpol /set /subcategory:"{0CCE9224-69AE-11D9-BED3-505054503030}" /success:enable
auditpol /set /subcategory:"{0CCE9244-69AE-11D9-BED3-505054503030}" /success:enable
auditpol /set /subcategory:"{0CCE921D-69AE-11D9-BED3-505054503030}" /success:enable

In order, these are Logon, File Share, Detailed File Share, and File System.

Check the result:

auditpol /get /subcategory:"{0CCE9215-69AE-11D9-BED3-505054503030},{0CCE9224-69AE-11D9-BED3-505054503030},{0CCE9244-69AE-11D9-BED3-505054503030},{0CCE921D-69AE-11D9-BED3-505054503030}"

Each of the four lines should show Success (or Success and Failure).

To turn on the auditing in Local Security Policy:

On the storage machine, run secpol.msc.
Go to Security Settings > Advanced Audit Policy Configuration > System Audit Policies - Local Group Policy Object.
Under Logon/Logoff, open Audit Logon, select Configure the following audit events and Success, and select OK.
Under Object Access, do the same for Audit File Share, Audit Detailed File Share, and Audit File System.

If the machine also has basic audit policies set under Local Policies > Audit Policy, check that Local Policies > Security Options > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings is Enabled, which is the default. Otherwise Windows ignores the subcategory settings.

You do not need to add audit entries to any folder: the storage agent adds the one that File System auditing needs on each committed backup. Detailed File Share logs every access to every share on the machine, so increase the maximum size of the Security log to keep enough history.

The storage agent reads the audit policy every 10 minutes, so Storage machines not fully watching the staging share clears without a restart once it sees the change, unless the alert gives another reason. To have it read the policy at once, restart the storage agent service, CygnaDRStorageAgent, while no backup is running.

For what the storage agent watches, see Vault Protection and Integrity.

Account for installing DC agents remotely

When you install or update the DC agent from the console or with cdr agent deploy, you supply an account for that run. The password is used only for the run and is never stored.

The account must be a local administrator on each target domain controller.
Enter it as DOMAIN\user or user@domain.
To install from the console, your operator account needs the System Admin role.

Each target must have:

The ADMIN$ administrative share, which is enabled by default.
The Remote Registry service, which Windows Server starts on demand by default.
WinRM, which is enabled by default on Windows Server, or, if you use DCOM, the Windows Management Instrumentation (WMI-In) firewall rule group enabled.

WinRM also needs a setting on the machine that runs the installation. When that machine is not in the target's domain, the target must be in its WinRM TrustedHosts list. Console installations run from the Manager, which is never in the domain, so for WinRM add your domain controllers to the Manager machine's TrustedHosts list. DCOM needs no such setting. You choose the transport with the Remote management transport setting on the Manager tab of the Configuration screen, or with the --transport option of cdr agent deploy.

The enrollment token is also needed for a new agent. A console installation uses the Manager's own token; cdr agent deploy asks you for it. You can also install agents manually or with your own software distribution tools, which needs no remote access. For the steps, see Deploying DC Agents.

Credentials needed during a recovery

Some recovery steps need directory credentials. You supply them when the recovery asks for them; they are never stored.

Credential	When it is needed
An Enterprise Admins or Domain Admins account	Seizing operations master roles and promoting rebuilt domain controllers.
An account in both Enterprise Admins and Schema Admins	Recovering the forest root domain.
The password of each domain's built-in Administrator account, as it was at the time of the backup	Signing in to a restored domain controller, including in Directory Services Restore Mode.

Record where these credentials are kept as part of your recovery planning. The built-in Administrator password in particular must be the one that was valid when the backup was taken, not the current one. For details, see Recovery Requirements.

Accounts for sizing and directory cleanup

cdr repository estimate—An account that is an administrator on the domain controllers. Give the domain by its DNS name, as user@corp.example.com or corp.example.com\user; the NetBIOS form, such as CORP\user, is refused because the command authenticates only with Kerberos. If you omit the account, the command uses your own sign-in on a domain-joined machine. See Sizing Backup Storage.
cdr cleanup—An account with domain administrator rights, to remove the directory data of a domain controller, domain, or trust that no longer exists. See Directory Cleanup Commands.

cdr never accepts a password as a command-line argument. It reads passwords from an environment variable or asks for them at a prompt, so they don't appear in your command history.

Cygna Forest Recovery operator accounts

People sign in to the console and cdr with Cygna Forest Recovery operator accounts. These accounts are kept in the Manager's database. They are not Windows or Active Directory accounts, so you can sign in while the directory is down. Each operator can also turn on multi-factor authentication, with a code from an authenticator app; it needs no internet access on the Manager or the phone. See Multi-Factor Authentication.

The first account, the break-glass account, is created when you first sign in to the console after installing the Manager. It holds every permission. You then create named accounts for each person and assign them roles: Viewer / Auditor, Backup Operator, Restore Operator, or System Admin. Approval and execution of a recovery are separate permissions, which among the roles only Restore Operator grants, and the System Admin role has no backup or restore permissions.

For details, see Signing In for the First Time and Managing Operators and Roles.