XenServer

ユーザー管理

ユーザー、グループ、ロール、および権限を定義することで、XenServer® ホストおよびプールに誰がアクセスできるか、およびどのような操作を実行できるかを制御できます。

XenServerを初めてインストールすると、ユーザーアカウントがXenServerに自動的に追加されます。このアカウントは、ローカルスーパーユーザー (LSU) またはrootであり、XenServerがローカルで認証します。

LSU、つまりrootは、システム管理を目的とし、すべての権限を持つ特別なユーザーアカウントです。XenServerでは、LSUはインストール時のデフォルトアカウントです。XenServerはLSUアカウントを認証します。LSUは外部認証サービスを必要としません。外部認証サービスが失敗した場合でも、LSUはログインしてシステムを管理できます。LSUは常にSSHを介してXenServer物理サーバーにアクセスできます。

XenCenterの[ユーザー]タブまたはxe CLIのいずれかを使用してActive Directoryアカウントを追加することで、さらにユーザーを作成できます。環境でActive Directoryを使用しない場合、LSUアカウントに限定されます。

注:

ユーザーを作成すると、XenServerは新しく作成されたユーザーアカウントにRBACロールを自動的に割り当てません。したがって、これらのアカウントには、ロールを割り当てるまでXenServerプールへのアクセス権がありません。

これらの権限は、Active Directory (AD) を使用したユーザー認証セクションで説明されているとおり、ロールを通じて付与されます。

Active Directory (AD) を使用してユーザーを認証する

ホストまたはプールに複数のユーザーアカウントを持たせたい場合は、認証にActive Directoryユーザーアカウントを使用する必要があります。ADアカウントを使用すると、XenServerユーザーはWindowsドメイン資格情報を使用してプールにログオンできます。

注:

ADドメインコントローラーでLDAPチャネルバインディングとLDAP署名を有効にできます。詳細については、Microsoft Security Advisory ADV190023を参照してください。

Active Directory認証を有効にし、ユーザーアカウントを追加し、それらのアカウントにロールを割り当てることで、特定のユーザーに対してさまざまなレベルのアクセスを構成できます。

Active Directoryユーザーはxe CLI (適切な-uおよび-pw引数を渡して) を使用でき、XenCenterを使用してホストに接続することもできます。認証はリソースプールごとに実行されます。

サブジェクトはユーザーアカウントへのアクセスを制御します。XenServerのサブジェクトは、Active Directoryサーバー上のエンティティ (ユーザーまたはグループのいずれか) にマッピングされます。外部認証を有効にすると、XenServerはセッションの作成に使用された資格情報をローカルのroot資格情報と照合し、次にサブジェクトリストと照合します。アクセスを許可するには、アクセスを許可するユーザーまたはグループのサブジェクトエントリを作成します。XenCenterまたはxe CLIを使用してサブジェクトエントリを作成できます。

XenCenterに慣れている場合、xe CLIではActive Directoryおよびユーザーアカウント機能を参照するためにわずかに異なる用語が使用されていることに注意してください。

XenCenterの用語 xe CLIの用語
ユーザー、ユーザーの追加 サブジェクト、サブジェクトの追加

XenServerはLinuxベースですが、XenServerではActive DirectoryアカウントをXenServerユーザーアカウントとして使用できます。そのためには、Active Directoryの資格情報をActive Directoryドメインコントローラーに渡します。

Active DirectoryをXenServerに追加すると、Active DirectoryのユーザーとグループはXenServerのサブジェクトになります。これらのサブジェクトは、XenCenterではユーザーと呼ばれます。XenServerにサブジェクトを登録すると、ログオン時にActive Directoryを使用してユーザー/グループが認証されます。ユーザーとグループは、ドメイン名を使用してユーザー名を修飾する必要はありません。

XenServerホストにログオンするには、Active Directoryユーザーは、XenServerのマシンアカウントをホストするコンピューターにログオンするためのドメインレベルの権限を持っている必要があります。デフォルトでは、Windows Server 2019ドメインでは、すべてのユーザーがドメイン内の任意のコンピューターにログオンすることを許可されています。ただし、この設定を変更した場合は、XenServerホストへのアクセスを許可したいユーザーがドメインレベルでログオンすることを許可されていることを確認してください。

