ユーザー管理

Control Hub の基礎となる一元化されたユーザー管理システムがあります。ここで、ユーザーは組織全体 (およびすべての Webex) 内で区別され固有です。 サイト管理では、ユーザー プロファイルがミーティング サイトごとに異なります。

自動アカウント作成でのシングル サインオン (SSO)

サイト管理では、SSO により認証するときにユーザーを作成する「自動アカウント作成」機能があります。

新しいユーザーを追加するためのより強固な方法が用意されているため、この機能は Control Hub では利用できません。 サイトから Control Hub に更新する前に、[サイトの管理] でこの機能を無効にする必要があります。

SSO を使用する多くの組織は、Microsoft^® Active Directory および Microsoft Azure などの外部ディレクトリ ツールでユーザーを一元的に管理し、外部 ID プロバイダーとの認証を必要とすることを希望する場合があります。

詳細:

• Control Hub にユーザーを追加する: https://help.webex.com/mj2cls/

• Control Hub 組織を ID プロバイダーに統合する: https://help.webex.com/lfu88u/

必須のプロファイル データとトラッキング コード

サイト管理では、新規ユーザーに必要なプロファイル フィールドを指定することができます (前のスクリーンショット)。 これを拡張してユーザー作成のためのトラッキング コードを要求することができます (下のスクリーンショット)。 これらの追加要件を構成する場合、これらを使用せずユーザーをサイトに追加することはできません。

Control Hub では、ユーザーを作成するのに必要なのは表示名とメール アドレスのみです。

Control Hub で新しいユーザーを作成する際には、他のすべてのユーザー フィールドはオプションであるため、Control Hub への追加のプロファイル データ提供は強制されません。

サイトを Control Hub に更新する前に、必須のプロファイル フィールドとトラッキング コードを無効にする必要があります。

パスワード管理とロックアウト

サイト管理には、何回か試行した後にサインインに失敗した場合に、ユーザーを一時的にロックする機能があります。

Control Hub には以下のオプションがあり、不正アクセスを防ぎます。

• 最初の数回の試行失敗後に自動タイムアウト。

• CAPCHA メカニズム（(コンピューターと人間を区別するための完全に自動化されたパブリック チューリング テスト)。

• 正当なユーザーには、忘れてしまったパスワードを変更するセルフサービスのオプションがあります。

主催者のライセンス

主催者は Control Hub 組織に所属している必要があります

サイト管理で、任意のユーザーにホスト ライセンスを割り当てできます。 Control Hub のサイトを管理する場合、同じ Control Hub 組織のユーザーに対して、主催者ライセンス (および出席者の役割) のみを割り当てすることができます。

主催者アカウントにセルフ サインアップする

サイト管理で、ユーザーがサイト上で (主催者) アカウントを要求できるよう許可することができます。 アカウントを持つユーザーがサイト上で追加サービスを要求することもできます。(スクリーンショットを参照)。

Control Hub でミーティング サイトを管理している場合、ユーザーはサイトに対して自分の主催者アカウントを要求できません。

Control Hub には、新しいユーザーにミーティング ライセンスを割り当てる一元化された自動的な方法があります。 https://help.webex.com/n3ijtao を参照してください。

API または CSV を使用して一括でユーザー ライセンスを管理することもできます。

ユーザーが彼らの主催者アカウントを要求する場合、ポインタを使ってサイトのヘルプ/サポートを構成し、管理者に連絡したり、他のツールにリンクしたりします。

サイトから Control Hub に更新する前に、[サイトの管理] で [主催者アカウントのサインアップ許可] および [ユーザーに付加サービスの要求を許可] を無効にする必要があります。

Control Hub には、自動割り当てテンプレートなど、他のライセンス管理オプションがあります。 非アクティブな主催者のレポートを取得して、個々に、または一括で、または API で、これらのユーザーからライセンスを削除するのに役立ちます。

