ユーザー、グループと権限の管理

テストユーザーを作成して VM 1 台へのアクセス権を付与し、続いてグループ、委任リソースセット、外部サインイン（LDAP または SAML）を試します。XOA-HL アプライアンスでは管理者として作業し、テストユーザーは別のブラウザーセッションでサインインします。使い捨てのテスト VM を使います。管理者セッションは最後まで開いたままにします。テスト中に、最後の管理者アカウントや自分の権限を変更しないでください。ローカルアカウントのサインインにワンタイムコードを追加するには、ワンタイムコードでサインインを保護するを参照してください。

2 種類の役割を知る

設定 → ユーザー一覧（/#/settings/users）では、各アカウント全体の権限を設定します。

• User は一般アカウントです。
• Admin は管理者です。オブジェクトのルールをすべて迂回します。

アクセスルール（ACL）は、ユーザーまたはグループに、1 つのオブジェクトに対する役割を与えます。オブジェクトの役割 Admin は、アカウント全体の Admin とは別のものです。選んだオブジェクトとその範囲にだけ適用されます。

最初はテスト VM 1 台に Viewer を付与します。ホストやプールへのルールは、VM 1 台へのルールより多くのオブジェクトへのアクセスを与える場合があります。グループへのルールは、すべての所属ユーザーに適用されます。権限は加算され、アクセスを拒否するルールはありません。ルールを 1 つ削除しても、別のグループ、別のオブジェクト、親オブジェクトから来るアクセスは残ります。

テストユーザーに VM 1 台へのアクセス権を与える

次の 4 つの手順で 1 つのテストになります。一般ユーザーを作成し、使い捨て VM 1 台に Viewer を付与し、できることを確認してから、アクセス権を取り消します。

テストユーザーを作成する

1. 設定 → ユーザー一覧 で、専用のメールアドレスまたはログイン名と固有のパスワードを持つ、別のテストユーザーを作成します。
2. Admin ではなく User を選びます。このアカウントに表示される権限を確認します。
3. 2 つ目のブラウザーセッションで、このユーザーとしてサインインします。ルールを追加する前に、見える範囲を控えます。

このセッションが、使い回した管理者のログインではなく、本当にテストユーザーであることを確認します。本番の資格情報は使わず、パスワードをメモに書かないでください。テストユーザーは残しておきます。下のグループのテストで再び使います。

VM 1 台に Viewer を付与する

1. 管理者として 設定 → ACL一覧（/#/settings/acls）を開きます。
2. 対象者にはテストユーザーだけ、オブジェクトには使い捨て VM だけ、役割には Viewer を選びます。Create を選びます。
3. 新しい行の対象者、オブジェクト、役割を確認します。

全オブジェクトやプール全体は選ばないでください。このフォームでは複数の対象者とオブジェクトを選べ、組み合わせごとにルールが 1 つ作成されます。似た表示名で判断せず、識別情報を確認します。オブジェクトとタグのフィルターは今あるオブジェクトを選ぶもので、将来のオブジェクトへのルールは作りません。

ユーザーができることを確認する

1. テストユーザーのセッションで、ページを更新するか、サインインし直します。
2. VM が表示され、基本情報を読めることを確認します。
3. 起動、停止、管理の操作が使えないことを確認します。操作を要求できてしまう場合は、拒否され、VM が変わらないことを確認します。

このテストは使い捨て VM だけで行います。ボタンが隠れているだけでは、サーバーが操作を拒否する証明になりません。

想定外に操作が成功したら、作業を止めます。管理者として、アカウント全体の権限、所属グループ、VM とそのホストやプールへの他のルールを確認します。原因の分からないアクセスエラーを直すために、権限を広げないでください。ACL の画面がない場合は、バージョンとエラーを控えて報告してください。別の製品版の有料プランが必要だと判断しないでください。

取り消して再確認する