ユーザー名を修飾するには、ユーザー名をDown-Levelログオン名形式で入力する必要があります。例: mydomain\myuser

注:

デフォルトでは、ユーザー名を修飾しなかった場合、XenCenterは参加しているドメインを使用して、ユーザーをAD認証サーバーにログインさせようとします。この例外はLSUアカウントであり、XenCenterは常に最初にローカル(つまりXenServer上)で認証します。

外部認証プロセスは次のように機能します。

  1. ホストに接続する際に提供される資格情報は、認証のためにActive Directoryドメインコントローラーに渡されます。

  2. ドメインコントローラーは資格情報を確認します。資格情報が無効な場合、認証はすぐに失敗します。

  3. 資格情報が有効な場合、Active Directoryコントローラーにクエリが実行され、資格情報に関連付けられたサブジェクト識別子とグループメンバーシップが取得されます。

  4. 主体識別子がXenServerに保存されているものと一致する場合、認証は成功します。

ドメインに参加すると、プールに対してActive Directory認証が有効になります。ただし、プールがドメインに参加すると、そのドメイン内のユーザー(または信頼関係のあるドメインのユーザー)のみがプールに接続できます。

注:

DHCPで構成されたネットワークPIFのDNS構成を手動で更新することはサポートされておらず、AD統合、ひいてはユーザー認証が失敗したり、機能しなくなったりする可能性があります。

Active Directory認証の構成

XenServerは、Windows Server 2016以降で実行されているActive Directoryサーバーをサポートしています。ドメインコントローラーへの接続を保護するために、Secure LDAP (LDAPS)で説明されているように、LDAPSを構成できます。

XenServerホストのActive Directoryを認証するには、Active Directoryサーバー(相互運用性を許可するように構成されている)とXenServerホストの両方で同じDNSサーバーを使用する必要があります。 一部の構成では、Active Directoryサーバー自体がDNSを提供できます。これは、DHCPを使用してIPアドレスとDNSサーバーのリストをXenServerホストに提供することで実現できます。または、手動で静的構成を使用する場合は、PIFオブジェクトの値を設定するか、インストーラーを使用できます。

ホスト名の割り当てにはDHCPを有効にすることをお勧めします。ホストにlocalhostまたはlinuxというホスト名を割り当てないでください。

警告:

XenServerホスト名は、XenServer展開全体で一意である必要があります。

次の点に注意してください。

  • XenServerは、ホスト名を使用してADデータベース上のADエントリにラベルを付けます。同じホスト名を持つ2つのXenServerホストが同じADドメインに参加している場合、2番目のXenServerが最初のXenServerのADエントリを上書きします。この上書きは、ホストが同じプールに属しているか異なるプールに属しているかに関係なく発生します。これにより、最初のXenServerでのAD認証が機能しなくなる可能性があります。

    異なるADドメインに参加している限り、2つのXenServerホストで同じホスト名を使用できます。

  • 比較されるのはUTC時間であるため、XenServerホストは異なるタイムゾーンに設定できます。同期が正しいことを確認するには、XenServerプールとActive Directoryサーバーで同じNTPサーバーを使用できます。

  • 混合認証プールはサポートされていません。プール内の一部のホストがActive Directoryを使用するように構成され、一部が構成されていないプールを持つことはできません。

  • XenServerのActive Directory統合は、Kerberosプロトコルを使用してActive Directoryサーバーと通信します。そのため、XenServerはKerberosを使用しないActive Directoryサーバーとの通信をサポートしていません。

  • Active Directoryを使用した外部認証を成功させるには、XenServerホストのクロックをActive Directoryサーバーのクロックと同期させる必要があります。XenServerがActive Directoryドメインに参加する際、同期がチェックされ、サーバー間のずれが大きすぎる場合は認証が失敗します。

警告:

ホスト名は純粋な数字であってはなりません。XenServerはホストのNetBIOS名を使用してActive Directoryに登録するため、ホスト名は15文字以内(英数字とハイフンで構成され、ハイフンで開始または終了しない)にする必要があります。

最近のSSHクライアントの制限により、SSHは次の文字のいずれかを含むユーザー名では機能しません: {}[]|&。ユーザー名とActive Directoryサーバー名にこれらの文字が含まれていないことを確認してください。

