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)で説明されているように、[セキュアLDAP (LDAPS)]を構成できます。

注:

XenServer 9は、RC4_HMAC_MD5、DES_CBC_MD5、DES_CBC_CRCなどのレガシーAD暗号スイートをサポートしていません。ADサーバーがAES128_HMAC_SHA1またはAES256_HMAC_SHA1の少なくともいずれかをサポートしていることを確認する必要があります。

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ホストで同じホスト名を使用できます。

  • XenServerホストは異なるタイムゾーンに存在できます。比較されるのはUTC時間であるためです。同期が正しく行われるように、XenServerプールとActive Directoryサーバーで同じNTPサーバーを使用できます。

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

  • XenServerのActive Directory統合は、Active Directoryサーバーとの通信にKerberosプロトコルを使用します。したがって、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は、Active Directory(AD)ユーザーをADサーバーで認証し、ADサーバーとの通信を暗号化するためにWinbindを使用します。

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

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

Winbindの構成

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

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

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

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

    • 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. ドメイン信頼で、他のドメインはKerberos AES暗号化をサポートしていますを有効にするようにドメインコントローラーを構成します。

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

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

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

    注記:

    Windows Server 2016では、msDS-SupportedEncryptionTypes属性はデフォルトでRC4のみに設定されています。既存のすべてのユーザーにAES暗号化タイプを設定し、ドメインコントローラーがKerberos AESキーを再生成するようにパスワードをリセットしてください。

  • 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または以下のxeコマンドを使用して、Active Directory認証を無効にします。

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用にタグ付けされた、LDAPS用ドメインコントローラーのサーバー証明書に署名したCA証明書をインポートします。

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を使用して管理できます。

ユーザーを認証する際、まず資格情報がローカルのルートアカウントに対してチェックされ、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 資格情報でプールまたはホストに認証したすべてのユーザーが切断されます。

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

注:

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

ユーザーの管理