1. 管理者として、対象のテスト用ルールを削除します。
2. テストユーザーのセッションで、更新するかサインインし直します。VM へのアクセスがなくなったことを確認します。
3. 管理者が引き続きサインインでき、対象のオブジェクトを管理できることを確認します。

アクセスが残る場合は、他の直接、グループ、継承のルールを探します。1 行を削除しても、すべての権限がなくなるわけではありません。

確認: ユーザーは VM を読めたが変更できず、ルールの削除後にアクセスを失いました。資格情報を含めずに、アカウントの種類、ルールの範囲、期待した結果と実際の結果を控えます。

このページのテストがすべて終わるまで、テストユーザーは残します。バックアップジョブの委任と API トークンの範囲はここでは扱いません。より広い変更の前に、ホストとプールを参照し、設定をエクスポートしてください。

ローカルグループでアクセス権を与える

グループのオブジェクトのルールは、すべての所属ユーザーに適用されます。ユーザーをグループに追加しても、そのユーザー全体の権限は変わりません。

始める前に

• テストユーザーに VM 1 台へのアクセス権を与えるを終えておきます。直接付与したルールは削除済みで、他のグループや親オブジェクトから VM へのアクセスがないことが必要です。
• 同じ一般テストユーザーと、同じ使い捨て VM を使います。
• 比較用に、グループに入れない 2 つ目の一般テストアカウントを用意します。
• 管理者セッションは開いたままにします。

グループとそのルールを作成する

1. 設定 → グループ一覧（/#/settings/groups）を開きます。New Group Name に lab-vm-viewers などの固有の名前を入力し、Create を選びます。
2. 新しいグループにユーザーがいないことを確認します。名前が既にある場合は、別の名前にします。内容の分からないグループを、その権限ごと使い回さないでください。
3. 設定 → ACL一覧 で、対象者にはこのグループだけ、オブジェクトにはテスト VM だけ、役割には Viewer を選びます。Create を選び、新しい行のグループ、VM、役割を確認します。
4. 2 つの一般アカウントの見える範囲が、以前と変わらないことを確認します。空のグループはアクセスを与えません。

ユーザーを追加してアクセスを確認する

1. グループ一覧 で、このグループの Add User 列からテストユーザーだけを選びます。変更はすぐに送信され、別の保存ボタンはありません。
2. Users 列の人数をプラスアイコンで展開し、ログイン名を確認します。
3. 設定 → ユーザー一覧 で、ユーザーの所属グループにこのグループが含まれ、アカウントが User のままであることを確認します。エラーが出たら、両方の画面を更新します。所属の 2 つの記録は別々に書き込まれるため、片方の一覧が正しく見えるだけでは不十分です。
4. 所属ユーザーのセッションで、更新するかサインインし直します。VM を読めること、そして起動、停止、管理の操作が使えないか、VM を変えずに拒否されることを確認します。
5. 2 つ目のアカウントには、引き続き VM へのアクセスがないことを確認します。

結果が異なる場合は、作業を止めます。実際の識別情報、全体の権限、所属グループ、すべての直接と親のルールを確認します。テストを通すために、より広い権限を追加しないでください。

メンバーを外す

1. グループ一覧 でメンバー一覧を展開し、対象のテストログイン名の横にある削除アイコンを選びます。確認なしで、すぐに送信されます。
2. ログイン名がグループから消え、ユーザーの詳細からグループが消えたことを確認します。
3. 元のメンバーのセッションで、更新するかサインインし直します。グループによる VM へのアクセスがなくなったことを確認します。

グループのルールは残ります。他のメンバーがいれば、そのアクセスは残ります。

権限が加算されることを確認する

1. ユーザーをグループに戻し、Viewer のアクセスが戻ることを確認します。
2. 同じ VM に、このユーザーへの直接の Viewer ルールを別に追加します。
3. VM に対するグループのルールだけを削除します。ユーザーは直接のルールで、引き続き VM を読めます。
4. 直接のルールも削除して、もう一度確認します。他の権限がなければ、グループに所属したままでもアクセスはなくなります。

