PowerCommanderログイン

PowerCommanderのConnect-Keeperに関する詳細

パラメータリファレンスと自動化の手引き

本ページでは、KeeperのSDKログインコマンドのページに示したPowerCommanderの概要に加え、Connect-Keeper ログインコマンドレットについて詳しく取り扱います。

別名: kc

対話的なセッション向けのフラグと、自動化 (Azure Automation Runbook、CIパイプライン、スケジュールタスクなど) 向けのフラグを選ぶときに使います。

一般的な指針

シナリオ

よく使うフラグ

対話型デスクトップ、保存済みプロファイル

Connect-Keeper または Connect-Keeper -Username [email protected]

フルログインを強制する (セッション再開なし)

-NewLogin

自動化、永続ディスクなし

-Username、-Password、-Device、必要に応じて -Server

構成ファイルパスありの自動化

-Username、-Password、-Config 'D:\path\config.json'

SSO (エンタープライズ)

-SsoProvider (および関連スイッチ)

大規模ボルト/オフラインキャッシュ

-UseOfflineStorage 、-VaultDatabasePath

認証のみで、まだボルト全体のダウンロードはしない

-SkipSync

パラメータ

Username

内容: アカウントのメール (Keeperのユーザー名)。位置 0 で、名前を付けずに先頭に渡せます。 Connect-Keeper '[email protected]'
目的: 認証するKeeperアカウントの特定。
省略時: -NewLogin を渡さず、保存された config.json にエンドポイントと同じサーバーでの最終ログインがある場合、PowerCommanderが保存されている構成からユーザー名を補完することがあります (対話時の利便性)。
自動化: スクリプトでは常に明示的に指定し、欠落した構成ファイルや古い構成に依存しないようにしてください。

Password

内容: コンソールで手入力しない場合に用いる、通常 (非SSO) アカウント向けのマスターパスワード。
目的: 非対話型ホスト (Runbook、リモートジョブ) では Read-Host に応答できないため、パスワードはパラメータで渡す必要があります。渡さない場合、ログイン処理はブロックされるか失敗します。
よくあるパターン:
- SecureString (推奨): Connect-Keeper -Username '[email protected]' -Password (Read-Host -AsSecureString -Prompt 'Password') または、暗号化されたAutomation変数やKey Vaultのシークレットから SecureString に変換した値。
- 平文の文字列: 一部のビルドではRunbook変数向けに Password に string を受け付けることがあります。シークレットストアや暗号化変数を優先し、ソース管理にリテラルを置かないでください。
再開の挙動: Password を渡すと、その呼び出しではセッション再開が無効になります (指定パスワードでのフル認証)。

NewLogin

内容: 新規ログインを強制し、保存済みセッションを再開しないスイッチ。
目的: ポリシー変更後の切り分けや、サーバーに新しいログインセッションとして扱わせたいときに便利です。
使うタイミング: 対話・スクリプトのいずれでも。Username (および自動化では Password) と併用します。

SsoPassword

内容: アカウントはSSOだが、本セッションはIdPフローではなくアカウントの代替 (マスター) パスワードで認証する旨を示すスイッチ。
目的: 一部のエンタープライズでは、SSO連携アカウントに対して特定ツールや復旧シナリオで「マスターパスワード」方式のアクセスを許可します。SDKは代替パスワードのログイン種別を設定します。
使うタイミング: アカウントと管理者ポリシーがSSO利用者の代替パスワードを許可している場合のみ。通常は Username と Password と併用します。

SsoProvider

内容: パスワード優先のログインではなくエンタープライズSSOログインを開始するようPowerCommanderに指示します。Username は必ずしもメールではなくエンタープライズドメイン/プロバイダー識別子として解釈されます。画面またはスクリプトのSSO手順に従ってください。
目的: KeeperのクラウドまたはオンプレミスSSO (エンタープライズ向けに構成された SAML/OIDC) に対応します。
使うタイミング: SSOのみの環境向けです。マスターパスワードとデバイストークンだけのRunbook自動化では、組織がその方式で運用している場合を除き、第一選択にはなりません。

Server

内容: リージョン/デプロイメントに応じたKeeperのホスト名 (例: keepersecurity.com、keepersecurity.eu)。KeeperEndpoint に渡され、省略時は構成の最終サーバーまたは既定の米国商用ホスト (keepersecurity.com) が使われます。
目的: 米国、EU、GovCloud、カスタムホストなど、接続先ごとにホスト名が異なります。誤った値ではログイン失敗やリダイレクトの原因になります。
自動化: アカウントが既定リージョンにないとき、または config.json がないとき (例: Device のみのRunbook実行) は明示的に指定します。

Device

