PowerCommander login

Detailed description on connect-keeper for powercommander

Parameter reference and automation guide

This document expands the Power Commander login cmdlet beyond the summary on Keeper’s SDK login commands page.

Alias: kc.

Use it when choosing flags for interactive sessions vs automation (Azure Automation Runbooks, CI pipelines, scheduled tasks, etc.).

General Guidelines

Scenario	Typical flags
Interactive desktop, saved profile	Connect-Keeper or Connect-Keeper -Username [email protected]
Force full login (no session resume)	-NewLogin
Automation, no persistent disk	-Username, -Password, -Device, optionally -Server
Automation with config file path	-Username, -Password, -Config 'D:\path\config.json'
SSO (enterprise)	-SsoProvider (and related switches)
Large vault / offline cache	-UseOfflineStorage , -VaultDatabasePath
Auth only, no full vault download yet	-SkipSync

Parameters

Username

• What: Account email (Keeper username). Position 0 — can be passed first without the name: Connect-Keeper '[email protected]'

• Why: Identifies which Keeper account to authenticate.

• When omitted: If you do not pass -NewLogin and your stored config.json has a last login on the same server as the endpoint, Power Commander may fill the username from config (interactive convenience).

• Automation: Always set explicitly in scripts so behavior does not depend on a missing or stale config file.

Password

• What: Master password used for regular (non-SSO) accounts when you are not typing it at the console prompt.

• Why: Non-interactive hosts (Runbooks, remote jobs) cannot answer Read-Host; the password must be supplied as a parameter or the login flow will block or fail.

• Typical patterns:

  • SecureString (recommended): Connect-Keeper -Username '[email protected]' -Password (Read-Host -AsSecureString -Prompt 'Password') Or from an encrypted Automation variable / Key Vault secret converted to SecureString.

  • Plain string: Some builds accept string for Password for Runbook variables; prefer secrets from a vault or encrypted variables, never literals in source control.

• Resume behavior: If Password is provided, session resume is disabled for that invocation (full authentication path with the supplied password).

NewLogin

• What: Switch that forces a fresh login and does not resume a previously stored session.

• Why: Useful after policy changes, troubleshooting, or when you intentionally want the server to treat this as a new login session.

• When: Interactive or scripted; pairs with Username (and Password in automation).

SsoPassword

• What: Switch indicating the account uses SSO but you are authenticating with the account’s alternate (master) password instead of the IdP flow for this session.

• Why: Some enterprises allow “master password” style access for SSO-linked accounts in specific tools or recovery scenarios; the SDK sets the alternate-password login type.

• When: Only when your account and admin policy support alternate password for SSO users. Usually combined with Username and Password.

SsoProvider

• What: Tells Power Commander to start enterprise SSO login instead of password-first login. Username is interpreted as the enterprise domain / provider identifier , not always an email—follow on-screen or scripted SSO steps.

• Why: Aligns with Keeper’s cloud or on-premises SSO flows (SAML/OIDC as configured for the enterprise).

• When: SSO-only environments; not the usual choice for simple Runbook master-password + device-token automation unless your org uses SSO in that automation.

Server

• What: Keeper hostname for your region / deployment (for example keepersecurity.com, keepersecurity.eu). Passed through to KeeperEndpoint; if omitted, the client uses last server from config or the default US commercial host (keepersecurity.com).

• Why: Same codebase talks to US, EU, GovCloud, or custom-hosted endpoints; the wrong server yields login failures or redirects.

• Automation: Set explicitly when the account is not on the default region or when no config.json exists (for example pure Device Runbook runs).

Device

• What: Device token (same string as device_token in config.json) — base64url identifier for this Power Commander “device.”

• Why: Built for environments with no writable persistent storage between runs (for example Azure Automation Runbooks): each job starts clean, so there is no config.json to load. Passing Device makes Power Commander build an in-memory configuration that only carries this token (plus optional username/server), without reading a JSON file from disk.

• Behavior notes:

  • Mutually exclusive with Config.

  • SDK NoNewDevice is set so an invalid token fails instead of silently registering a new device.

  • Session resume (clone_code) is not used—nothing is persisted between Runbook runs, so expect full login steps, typically -Password for master password in automation.

• When: Stateless automation with a pre-provisioned device token stored in a secret store or Automation variable.

• When not to use: Normal workstation use where config.json already holds device keys and clone codes for persistent login — omit Device and use the default config path.

Config

• What: Path to a specific config.json (file or directory containing config.json). Overrides the default resolver (current directory / Documents\.keeper\config.json).

• Why: Multiple profiles (personal vs work), tests, or automation where the job does have a persistent disk and you want a fixed config path.

• Automation: Useful when the Runbook writes or mounts a config file per execution without using Device.

• Conflict: Cannot be combined with Device.

UseOfflineStorage

• What: After login, use SQLite for the local vault cache instead of only in-memory structures.

• Why: Persists encrypted vault data between processes—faster re-sync, usable for offline-capable workflows when paired with the rest of the offline story.

• When: Long-running agents or machines where rebuilding the cache every time is expensive. Requires SQLite binaries deployed next to Power Commander as documented for offline storage.

VaultDatabasePath

• What: Full path to the SQLite database file (for example D:\data\keeper_db.sqlite).

• Why: Controls where the offline vault DB is stored when UseOfflineStorage is set; avoids putting the DB next to the config in restricted directories.

• Default: If omitted with UseOfflineStorage, defaults relative to the config directory or current directory (see cmdlet help).

SkipSync

• What: After authentication succeeds, do not run SyncDown (initial full vault download). You get a valid VaultOnline and IAuthentication, but the local folder tree and records stay empty until Sync-Keeper runs.

• Why: Needed for flows that only call APIs that require auth without loading the whole vault; reduces cold-start time and memory.

• When: Automation that never touches vault records, or when you will Sync-Keeper later in the same script.

Automation patterns

1. Interactive (recommended for humans)

Connect-Keeper -Username '[email protected]'
# Enter master password when prompted; 2FA / device approval as required

Uses default config.json when present for device persistence and optional session resume.

2. Automation with secrets, no local config (Runbook-style)

Connect-Keeper `
  -Username '[email protected]' `
  -Password $securePwdFromVault `
  -Device $deviceTokenFromVault `
  -Server 'keepersecurity.com'

• Supply password via SecureString or supported automation variable.

• -Device must match a registered device token for that account.

3. Automation with a checked-in or deployed config file

Connect-Keeper -Username '[email protected]' -Password $securePwd -Config 'D:\Keeper\config.json'

Use when the worker has a known path to config.json (still protect secrets; config holds sensitive material).

4. Skip session resume

Connect-Keeper -Username '[email protected]' -NewLogin

---

Operational checklist

1. Region: Confirm -Server matches the account’s data center if not default.

2. Non-interactive: Provide -Password (and usually -Username) so nothing blocks on Read-Host.

3. Stateless hosts: Use -Device + stored token; do not rely on resume without disk.

4. Secrets: Prefer vault / encrypted variables; rotate tokens and passwords on compromise.

5. 2FA / device approval: If the account requires them, the SDK may still present steps—some flows need one-time interactive approval or API-supported channels; design automation accordingly.

---