Connecting and Signing In

Before cdr sends a request to a Manager, two things must be in place: cdr must trust the Manager's certificate authority (CA), and you must be signed in as an operator. Both are saved for your Windows account on this computer, so you set them up once per Manager.

Operator accounts are the Manager's own accounts, the same ones you use in the console. They are not Windows or Active Directory accounts, so you can sign in while the directory is down. The cdr operator commands at the end of this topic list, remove, and restore those accounts.

Trusting the Manager on first use

The first time you connect to a Manager address, cdr fetches the Manager's CA certificate, shows its fingerprint, and asks whether to trust it:

cdr has not connected to the manager at https://10.0.0.10:5210/ before.
Its CA fingerprint is:
  3F2A-91C0-5B7E-04D8-C1A6-2E9F-7B30-D4C2-8E15-6A9B-F0D3-1C47-B8E2-5D90-A6F1-E7F8
Compare it with the fingerprint on the manager's console, or in its event log. Trust it only if they match: a different value means you are not talking to your manager.
Trust this manager and remember it for this address?

Compare the value with a second source before you answer, such as the Manager's event log or the copy in your recovery notes; for where else it is shown, see Certificates and Trust. When you confirm, cdr saves the fingerprint for this address in %LOCALAPPDATA%\Cygna Labs\Disaster Recovery Suite\cdr-trusted-managers.json. Every later connection to the address must present the same CA, or cdr refuses to send anything and exits with code 9.

A script or scheduled task has no terminal to confirm on. Give it the fingerprint with --manager-ca or the CYGNADR_MANAGER_CA environment variable; cdr checks it against what the Manager presents. You can also save it once in advance with cdr trust pin. The fingerprint can be entered with or without the hyphens.

To list, save, or forget fingerprints, use the cdr trust commands described in Agent and Trust Commands. For background, see Certificates and Trust.

Sessions

Saved per Windows user and Manager—cdr login saves the session for the Manager address you signed in to, protected with Windows data protection for your Windows account, in %LOCALAPPDATA%\Cygna Labs\Disaster Recovery Suite\cdr-sessions.json. Another Windows user on the same computer has to sign in separately.
Lifetime—A session ends 12 hours after sign-in, or after 4 hours without use, whichever comes first. When it has ended, commands exit with code 10; run cdr login again.
Same rules as the console—A cdr session is the same kind of session the console holds. The Manager applies the same capability checks, and the audit trail records your username against everything you do.
Ended by account changes—Disabling or removing your account, an administrator resetting your password or your multi-factor authentication (MFA), changing your own password, or turning on MFA for yourself ends your other sessions, including the one cdr holds.

login

Signs in to the Manager as an operator and saves the session for this Windows user until it expires or you run cdr logout.

The password is never an argument. cdr reads it from the CYGNADR_PASSWORD environment variable, or prompts for it. If the account has a temporary password—a new account, or one an administrator has reset—cdr asks you to choose a new password and to repeat it, as the console does. Choosing a new password needs a terminal; from a script, sign in once interactively or in the console first.

If your account uses MFA, cdr asks for the code after the password, with the prompt Authenticator code (or a recovery code):. Enter the 6-digit code your authenticator app shows, or one of your recovery codes. If the code is refused, cdr shows why and asks again. It prompts for a code at most three times in one run. When too many wrong codes have locked authenticator codes, it asks for a Recovery code: instead, because recovery codes still work during the lock. You can also give the code with --code. Unlike the password, a code is safe on the command line: it is accepted only once, so a copy in your shell history is useless. A recovery code given with --code is also used up by the sign-in. MFA is turned on and off in the console, not with cdr. See Multi-Factor Authentication.

When there is no terminal, for example in a scheduled task, an account with MFA needs --code. Without it, cdr login stops with This account uses MFA and there is no terminal to prompt on. Pass --code with the code your authenticator app shows. and exits with code 1. A wrong or locked code exits with code 3, like any other refused sign-in.

After five failed attempts in a row, the account is locked for 15 minutes. A refused sign-in does not say whether the account exists, is locked, or is disabled; the audit trail records the reason. No more than 10 failed sign-ins from one address are allowed in any 15 minutes: after that, sign-ins from it are refused with Too many failed sign-ins from this address until the oldest failure is 15 minutes old. The break-glass account is never locked by wrong passwords, and is refused for its address only when it does not sign in on the Manager machine itself. When you sign in with the break-glass account, cdr warns you that everything it does is audited as break-glass, and that you should use a named account when one is available.

Requirements: An enabled operator account on the Manager. Runs on Windows only.

Syntax

cdr login [options]

Options