この自動非アクティブ化オプションは必要でも、Control Hub の他のオプションが不適当な場合は、現時点でサイトを Control Hub に更新することは避けてください。

新規ユーザーのアカウント自動生成

Webexサイトでサイト管理での自動アカウント作成が有効な場合、次を使用して Control Hub で同様の機能を有効にすることができますSAML自動アカウント作成を選択します。 また、会議室のセットアップする自動ライセンステンプレートControl Hub 組織でアカウントが作成されると、新規ユーザーに自動的にライセンスが割り当てられます。

ディレクトリ同期を持つ組織

組織がディレクトリ同期に構成されている場合、組織内に所属させるすべてのユーザーがサイトに存在するようにします。 サイトの更新プロセスを開始する 24 時間前に実行する必要があります。これにより、サイトのユーザーは Control Hub 組織の新しいユーザーにリンクすることができます。

サイトのアクティブ ユーザーが Control Hub ユーザーにリンクできない場合、更新は失敗します。

XML API

XML API は Control Hub 管理対象サイトと互換性があります。 XML API 41.11.0 Updates で詳細と問題についてお読みください。

XML APIサービス URL は、サイトがサイト管理から Control Hub 管理に更新された後も変更されません。 同じAPI URL は引き続き機能します。 すべてのAPI統合で認証にCiscoを使用することを推奨します。

XML API での認証

インテグレーションは、認証用のWebex OAUTHサイトが Control Hub に更新された後に失敗します。 次の表は、サイト更新後に機能する管理者認証のタイプを示します。

表 1. サイト更新後にXML APIで機能する管理認証の種類

サイト更新前のXML APIの管理者認証の種類	サイト更新後のSSO組織の管理者	サイトの更新後、管理者がSSO組織にいない
ユーザー名 (webExID)/パスワード	問題ありません*	問題ありません*
ユーザ名 (webExID)/sessionTicket	動作します	動作します
ユーザー名/OAUTH (webExAccessToken)	動作します	動作します
メール/パスワード	問題ありません*	問題ありません*
メール/セッションチケット	動作します	動作します
メール/OAUTH (webExAccessToken)	動作します	動作します

* 下位互換性— サイト更新後、非XML組織のみでユーザー名がメールと一致しない場合でも、 Ciscoはユーザー名/パスワード認証を有効にしSSOた。 互換性は、次の場合にのみ適用されます。 ユーザー資格情報はサイトの更新前に作成されました。 ユーザー名の変更は許可されません。さもないと以前の資格情報が使用できなくなります。 API認証の資格情報は、 [サイトの管理] で管理された場合、Control Hub とサイトで異なるパスワードを持つことはできません。 OAUTH 認証など、Control Hub 管理対象サイトでのXML APIインテグレーションの詳細については、このガイドを選択します。

サイトが Control Hub に更新されると、ユーザー名はすべてのユーザーのメールに設定されます。 ユーザー名がAPIペイロードに使用される場合、サイトが更新された後、ペイロードは代わりにメールを使用する必要があります。

APIインテグレーションのための Control Hub の管理者ロール

サイト管理者のロールだけを持つ管理者は、 XML API を使用した一部の操作を行うことができません。たとえば、サイトが Control Hub サイトに更新された後のユーザーのメール アドレスか表示名を変更するなどです。 資格情報がAPIインテグレーションに使用されている管理者の場合、できればサイトを Control Hub に更新する前に、Control Hub で組織のフル管理者に昇格することをお勧めします。

ベスト プラクティスとして、Control Hub に更新した後で API インテグレーションが変更されていないことを確認するために、まずテスト サイトを更新することをお勧めします。

インテグレーションの内容によっては、管理者はインテグレーションが機能するために Control Hub サイトの Meetings主催者アカウントを割り当てられる必要がある場合もあります (これはサイト管理サイトの管理者には必要ではありませんでした)。

も追加します ( SSOセクションには含まれません)。

サイトが CH に変換されたときに、ユーザー名はすべてのユーザーのメールに設定されます。