グループのルールがないことは拒否を意味しません。また、全体の Admin はオブジェクトのルールをすべて迂回します。

グループのテストを片付ける

1. ユーザーとグループがまだ存在するうちに、テスト用のルールを削除します。
2. テスト用の所属を解除し、2 つの一般アカウントの結果を確認します。
3. 空になったテストグループの行と名前を確認します。その行の Delete Group を選び、確認します。確認画面にグループ名は出ないため、開く前にグループを特定してください。
4. グループ一覧、ACL一覧、ユーザー一覧の画面を更新します。独立した管理者は残します。

削除したグループのルールと所属は、XO がバックグラウンドで片付けます。グループが消えても、関連する記録がすべて消えたとは限りません。ACL の表では、対象者が存在しなくなった行が表示されないことがあります。要求が失敗した場合や記録が一致しない場合は、作業を止めます。秘密情報を除いて識別情報とエラーを控え、再試行や追加の削除の前に不整合を報告してください。

認証プロバイダーから同期したグループ、入れ子のグループ、名前の変更、より広い委任はここでは扱いません。同期したグループでは、ローカルでの名前とメンバーの操作が制限されます。この制限を回避するために、Synchronize LDAP groups を使ったり、認証プロバイダーを切り離したりしないでください。

委任リソースセットのクォータをテストする

リソースセットを使うと、一般ユーザーが、選ばれたテンプレート、SR、ネットワークから、CPU、RAM、ディスクの上限（クォータ）内で VM を作成できます。ここでは、使い捨てプール上で、1 人のユーザー向けに 1 つのセットをテストします。

始める前に

• 使い捨てのプールと、そのプールに広いルールを持たない専用の一般テストユーザーだけを使います。
• 独立した管理者セッションと、残したいデータの独立したバックアップを用意します。
• 本番のユーザーを追加したり、本番のストレージやネットワークを共有したりしないでください。
• ブラウザーセッションを 2 つ使います。XOA-HL の管理者セッションと、一般ユーザー用の別のセッションです。

リソースセットを作成する

1. 管理者として、使い捨てプール 1 つ、既知の停止したテンプレート 1 つ、十分な空き容量のある書き込み可能なテスト SR 1 つ、対象ホストから届く隔離した検証用ネットワーク 1 つを選びます。
2. それぞれの正確な UUID と、テンプレートの CPU、RAM、ディスクの既定値を控えます。テンプレートのディスクやネットワークをこれらのリソースに配置できない場合は、作業を止めます。
3. テストユーザーが全体の Admin ではなく User で、まだこのプールに VM を作成できないことを確認します。
4. セルフサービス → リソースセット（/#/self）を開き、新規リソースセット を選びます。セットに固有の検証用の名前を付けます。そのユーザーとそのプールだけを選び、続けて選んだ Templates、SRs、Networks だけを選びます。
5. ホストの一覧を確認します。エディターは、SR とネットワークへのアクセスに基づいて、対象になるホストと除外されるホストを表示します。予定したホストが少なくとも 1 台、対象になっている必要があります。
6. 合計最大CPU数、合計最大メモリ(RAM GiB)、合計最大仮想ディスク容量 に有限の値を設定します。テンプレートから小さな VM を 1 台作れる値で、次に試す上限超過の要求よりは低くします。
7. Share VMs by default はオフのままにし、IP プールは追加せず、保存 を選びます。エディターはセットを作成してから編集します。保存でエラーが出たら一覧を更新し、空のセットや不完全なセットがないか確認してから再試行します。
8. セットを再読み込みします。ID、ユーザー、テンプレート、SR、ネットワーク、ホスト、3 つの上限を確認します。現在の使用量（通常は 0）を控えます。

画面にアップグレードの案内が出る場合や、セットが見つからない場合は、バージョンを控えて作業を止めます。Vates のプランが必要だと判断したり、未確認の API 呼び出しで画面を迂回したりしないでください。

