# PowerCommander login

## Parameter reference and automation guide

This document expands the Power Commander login cmdlet beyond the summary on [Keeper’s SDK login commands page](https://docs.keeper.io/en/keeperpam/commander-sdk/keeper-commander-sdks/sdk-command-reference/login-commands#powercommander).

**Alias:** `kc`.

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

### General Guidelines

<table><thead><tr><th width="319.9033203125">Scenario</th><th>Typical flags</th></tr></thead><tbody><tr><td>Interactive desktop, saved profile</td><td><code>Connect-Keeper</code> or <code>Connect-Keeper -Username user@company.com</code></td></tr><tr><td>Force full login (no session resume)</td><td><code>-NewLogin</code></td></tr><tr><td>Automation, <strong>no</strong> persistent disk</td><td><code>-Username</code>, <code>-Password</code>, <code>-Device</code>, optionally <code>-Server</code></td></tr><tr><td>Automation <strong>with</strong> config file path</td><td><code>-Username</code>, <code>-Password</code>, <code>-Config 'D:\path\config.json'</code></td></tr><tr><td>SSO (enterprise)</td><td><code>-SsoProvider</code> (and related switches)</td></tr><tr><td>Large vault / offline cache</td><td><code>-UseOfflineStorage</code> , <code>-VaultDatabasePath</code></td></tr><tr><td>Auth only, no full vault download yet</td><td><code>-SkipSync</code></td></tr></tbody></table>

### Parameters

#### Username

* **What:** Account email (Keeper username). **Position 0** — can be passed first without the name:\
  `Connect-Keeper 'user@example.com'`
* **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 'u@example.com' -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&#x20;*****not*****&#x20;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)

```powershell
Connect-Keeper -Username 'you@company.com'
# 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)

```powershell
Connect-Keeper `
  -Username 'automation@company.com' `
  -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

```powershell
Connect-Keeper -Username 'automation@company.com' -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

```powershell
Connect-Keeper -Username 'you@company.com' -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.

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/keeperpam/commander-sdk/keeper-commander-sdks/sdk-command-reference/login-commands/powercommander-login.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.