Active Directory認証を有効にした後でプールにホストを追加すると、プールに参加するホストでActive Directoryを構成するように求められます。参加するホストで資格情報の入力を求められたら、そのドメインにホストを追加するのに十分な権限を持つActive Directory資格情報を入力します。

アクティブディレクトリ統合

XenServerからActive Directoryドメインコントローラーへのアウトバウンド接続のために、以下のポートが開いていることを確認してください。

ポート プロトコル 用途
53 UDP/TCP DNS
88 UDP/TCP ケルベロス 5
123 UDP NTP
135 TCP RPC エンドポイントマッパー
137 UDP NetBIOS ネームサービス
139 TCP NetBIOS セッション (SMB)
389 UDP/TCP LDAP
445 TCP TCP上のSMB
464 UDP/TCP マシンのパスワード変更
636 UDP/TCP SSL経由のLDAP
3268 TCP グローバルカタログ検索
49152-65535 TCP RPC 動的接続

詳細については、XenServer で使用される通信ポートを参照してください。

注:

信頼されたドメインのユーザーがXenServerにログインする必要がある場合、XenServerから信頼されたドメインのドメインコントローラーへの送信接続のために、前述のポートも開いていることを確認してください。

ウィンバインド

XenServerはWinbindを使用して、Active Directory (AD) ユーザーをADサーバーで認証し、ADサーバーとの通信を暗号化します。