クォータを確認する

1. 一般ユーザーのセッションで VMの新規作成（/#/vms/new）を開き、対象のリソースセットを選びます。
2. CPU の上限を超える VM を要求します。テンプレート、SR、ネットワーク、RAM、ディスクは有効な値にします。サーバーは要求を拒否し、新しい VM も想定外のディスクも残らないはずです。
3. 管理者として、インベントリとクォータの使用量を確認します。操作が隠れているだけでは、上限が守られる証明になりません。不完全な VM やディスクが残っていたら作業を止め、片付けの前に一覧を控えます。
4. 一般ユーザーとして、選んだオブジェクトだけを使い、すべての上限内で VM を 1 台要求します。停止したままにします。隔離した状態で起動する前に、引き継いだ VIF を削除または切断します。
5. 新しい VM の UUID、ディスクの SR、ネットワーク、リソースセット、クォータの Used と Total の値を確認します。
6. 一般ユーザーがこの VM を表示・管理でき、セットを持たない別の一般アカウントはできないことを確認します。

本番の VM で上限を試さないでください。既定では、XO は VM の作成者に、その VM のオブジェクトの役割 Admin を与えます。Share VMs by default をオンにすると、これがセットのユーザーにも広がります。テストユーザーに、プール全体への管理者のルールは不要です。

確認: 上限を超える要求は何も残さずに拒否され、上限内の VM はクォータの使用量に表示されています。

ユーザーをセットから外す

1. 管理者として、テストユーザーをセットから外します。一般ユーザーのセッションを更新します。
2. ユーザーがセットを選べず、そのセットで別の VM を作成できないことを確認します。
3. 既存の VM に残る直接や継承のルールを、別に確認します。ユーザーをセットから外すと、セットに関係する VM のルールは削除されますが、他の権限があればアクセスは残ります。

アクセスや使用量が合わない場合は作業を止め、秘密情報を除いて、セットと VM の ID とエラーを控えます。原因の説明できない修復として リソースセットの再計算 を使わないでください。

リソースセットのテストを片付ける

1. 新しい VM を停止し、正確な VM と VDI の ID を確認します。VIF を削除します。
2. その使い捨て VM だけを削除します。ディスクとスナップショットが意図どおりに処理されたことを確認します。
3. クォータの使用量とセットの VM 数を更新します。セットに VM が残っていないことを確認します。
4. 対象のセットで リソースセットの消去 を選びます。セットの削除では VM とセットの関連が外れるだけで、VM は削除されません。
5. 一般ユーザー、独立した管理者、プールのインベントリを再確認します。

資格情報を含めずに、期待した ID と実際の ID、拒否の結果、クォータの値、片付けの内容を控えます。グループを対象者にする場合、IP プール、既定の共有、複数 VM の同時作成、作成失敗後の片付け、本番での委任はここでは扱いません。

外部 LDAP サインインをテストする

LDAP サインインは、XO アカウントを作成したり、既存のアカウントに紐付いたりすることがあります。使い捨てのディレクトリと、管理者ではない専用のテスト ID を 1 つ使います。

始める前に

• 独立したローカル管理者のセッションと、復旧の手段を残します。
• 管理者として、イメージ、パッケージ、XO のバージョンと、実際の認証設定を控えます。非公開の設定エクスポートを保存します。
• 設定 → プラグイン（/#/settings/plugins）で、auth-ldap がバージョン付きで表示されることを確認します。設定、読み込み、自動読み込みの状態を、秘密情報を除いて控えます。表示されない場合や、既に実際のユーザーが使っている場合は、作業を止めます。
• ディレクトリの担当者と、信頼できる CA を使う隔離した LDAPS または StartTLS の接続先、一意で変わらないユーザー ID 属性、絞り込んだユーザーのベースとフィルター、必要なら専用の検索用 ID を用意します。
• このテストのために、最後のローカル管理者や既存のプロバイダーを変更しないでください。

プラグインを設定して読み込む