内容: デバイストークン (config.json の device_token と同じ文字列)。このPowerCommander環境を表すbase64url形式の識別子です。
目的: 実行間に書き込み可能な永続ストレージがない環境 (例: Azure Automation Runbook) 向けに用意されています。ジョブごとにクリーンな状態で始まるため、読み込む config.json がありません。Device を渡すと、PowerCommanderはこのトークン (と任意のユーザー名/サーバー) だけを持つインメモリ構成を組み立て、ディスク上のJSONファイルを読みません。
挙動のメモ:
- Config と同時には使えません。
- SDKでは NoNewDevice が設定され、無効なトークンは失敗し、新しいデバイスを黙って登録しません。
- セッション再開 (clone_code) は使われません。Runbook実行間で何も永続化されないため、通常はフルログイン手順になり、自動化では多くの場合 -Password が必要です。
使うタイミング: あらかじめ発行したデバイストークンをシークレットストアやAutomation変数に保持するステートレス自動化。
使用しないほうがよい場合: config.json にデバイス鍵とクローンコードが保存され、永続的にセッションを維持する通常のワークステーション。Device は省略し、既定の構成パスを使います。

Config

内容: 特定の config.json へのパス (config.json を含むファイルまたはディレクトリ)。既定の解決順 (カレントディレクトリ / Documents\.keeper\config.json) を上書きします。
目的: 複数プロファイル (個人用と職場用など)、テスト、ジョブに永続ディスクがあり、固定の構成パスを使いたい自動化。
自動化: 実行ごとに config.json を書き込む/マウントする Runbookで、Device を使わない場合に便利です。
競合: Device と併用できません。

UseOfflineStorage

内容: ログイン後、ローカルボルトキャッシュにインメモリ構造だけでなく SQLite を使います。
目的: プロセス間で暗号化されたボルトデータを保持します。再同期が速く、オフライン対応フローの他要素と組み合わせるとオフライン可能なワークフローに使えます。
使うタイミング: キャッシュを毎回作り直すコストが高い常駐エージェントやマシン。オフラインストレージ用にPowerCommanderの隣にSQLiteバイナリを配置する必要があります (ドキュメント記載のとおり)。

VaultDatabasePath

内容: SQLiteデータベースファイルのフルパス (例: D:\data\keeper_db.sqlite)。
目的: UseOfflineStorage 指定時にオフライン用ボルトDBをどこに置くかを制御し、制限のあるディレクトリに構成の横へ置かないようにします。
既定: UseOfflineStorage ありで省略した場合、構成ディレクトリまたはカレントディレクトリ相対が既定です (詳細はコマンドレットのヘルプをご参照ください)。

SkipSync

内容: 認証が成功したあと、SyncDown (初回のボルト全体ダウンロード) を実行しないこと。有効な VaultOnline と IAuthentication は得られますが、Sync-Keeper を実行するまでローカルのフォルダツリーとレコードは空のままです。
目的: ボルト全体を読み込まずに認証が必要なAPIだけを呼ぶフロー向けです。コールドスタート時間とメモリを抑えます。
使うタイミング: ボルトのレコードに触れない自動化、または同一スクリプトの後半で Sync-Keeper する場合。

自動化のパターン

1. 対話型 (利用者向けの推奨)

Connect-Keeper -Username '[email protected]'
# プロンプトに従ってマスターパスワードを入力する。必要に応じて2FAやデバイス承認を行う

デバイスの永続化や任意のセッション再開のために、存在すれば既定の config.json を使います。

2. シークレット利用の自動化、ローカル構成なし (Runbook型)

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

パスワードは SecureString または対応するAutomation変数で渡します。
-Device はそのアカウントで登録済みのデバイストークンと一致させる必要があります。

3. チェックイン済みまたは配置済みの構成ファイルありの自動化

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

ワーカーが config.json の既知のパスを持つ場合に使います (シークレットは引き続き保護してください。構成には機微な情報が含まれます)。

4. セッション再開のスキップ

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

運用上のチェックリスト

リージョン: 既定でない場合は、アカウントのデータセンターに -Server が合っているか確認してください。
非対話: Read-Host で止まらないよう、-Password (通常は -Username も) を渡してください。
ステートレスホスト: -Device と保存済みトークンを使い、ディスクがない前提でセッション再開に頼らないようにしてください。
シークレット: シークレット保管ストアや暗号化変数を優先し、侵害があった場合はトークンとパスワードをローテーションしてください。
2FA/デバイス承認: アカウントで必須の場合でもSDKが手順を示すことがあります。一部のフローでは一回限りの対話承認やAPI対応チャネルが必要になるため、自動化の設計に反映してください。

前へ生体認証ログインコマンド次へゴミ箱コマンド

最終更新 22 日前