したがって、ユーザー名がAPIペイロードの場合、サイトが変換された後にユーザーのメールを入力する必要があります。

Control Hub でのXML APIの違い

ほとんどの XML API 統合は、サイト更新後に変更を加えなくても機能します。 ただし、以下のリストに示すように、一部の例外があります。

• ユーザーの作成—Control Hub 管理対象サイトでは、この操作により、ライセンスを割り当てる前にサイト所有組織にもユーザーが作成される場合があります。 ユーザーがすでに別の組織に存在する場合、この操作は失敗します。 PMR ID parameter パーソナル会議室の アクティブステータスを共有します。

  createuser APIは、Control Hub 管理サイトで完了するのに時間がかかります。 パフォーマンスを向上させるため、 createuser がコールします。

• 設定ユーザー- ミーティング サイトのライセンスをユーザーから割り当てまたは削除した結果 ( APIパラメーターまたはペイロードに応じて)。
• Delユーザー—ミーティングサイトのライセンスを削除しますが、Control Hub 組織からユーザーは削除されません。
• LstsummaryUser —また、ユーザーの objectGUID です。
• 認証ユーザ—Control Hub 管理対象サイトでは、以下の方法でセッション チケットを作成することをお勧めします。 AuthenticateUser 各XML APIに対してユーザー名とパスワードを使用するのではなく、 Control Hub が管理するサイトに対するこの通話では、本文のコンテンツでのSAML応答の使用はサポートされていません。

REST API

Control Hub には、ユーザーを作成したり、ライセンスを供与したりするためのユーザー API や License REST API など独自の API があり、次の場所からアクセスできます。

• developer.webex.com

• developer.webex.com

セッション タイプとトラッキングコードは、次の REST API でも入手できます。

• developer.webex.com
• developer.webex.com

ただし、上記の REST API は、 XML API で使用できるすべてのユーザー管理機能をサポートしているわけではありません。 たとえば、サイトを所有する組織の外部のユーザーにミーティングライセンスを割り当てるには、 XML API を使用する必要があります。 People APIは、サイト管理の役割の割り当てユーザーに割り当てる場合。 APIを介してサイト管理者のロールを割り当てる場合は、引き続きXML APIを使用する必要があります。

ユーザーAPIを使用して、フル (または読み取り専用) 権限を持つ組織管理者を作成することができます。これらの管理者は、Control Hub で管理されるミーティングサイトを管理 (または表示) することができます。

Control Hub には Webex サイト固有の管理者ロールがありますが、ユーザー API では現在このロールを割り当てることはできません。

今後のプラン（変更の可能性あり）

• サイトを作成した組織と同じ組織にいない外部ユーザーにもミーティングサイトのライセンスを付与できる新しいライセンスAPI 。 外部ユーザー ライセンスを手動で使用できます共有する方法を説明します
• SCIM APIを使用して、組織のユーザーを作成および削除します。
• Cisco は長期的には REST API のみを使用することです (ユーザーとミーティングサイトでのすべての操作に対して)。 ユーザー管理用のXML API は、REST API がすべてのユーザー管理操作に排他的に使用できるようになるまで、引き続きサポートされます。 ユーザー管理XML API も廃止されます（日付 TBD）。

サイトの更新をブロックするユーザーがいないか確認する方法

1. ログインし、[サイト管理更新] ページ を開 きます。

2. [管理を更新するための前提条件を確認する] コントロールを開き、[影響を受けるユーザーをCSV でエクスポートする] をクリックします。

3. エクスポートが完了するのを待ちます。 開始時刻とサイト内のユーザー数によっては、このプロセスに時間がかかる場合があります。 エクスポートは正時には 6 分間一時停止されます（xx:57 ～ xx:03 の間）。

4. エクスポートが完了したら [CSV のダウンロード] をクリックします。

   ブラウザが以下をダウンロードします: users-to-review.csv です。

5. CSV ファイルを開き、[推奨されるアクション] 列 (最後の列) を確認します。 ファイル内の各ユーザーに対し、推奨されるアクションを実行します。