1. 承認された検証時間内に、ディレクトリの担当者から受け取った値だけをプラグインのフォームに入力します。URI、CA のパス、有効にした証明書の検証、StartTLS の選択、ベース、ユーザーのフィルター、ID 属性、検索用の資格情報です。
2. Synchronize groups は設定しません。所属を取り込み、誰が何にアクセスできるかを変えることがあります。
3. TLS の識別情報と到達性を別に確認します。エラーを隠すために証明書の検証を無効にしないでください。
4. 設定を保存します。次にプラグインを読み込み、読み込みと自動読み込みの状態を確認します。この画面で読み込むと、自動読み込みも有効になります。

保存しただけでは、サインインが動く証明になりません。秘密情報は非公開にし、画面の記録、ログ、問題の報告に含めないでください。

1 回サインインしてアカウントを確認する

Test は、無害な接続確認として使わないでください。実際のサインイン処理が動き、XO アカウントが作成されたり、設定によってはグループが同期されたりします。

1. 新しい別のブラウザーセッションで、ディレクトリの固有のテスト ID を使って 1 回だけサインインします。
2. 管理者セッションで、新しい XO ユーザーの ID、プロバイダー、全体の権限（User）、所属グループ、見える範囲を確認します。サインインに成功しただけでは、オブジェクトへのアクセスは与えられません。
3. VM 1 台に Viewer を付与すると同じように、このアカウントに使い捨て VM 1 台だけの Viewer を与えます。そのセッションで VM を読めること、運用と管理の操作が表示されないか、何も変えずに拒否されることを確認します。
4. 対象のルールを削除します。更新したセッションで、アクセスがなくなったことを確認します。
5. ディレクトリの誤ったパスワードを、内容を明かさずに試します。独立したローカル管理者が引き続きサインインできることを確認します。

既存の XO アカウントに紐付いた場合、想定外の管理者の役割やグループが現れた場合、プロバイダーや証明書の結果がはっきりしない場合は、作業を止めます。秘密情報を除いた証拠を残し、担当者の復旧計画に従います。サインインを繰り返したり、権限を追加したりしないでください。

LDAP のテストを片付ける

1. テスト用のルールとテスト用の所属だけを削除します。外部セッションからサインアウトします。
2. auth-ldap の読み込みを解除し、読み込みと自動読み込みの状態を確認します。ローカル管理者は使える状態のままにします。
3. テストアカウントを削除する前に、対象のユーザー、そのトークンとルールを特定します。アカウントの削除とプラグイン設定の消去は別の操作です。他のユーザーが使っているプロバイダーは消去しないでください。

読み込み、サインイン、読み込みの解除が失敗した場合は、再試行の前に、秘密情報を除いたエラーと、ユーザーとプロバイダーの実際の状態を保存します。失敗を回避するために、TLS の確認を緩めたり、アカウントを統合したりしないでください。プロバイダー、バージョン、TLS の信頼、ID の対応、前後のユーザーとルールの ID、許可と拒否の結果、維持したローカルのサインインを控えます。グループの同期、ディレクトリの障害、資格情報の更新、ID の名前変更、トークン、OTP、切り替えはここでは扱いません。

外部 SAML サインインをテストする

隔離した ID プロバイダー（IdP）のアプリケーション、固有の名前を持つ管理者ではないテスト ID 1 つ、独立したローカルの XO 管理者が必要です。プラグインは、usernameField で指定したプロファイル属性から XO のユーザー名を取ります。

始める前に

• IdP の担当者と一緒に、イメージ、パッケージ、XO、プラグインのバージョン、実際の認証設定、公開 HTTPS アドレスを控えます。非公開の設定エクスポートを保存します。
• 設定 → プラグイン（/#/settings/plugins）に auth-saml が表示され、実際のユーザーに使われていないことを確認します。
• usernameField に使う、変わらない一意のプロファイル属性を決めます。プラグインを読み込む前に、そのテスト値をすべての XO ユーザー名と照合します。
• 使えるローカル管理者のセッションと、コンソールによる別の復旧手段を残します。
• 公開アドレス、プロキシ、アカウントの対応がはっきりしない場合は、作業を止めます。