Winbindは以下のシナリオをサポートしていません。

  • ドメインユーザー名またはドメイングループ名の先頭または末尾にスペースがある場合。
  • 64文字以上を含むドメインユーザー名。
  • 以下の特殊文字 +<>”=/%@:,;\` を含むドメインユーザー名
  • 以下の特殊文字 ,;\` を含むドメイングループ名

Winbindの構成

以下の構成オプションを使用してWinbindの動作を構成します。これらは/etc/xapi.confファイルに含めることができます。

  • winbind_machine_pwd_timeout: このオプションの値は、このXenServerホストのコンピューターパスワードが何秒ごとにローテーションされるかを定義します。値を整数として定義します。

    デフォルト値は1209600秒(14日)です。新しいパスワードをドメインコントローラー間で同期するのに十分な時間を確保するため、デフォルト値を維持するか、デフォルト値より値を減らさないことをお勧めします。

  • winbind_kerberos_encryption_type: このオプションの値はstronglegacy、およびallです。デフォルト値はallです。

    • allは、次の暗号スイートを許可します: aes256-cts-hmac-sha1-96aes128-cts-hmac-sha1-96、およびarcfour-hmac-md5

    • strongは、次の暗号スイートを許可します: aes256-cts-hmac-sha1-96およびaes128-cts-hmac-sha1-96

    • legacyは、次の暗号スイートを許可します: arcfour-hmac-md5

      レガシーオプションは安全ではないため、問題のデバッグにのみ使用することをお勧めします。

    セキュリティを向上させるため、AES暗号化を強制することをお勧めします。これを行うには、,

    1. ドメインコントローラーがaes256-cts-hmac-sha1-96aes128-cts-hmacsha1-96をサポートしていることを確認します。
    2. ドメインコントローラーを構成して、ドメイン信頼でThe other domain supports Kerberos AES Encryptionを有効にします。

      詳細については、方法3:MicrosoftドキュメントでRC4暗号化の代わりにAES128およびAES 256暗号化をサポートするように信頼を構成するを参照してください。

    3. winbind_kerberos_encryption_typeオプションを更新して、値strongを使用します。
    4. ツールスタックを再起動します。

      HAが有効な間はツールスタックを再起動しないでください。可能であれば、ツールスタックを再起動する前に一時的にHAを無効にしてください。

  • winbind_set_machine_account_kerberos_encryption_type: このオプションの値はtruefalseです。デフォルト値はfalseです。

    • trueは、XenServerホストのActive DirectoryコンピューターオブジェクトでmsDS-SupportedEncryptionTypesstrongに設定します。

    • false は、XenServer ホストの Active Directory コンピューターオブジェクトに msDS-SupportedEncryptionTypes を構成しません。

  • winbind_cache_time: Winbind は一部のドメイン情報をローカルにキャッシュします。このオプションの値は、各キャッシュ更新間の秒数を定義します。デフォルトは 60 秒です。

これらの構成オプションのいずれかを更新した後、ツールスタックを再起動します。

XenServer は AD 統合のコンピューターアカウントパスワードをどのように管理しますか?

Windows クライアントマシンと同様に、Winbind はコンピューターアカウントパスワードを自動的に更新します。Winbind は、14 日ごと、または構成オプション winbind_machine_pwd_timeout で指定されたとおりに、コンピューターアカウントパスワードを自動的に更新します。

プールで外部認証を有効にする

Active Directory を使用した外部認証は、XenCenter または CLI を使用して、次のコマンドで構成できます。

xe pool-enable-external-auth auth-type=AD \
  service-name=fully-qualified-domain \
  config:user=username \
  config:pass=password
<!--NeedCopy-->

指定されたユーザーは Add/remove computer objects or workstations 権限を持っている必要があります。これはドメイン管理者にとってのデフォルトです。

Active Directory と XenServer ホストが使用するネットワークで DHCP を使用していない場合は、次の方法で DNS を設定してください。

  1. 非 FQDN エントリを解決するためのドメイン DNS サフィックス検索順序を設定します。

    xe pif-param-set uuid=pif_uuid_in_the_dns_subnetwork \
       "other-config:domain=suffix1.com suffix2.com suffix3.com"
    <!--NeedCopy-->
    
  2. XenServer ホストで使用する DNS サーバーを構成します。

    xe pif-reconfigure-ip mode=static dns=dnshost ip=ip \
      gateway=gateway netmask=netmask uuid=uuid
    <!--NeedCopy-->
    
  3. 管理インターフェイスを、DNS サーバーと同じネットワーク上にある PIF を使用するように手動で設定します。

    xe host-management-reconfigure pif-uuid=pif_in_the_dns_subnetwork
    <!--NeedCopy-->
    

注:

外部認証はホストごとのプロパティです。ただし、外部認証はプールごとに有効/無効にすることをお勧めします。プールごとの設定により、XenServer は特定のホストで認証を有効にする際に発生する障害に対処できます。XenServer は、必要となる可能性のある変更もロールバックし、プール全体で一貫した構成を保証します。host-param-list コマンドを使用して、ホストのプロパティを検査し、関連フィールドの値をチェックして外部認証のステータスを判断します。

XenCenter を使用して Active Directory 認証を無効にするか、次の xe コマンドを使用します。

xe pool-disable-external-auth
<!--NeedCopy-->

AD認証キャッシュを有効にする

Windows ADインフラストラクチャでは、異なるADサイト間でのレプリケーション中に、ブロック/ブロック解除、パスワード、その他のフィールドなど、ユーザーに関する情報をレプリケートする際に固有の遅延が発生します。これにより、特にグローバルなAD展開で大規模に運用する場合、AD認証に非常に長い時間がかかることがあります。認証キャッシュを有効にすると、システムは認証決定を限られた時間記憶できるため、外部のActive Directory (AD) 認証が遅い場合にログインを高速化するのに役立ちます。この機能はデフォルトで無効になっています。

AD認証キャッシュを有効にするには:

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-enabled=true
<!--NeedCopy-->

デフォルトでは、認証決定は300秒間記憶されます。これは調整できます。

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-expiry=<seconds>
<!--NeedCopy-->

AD認証キャッシュを無効にするには:

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-enabled=false
<!--NeedCopy-->

セキュアLDAP (LDAPS)

デフォルトでは、XenServerはLDAPトラフィックに署名して封印することにより、Active Directoryドメインコントローラーへの接続を保護します。さらに、このトラフィックをLDAPS (SSL/TLS経由のLDAP、ポート636) で保護することもできます。これは、ディレクトリトラフィックをTLSトンネルでラップします。XenServerは、プールにインポートした信頼されたCA証明書に対してトンネルを検証します。

注:

XenServerは、インポートされたCA証明書に対してのみドメインコントローラー証明書チェーンを検証します。リーフ証明書または自己署名証明書(CAではない)はLDAPSではサポートされていません。LDAPSを有効にする前に、少なくとも1つのCA証明書をインポートする必要があります。そうしないと、外部認証の有効化は失敗します。

CA証明書を準備する

ドメインコントローラーでLDAPSを有効にする必要があり、ドメインコントローラーの証明書に署名したCA証明書を提供する必要があります。証明書を準備するには、以下のMicrosoftドキュメントを参照してください。

CA証明書をインポートする

LDAPS 用にドメインコントローラーのサーバー証明書に署名した CA 証明書を、LDAPS 用にタグ付けしてインポートします。

xe pool-install-trusted-certificate uuid=<pool-uuid> purpose=ldaps ca=true filename=<path-to-ca.pem>
<!--NeedCopy-->

ここで、:

  • purpose=ldaps は、証明書を LDAPS 用にタグ付けします。
  • ca=true は、これがピン留めされたリーフ証明書ではなく、チェーンを検証する CA 証明書であることを示します。
  • filename は、xe コマンドを実行するマシン上の、PEM 形式の CA 証明書へのパスです。

ドメインコントローラーの証明書が中間 CA を介して発行された場合は、代わりに中間 CA をインポートします(ルート証明書はあれば便利です)。

LDAPS の有効化または無効化

外部認証を有効にする際に LDAPS を有効にするには、pool-enable-external-auth コマンドに config:ldaps=true を追加します。

xe pool-enable-external-auth auth-type=AD \
  service-name=fully-qualified-domain \
  config:user=username \
  config:pass=password \
  config:ldaps=true
<!--NeedCopy-->

既にドメインに参加しているプールで LDAPS をオンまたはオフにするには、pool-external-auth-set-ldaps コマンドを使用します。

xe pool-external-auth-set-ldaps uuid=<pool-uuid> ldaps=true
<!--NeedCopy-->
xe pool-external-auth-set-ldaps uuid=<pool-uuid> ldaps=false
<!--NeedCopy-->

この変更はプール内のすべてのホストに適用され、ドメインに対して検証されます。失敗した場合、変更はすべてのホストで自動的にロールバックされます。

LDAPS 用にタグ付けされた証明書を一覧表示するには:

xe certificate-list purpose=ldaps
<!--NeedCopy-->

複数のドメインコントローラーで 1 つの CA チェーンを使用する

プールが LDAPS 経由で認証する場合、XenServer はドメイン内の任意のドメインコントローラーに接続でき、使用するドメインコントローラーは操作によって異なる場合があります。各ドメインコントローラーは LDAPS 用に独自のサーバー証明書を提示し、XenServer はそれをインポートした CA 証明書に対して検証します。インポートしていない CA によってドメインコントローラーの証明書が署名されている場合、XenServer は断続的な障害に遭遇する可能性があります。

次の推奨事項に従ってください。

  • すべてのドメインコントローラーの LDAPS 用サーバー証明書を同じルート CA から発行し、purpose=ldaps を信頼された証明書としてルート証明書を XenServer にインポートします。
  • 環境で、異なるCAによって署名された参加ドメインと信頼済みドメインを使用している場合は、それらのすべてのドメインのCA証明書をすべてインポートします。

ユーザー認証

ユーザーがXenServerホストにアクセスできるようにするには、そのユーザーまたはユーザーが属するグループのサブジェクトを追加する必要があります。(推移的なグループメンバーシップも通常の方法でチェックされます。たとえば、グループAのサブジェクトを追加し、グループAがグループBを含み、user 1がグループBのメンバーである場合、user 1へのアクセスが許可されます。) Active Directoryでユーザー権限を管理したい場合は、単一のグループを作成し、そのグループにユーザーを追加したり削除したりできます。あるいは、XenServerから個々のユーザーを追加したり削除したり、または認証要件に応じてユーザーとグループを組み合わせて管理することもできます。サブジェクトリストは、XenCenterから、または次のセクションで説明するようにCLIを使用して管理できます。

ユーザーを認証する際、資格情報は最初にローカルのrootアカウントに対してチェックされ、これによりADサーバーが故障したシステムを回復できます。資格情報(ユーザー名とパスワード)が一致しない場合、ADサーバーに認証要求が行われます。認証が成功した場合、ユーザーの情報が取得され、ローカルのサブジェクトリストに対して検証されます。認証が失敗した場合、アクセスは拒否されます。サブジェクトリストに対する検証は、ユーザーまたはユーザーの推移的なグループメンバーシップ内のグループがサブジェクトリストに含まれている場合に成功します。

注:

ホストSSHアクセスを必要とするプール管理者ユーザーにアクセス権を付与するためにActive Directoryグループを使用する場合、ADグループのサイズは500ユーザーを超えてはなりません。

XenServerにADサブジェクトを追加するには:

xe subject-add subject-name=entity_name
<!--NeedCopy-->

entity_nameは、アクセスを許可したいユーザーまたはグループの名前です。エンティティのドメインを含めることができます(例: ‘user1’ではなく’xendt\user1’)。ただし、曖昧さの解消が必要な場合を除き、動作は同じです。

ユーザーのサブジェクト識別子を見つけます。識別子は、ユーザーまたはユーザーを含むグループです。グループを削除すると、そのグループ内のすべてのユーザーへのアクセスが削除されます。ただし、そのユーザーがサブジェクトリストにも指定されていない場合に限ります。ユーザーのサブジェクト識別子を見つけるには、subject listコマンドを使用します。:

xe subject-list
<!--NeedCopy-->

このコマンドは、すべてのユーザーのリストを返します。

リストにフィルターを適用するには、たとえば、testadドメイン内のユーザーuser1のサブジェクト識別子を見つけるには、次のコマンドを使用します:

xe subject-list other-config:subject-name='testad\user1'
<!--NeedCopy-->

前のステップで取得したサブジェクト識別子を渡して、subject-removeコマンドを使用してユーザーを削除します:

xe subject-remove subject-uuid=subject_uuid
<!--NeedCopy-->

このユーザーがすでに認証している現在のセッションを終了できます。詳細については、次のセクションの「xeを使用したすべての認証済みセッションの終了」および「xeを使用した個々のユーザーセッションの終了」を参照してください。セッションを終了しない場合、権限を取り消されたユーザーは、ログアウトするまでシステムにアクセスし続ける可能性があります。

XenServerホストまたはプールにアクセスする権限を持つユーザーとグループのリストを特定するには、次のコマンドを実行します:

xe subject-list
<!--NeedCopy-->

ユーザーのアクセス権を削除する

ユーザーが認証されると、セッションを終了するか、別のユーザーがセッションを終了するまでホストにアクセスできます。サブジェクトリストからユーザーを削除したり、サブジェクトリスト内のグループからユーザーを削除したりしても、そのユーザーがすでに認証済みのセッションが自動的に取り消されることはありません。ユーザーは、XenCenterまたはすでに作成した他のAPIセッションを使用してプールにアクセスし続けることができます。XenCenterとCLIは、個々のセッション、またはすべてのアクティブなセッションを強制的に終了する機能を提供します。XenCenterを使用した手順については、XenCenterドキュメントを参照してください。CLIを使用した手順については、次のセクションを参照してください。

「xe」を使用してすべての認証済みセッションを終了する

「xe」を使用してすべての認証済みセッションを終了するには、次のCLIコマンドを実行します。

xe session-subject-identifier-logout-all
<!--NeedCopy-->

「xe」を使用して個々のユーザーセッションを終了する

  1. ログアウトしたいセッションのサブジェクト識別子を特定します。サブジェクト識別子を見つけるには、session-subject-identifier-listまたはsubject-listのxeコマンドを使用します。最初のコマンドはセッションを持つユーザーを表示します。2番目のコマンドはすべてのユーザーを表示しますが、フィルタリングできます。たとえば、xe subject-list other-config:subject-name=xendt\\user1のようなコマンドを使用します(シェルによっては、示されているように二重のバックスラッシュが必要になる場合があります)。

  2. たとえば、前の手順で特定したサブジェクト識別子をパラメーターとして渡して、session-subject-logoutコマンドを使用します。

    xe session-subject-identifier-logout subject-identifier=subject_id
    <!--NeedCopy-->
    

ADドメインから離脱する

警告:

ドメインから離脱すると、Active Directoryの資格情報でプールまたはホストに認証されたすべてのユーザーは切断されます。

XenCenterを使用してADドメインから離脱します。詳細については、XenCenterドキュメントを参照してください。または、必要に応じてプールUUIDを指定してpool-disable-external-authコマンドを実行します。

注:

ドメインから離脱しても、ADデータベースからホストオブジェクトは削除されません。無効になったホストエントリを検出して削除する方法については、Active Directoryのドキュメントを参照してください。

ユーザー管理