Option	Description
`-u, --username <NAME>`	The operator to sign in as. Default: you are prompted for it. Required when there is no terminal.
`--code <CODE>`	For an account with MFA: the code your authenticator app shows now, or a recovery code. Default: you are prompted for it when the account needs one. Required for an account with MFA when there is no terminal.

The global options also apply. Use --manager to choose the Manager to sign in to.

Examples

cdr login
cdr login --username jsmith --manager https://10.0.0.10:5210
cdr login --username jsmith --code 492817

From a scheduled task, with the fingerprint and password supplied by the task's environment:

cdr login --username svc-monitor --manager https://10.0.0.10:5210 --manager-ca 3F2A-91C0-5B7E-04D8-C1A6-2E9F-7B30-D4C2-8E15-6A9B-F0D3-1C47-B8E2-5D90-A6F1-E7F8

logout

Ends your session on the Manager and removes it from this computer. The session is ended on the Manager first, so a copy of the token taken earlier stops working too. If the Manager cannot be reached, the saved session is still removed, and the session on the Manager expires on its own. If you are not signed in, the command says so and succeeds.

Requirements: None. Runs on Windows only.

Syntax

cdr logout [options]

Takes the global options only.

Example

cdr logout --manager https://10.0.0.10:5210

whoami

Shows who the Manager says this run is signed in as: the username and display name, the Manager address, the roles (or break-glass), the capabilities those roles grant, whether MFA is on and how many recovery codes are left, and when the session ends. The answer comes from the Manager, not from the saved session, so it reflects any role change made since you signed in.

Requirements: A current session.

Syntax

cdr whoami [options]

Takes the global options only.

Example

cdr whoami --json

operator list

Lists the operator accounts on the Manager, as the Operators tab in the console shows them: username, display name, roles (or break-glass), status, whether MFA is on, and the last sign-in. The status is active, temporary password, locked until a time, disabled, or removed with the date and who removed it.

The table leaves removed accounts out, and says on standard error how many it left out. --removed includes them. --json always writes every account; a removed account has a removedAtUtc value.

Creating, editing, disabling, and enabling operators, and resetting passwords and MFA, are done in the console. See Operators and Roles Screen.

Requirements: The accounts.manage capability (System Admin role).

Syntax

cdr operator list [--removed]

Option	Description
`--removed`	Include removed operators in the table.

Examples

cdr operator list
cdr operator list --removed
cdr operator list --json

operator remove

Removes the account of someone who has left. Every session the account has, in the console and in cdr, ends at once. Its password, MFA, and roles are cleared, not kept. The account stays in the audit trail and its username stays reserved, so nobody else can be created under it. For a temporary absence, disable the account in the console instead: that keeps its roles. For the difference, see Managing Operators and Roles.

Before it asks for confirmation, the command shows the account's display name and the roles, MFA, and disabled state being cleared. If the account is already removed, it says when and by whom, changes nothing, and exits with code 0. The Manager refuses to remove your own account or the break-glass account; cdr shows the Manager's message and exits with code 3.

Requirements: The accounts.manage capability (System Admin role).

Syntax

cdr operator remove <USERNAME> [--yes]

Argument or option	Description
`<USERNAME>`	Required. The operator who has left. Case does not matter.
`--yes`	Skip the confirmation. Required when standard input is not a terminal.

Exit codes: 0 when the account is removed, was already removed, or you answered no; 3 when no operator has the username or the Manager refused; 1 for a usage error, including no --yes without a terminal.

Examples

cdr operator remove jsmith
cdr operator remove jsmith --yes

operator restore

Restores a removed account, for the same person returning. Nothing comes back from before: the account gets a new temporary password, no MFA, and only the roles you name now. The command prints the temporary password once, on standard output; with --json, it is in the temporaryPassword field. Give it to the operator by a channel you trust. They choose their own password at their next sign-in, in the console or with cdr login, and turn MFA on again from the console's account menu.

The Manager refuses an account that is not removed; cdr shows the Manager's message and exits with code 3.

Requirements: The accounts.manage capability (System Admin role).

Syntax

cdr operator restore <USERNAME> --role <ROLE> [--role <ROLE>...] [--display-name <NAME>]

Argument or option	Description
`<USERNAME>`	Required. The removed operator who is returning. Case does not matter.
`-r, --role <ROLE>`	Required. A role to grant: `viewer` (Viewer / Auditor), `backupOperator`, `restoreOperator`, or `systemAdmin`. Case does not matter. Repeat the option for several roles.
`--display-name <NAME>`	A new display name. Default: the display name the account had.

Exit codes: 0 when the account is restored; 3 when no operator has the username or the Manager refused; 1 for a usage error, including no --role or a name that is not a role.

Examples

cdr operator restore jsmith --role viewer
cdr operator restore jsmith --role backupOperator --role restoreOperator