アプライアンスを IdP に登録する

1. この検証用のサービスプロバイダーだけを IdP に登録します。戻り先 URL は、外部から届く https://<appliance-name>/signin/saml/callback と一致させます。正確な DNS 名、証明書の信頼、プロキシを経由するリダイレクトを確認します。
2. IdP の署名証明書、エントリーポイント、合意した発行者を、担当者の非公開の経路で受け取ります。この証明書は、アプライアンスの HTTPS 証明書とは別のものです。
3. IdP の担当者と合意したとおり、署名付きの SAML レスポンスまたはアサーションを必須にします。プラグインの既定値 wantAssertionsSigned と wantAuthnResponseSigned はどちらも false ですが、署名のないメッセージを受け入れてよいわけではありません。

これらのオプションを IdP の担当者と確認します。不一致を隠すために、署名や TLS の確認を弱めないでください。

設定、読み込み、サインインを行う

1. 検証用の証明書、エントリーポイント、発行者、ユーザー名の属性と、担当者が承認した戻り先や厳格化のオプションだけを入力します。
2. 設定を保存します。次にプラグインを読み込み、読み込みと自動読み込みの状態を確認します。保存だけでは有効になりません。この画面で読み込むと、自動読み込みも有効になります。
3. 新しい別のブラウザーセッションで、XO のサインイン画面から SAML のサインインを始めます。割り当てた検証用 ID で 1 回だけ認証します。
4. IdP の担当者に、アサーションを公開せずに、署名付きの応答と選んだ属性を確認してもらいます。

証明書、アサーション、プロファイルのデータ、セッショントークンを、公開の問題報告に貼らないでください。

新しいアカウントを確認する

1. 管理者セッションで、新しい XO ユーザーの ID、saml プロバイダー、全体の権限（User）、所属グループ、見える範囲を確認します。
2. VM 1 台に Viewer を付与すると同じように、使い捨て VM 1 台だけの Viewer を与えます。読み取りができ、操作が拒否されることを確認します。
3. 対象のルールを削除します。更新したセッションで、アクセスがなくなったことを確認します。
4. IdP の担当者に、割り当てていない検証用の比較 ID を、新しいセッションで拒否してもらいます。これは新しいサインインのテストで、既存の XO トークンの取り消しのテストではありません。
5. ローカル管理者が引き続きサインインできることを確認します。

既存のユーザーに紐付いた場合、特権のある役割が現れた場合、属性がない場合、署名や戻り先の結果がはっきりしない場合は、作業を止め、秘密情報を除いた証拠だけを残します。ユーザー名の属性がないと、プラグインはプロファイル全体をログに出力します。失敗時のログは機密情報として扱ってください。

SAML のテストを片付ける

1. SAML のテストセッションからサインアウトし、テスト用のルールを削除します。
2. 隔離した auth-saml プラグインだけの読み込みを解除します。読み込みと自動読み込みの状態、ローカルのサインインを確認します。
3. アカウントを削除する前に、対象のテストユーザーとそのトークンを一覧にします。サインアウトやプロバイダーの無効化だけでは、既存の XO トークンが無効になった証明になりません。実際のユーザーが使っているプロバイダーは消去しないでください。

失敗した場合は、再試行の前に、秘密情報を除いた戻り先とエラー、ユーザー、プロバイダー、トークンの実際の状態を控えます。戻り先のアドレス、IdP 証明書の識別情報と有効期限、署名の方針、対応する属性、プラグインの状態、前後のユーザーとルールの ID、結果、維持したローカルのアクセスを、秘密情報を除いて控えます。IdP の障害、署名鍵の更新、時刻のずれ、属性の変更、トークンとセッションの取り消し、OTP、本番のフェデレーションはここでは扱いません。