一致しないメール アドレスを持つユーザー

一部のユーザーは、サイト管理と Control Hub でメール アドレスが異なります。 これは、ユーザーがこのサイトから Control Hub にリンクされた後で、ユーザーのメールが 2 つの場所のうち 1 つでのみ変更された場合に可能です。

これらのアクションを試して、電子メール アドレスが一致しないユーザーを修正します。

• サイト管理のユーザーのメール アドレスを変更して、Control Hub メール アドレスに一致させる

  ユーザーはサイト管理者のプロファイルを編集することができます。 https://help.webex.com/nmi58lk/

• Control Hub のユーザーのメール アドレスを変更して、サイト管理メール アドレスに一致させる: https://help.webex.com/njpf8r5

  ユーザーは Control Hub 組織で自分のメール アドレスを変更できます。 https://help.webex.com/nmdp0hq/

ユーザーのメール アドレスの不一致を修正しないまま、サイトを Control Hub に更新した場合、影響を受けるユーザーは Control Hub のメール アドレスを使用してミーティングサイトにサインインする必要があります。 これらのユーザーは、サイト管理のメール アドレスでサインインしようとした場合、または Control Hub のメール アドレスが IdP で有効でなくなった場合 ( SSO組織の場合)、サインインできない場合があります。 彼らはサイトの更新をブロックしませんが、更新を開始する前にメール アドレスを修正することをお勧めします。

Basic Meetings ライセンスを持つ外部ユーザー

権限を持つ外部ユーザーBasic Meetings ライセンスサイトをサイト管理から Control Hub に更新する前に、無効化するか、有料の Webex Meetingsライセンスにアップグレードする必要があります。

ユーザーを非アクティブにする方法

ユーザーを非アクティブ化すると、彼らは主催者ライセンスまたは出席者権限を失います (アクティブの間、どの役割があったかによって異なる)。 非アクティブ化されたユーザーは、サイトを Control Hub に更新した後でも、サイトの CSV エクスポート ファイルに表示されます。

サイト管理での個別ユーザーの非アクティブ化:

1. [ユーザー管理] > [ユーザーの>編集] にアクセスします。

2. インデックス、検索、フィルター管理を使ってユーザーを探します。

3. [アクティブ] ボックスのチェックを 外します。

4. 変更 を提出します。

   参照先Webexサイトの管理するをご覧ください。

サイト管理でのバッチ ユーザーの非アクティブ化:

1. ユーザーを CSV ファイルにエクスポートします。

2. CSV ファイルを開き、 Active すべての影響を受けるユーザーの N 行の値を変更します。

3. 変更された CSV ファイルをインポートします。

   変更されたユーザーは非アクティブになりました。

   詳細については、「Webex サイト管理で Webex ユーザーをバッチインポートまたはエクスポートする」を参照します。

ディレクトリの同期を持つ組織のユーザー

組織内にリストされているはずの、まだ追加されていないユーザーがリンクされていない場合、まず組織にユーザーを追加する必要があります。 これは、ディレクトリ同期 (ディレクトリ コネクタ または Azure AD を通じて) に構成されている組織にとって特に重要です。ディレクトリ同期によってサイトの更新プロセスがユーザーを追加できないためです。

サイトのアクティブ ユーザーが Control Hub 組織にリンクできない場合、サイトの更新は失敗します。 組織がディレクトリ同期に構成されている場合は、Control Hub 組織の一部である必要があるサイト上のすべてのユーザーが、更新を開始する前に、ディレクトリ コネクタ または Azure AD に追加されていることを確認してください。

アップデートを開始する前にユーザーの問題を解決する

サイトのユーザーの問題を解決せずに、Control Hub にサイトを更新しようとした場合 users-to-review ファイルがあれば、更新管理プロセスが失敗する可能性があります。 最終更新が開始されるまで、ツールでは問題が修正済みどうか確認されません。