この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco Jabber は Jabber ID を使用して、連絡先ソース内の連絡先情報を識別します。
デフォルトの Jabber ID は、ユーザ ID とプレゼンス ドメインを使用して作成されます。
たとえば、Adam McKenzie が amckenzie というユーザ ID を持っており、そのドメインが example.com である場合、Jabber ID は amckenzie@example.com となります。
大文字 (A Z から)
小文字 (、z)
数字(0 ~ 9)
ピリオド(.)
ハイフン(-)
アンダースコア(_)
チルダ(~)
連絡先リストに入力する場合、クライアントは Jabber ID を使用して連絡先ソースを検索し、連絡先を解決して、名、姓、その他の連絡先情報を表示します。
Cisco Jabber 10.6 以降は、example-us.com や example-uk.com のユーザのようにドメインが同じプレゼンス アーキテクチャ上に存在する場合は、オンプレミス展開用の複数のプレゼンス ドメイン アーキテクチャ モデルをサポートします。Cisco Jabber は Cisco Unified Communications Manager IM and Presence 10.x 以降を使用して柔軟な IM アドレス スキームをサポートします。IM アドレス スキームは Cisco Jabber ユーザを識別する Jabber ID です。
User ID フィールドは LDAP フィールドにマップされます。これがデフォルトの IM アドレス スキームです。
たとえば、ユーザの Anita Perez は、アカウント名が aperez で、User ID フィールドが sAMAccountName LDAP フィールドにマップされます。使用されるアドレス スキームは aperez@example.com です。
ディレクトリ URI は、mail または msRTCSIP-primaryuseraddress LDAP フィールドにマップされます。このオプションは、認証用のユーザ ID に依存しないスキームを提供します。
たとえば、ユーザの Anita Perez は、アカウント名が aperez で、mail フィールドが Anita.Perez@domain.com で、使用されるアドレス スキームが Anita.Perez@domain.com です。
SIP URI は各ユーザに関連付けられます。SIP URI には、電子メール アドレス、IMAddress、または UPN を使用できます。
ユーザは、SIP URI を入力して、連絡先を検索したり連絡先に電話をかけることができます。
ディレクトリ ソースから Cisco Unified Communications Manager にユーザを同期させる場合は、ディレクトリ内の属性からユーザ ID を入力できます。ユーザ ID を保持するデフォルトの属性は、sAMAccountName です。
フェデレーションでは、連絡先の検索中に連絡先を解決するため、Cisco Jabber はそれぞれの連絡先に対して連絡先 ID またはユーザ ID を必要とします。
jabber-config.xml ファイルで、SipUri パラメータ内のユーザ ID の属性を設定します。デフォルト値は msRTCSIP-PrimaryUserAddress です。ユーザ ID から削除するプレフィクスがある場合は、UriPrefix パラメータの値を設定できます。
Cisco Jabber は写真サーバにアクセスして、連絡先の写真を取得します。ネットワーク設定に Web プロキシが含まれている場合は、Cisco Jabber が写真サーバにアクセスできることを確認する必要があります。
ディレクトリ サーバを使用して認証するには、Cisco Unified Communications Manager に LDAP 認証を設定します。
ユーザがクライアントにサインインすると、プレゼンス サーバがその認証を Cisco Unified Communications Manager にルーティングします。次に、Cisco Unified Communications Manager がその認証をディレクトリ サーバにプロキシします。
Cisco WebEx Messenger の認証は、Cisco WebEx 管理ツールを使用して設定します。
ユーザがクライアントにサインインすると、その情報が Cisco WebEx Messenger に送信され、認証トークンがクライアントに返送されます。
シングル サインオン認証は、アイデンティティ プロバイダー(IdP)とサービスを使用して設定されます。
ユーザがクライアントにサインインすると、その情報が IdP に送信され、クレデンシャルが承認されると、認証トークンが Cisco Jabber に返送されます。
Cisco Jabber は、クライアント証明書により IdP サーバで認証されます。この証明書認証により、ユーザ クレデンシャルを入力せずにサーバにサインインできます。クライアントは Safari フレームワークを使用してこの機能を実装します。
Cisco Unified Communications Manager 11.5、IM and Presence Service 11.5、Cisco Unity Connection 11.5 以降。
Expressway for Mobile and Remote Access サーバ 8.9 以降。
ユニファイド コミュニケーション インフラストラクチャに対し SSO が有効。
Cisco Unified Communications Manager、IM およびプレゼンス サービス、Cisco Unity Connection、IdP サーバを含むすべてのサーバ証明書が CA による署名を持つ。iOS デバイスが OS の信頼認証局を使用する場合、Cisco Jabber アプリをインストールする前に CA 証明書をインストールします。
Cisco Unified Communications Manager で SSO のネイティブ ブラウザ(Safari に付属)を設定します。詳細については、『On-Premises Deployment for Cisco Jabber 11.7』の「Certificate-Based SSO Authentication for Mobile Clients」のトピックを参照してください。
Expressway for Mobile and Remote Access サーバで SSO のネイティブ ブラウザ(Safari に付属)を設定します。詳細については、『 Installation guides for Cisco Expressway 8.9』を参照してください。
Cisco 証明書は、EMM ソリューションを用いて iOS デバイスに導入できます。
推奨 - iOS デバイスへの証明書の展開には EMM ソリューションの使用をお勧めします。
Cisco Jabber は、シングル サインオン サーバへのサインインにクライアント証明書を使用します(WebEx Messenger と社内)。
Android デバイスでの証明書の展開には EMM ソリューションの使用をお勧めします。
ユーザは Cisco Unity Connection に存在している必要があります。Cisco Unity Connection は、複数の認証タイプをサポートします。Cisco Unified Communications Manager と Cisco Unity Connection が同じ認証を使用している場合、Cisco Jabber は同じクレデンシャルを使用するように設定することをお勧めします。
Cisco Jabber は、ユーザのアクセス権限の承認に OAuth を使用します。ユーザが OAuth 対応環境にサインインする場合、サインインのたびにクレデンシャルを入力する必要がありません。ただし、サーバが OAuth に対応していない場合は、Jabber が適切に機能しないことがあります。
サーバをこれらのバージョンにアップグレードすると、Cisco Unified Communications Manager、Cisco Expressway、および Cisco Unity Connection で OAuth の有効と無効を切り替えることができます。
デフォルトでは、OAuth はこれらのサーバ上で無効です。これらのサーバで OAuth を有効にするには、次の操作を実行します。
上記のサーバの OAuth の有効と無効を切り替えると、Jabber は設定の再取得間隔でこの切り替えを識別するため、ユーザは Jabber のサインアウトとサインインできます。
サインアウト中、Jabber はキャッシュ内に保存されているユーザ クレデンシャルを削除して通常のサインフローでサインインします。この場合、Jabber は最初にすべての設定情報を取得するため、ユーザは Jabber サービスにアクセスできます。
次の表に、Jabber が OAuth を使用してユーザ アクセス権限を認証するシナリオを示します。
Cisco Expressway |
Cisco Unified Communication Manager |
Cisco Unified Communication Manager Instant Messaging and Presence |
Cisco Unity Connection |
Jabber サインイン フロー |
---|---|---|---|---|
OAuth をサポート |
OAuth をサポート |
OAuth をサポート |
OAuth をサポート |
OAuth がユーザ認証に使用されます。 |
OAuth をサポート |
OAuth をサポート |
OAuth をサポート |
OAuth を非サポート |
Jabber はこの環境をサポートしていません。 |
OAuth をサポート |
OAuth をサポート |
OAuth を非サポート |
任意のモードで可能 |
Jabber はこの環境をサポートしていません。 |
OAuth を非サポート |
OAuth をサポート |
任意のモードで可能 |
任意のモードで可能 |
Jabber はこの環境をサポートしていません。 |
OAuth を非サポート |
OAuth を非サポート |
任意のモードで可能 |
OAuth をサポート |
OAuth はユーザ認証に使用されません。 |
OAuth をサポート |
OAuth を非サポート |
任意のモードで可能 |
任意のモードで可能 |
Expressway サーバで [内部認証可能性の確認(Check for internal authentication availability)] を選択します。 Expressway-C で、 に移動します。Jabber は OAuth フローを使用せずにこの展開をサポートします。 すべてのサーバが OAuth にアップグレードされたら、[内部認証可能性の確認(Check for internal authentication availability)] をオフにして、外部ネットワークのユーザ ID または電子メールの探索を禁止します。 |
Cisco コラボレーション クラウド |
Cisco Expressway、Cisco Unified Communication Manager、および Cisco Unity Connection |
Jabber サインイン フロー |
---|---|---|
SSO は有効 |
OAuth をサポートし、SSO を有効です |
SSO 認証は WebEx に使用されます。OAuth 認証は他のサービスに使用されます。 |
SSO は有効 |
OAuth をサポートし、モードは SSO 以外です |
SSO 認証は WebEx に使用されます。ユーザ名とパスワードの認証は他のサービスに使用されます。 |
SSO は無効 |
OAuth をサポート |
ユーザ名とパスワードの認証はすべてのサービスに使用されます。 |
に移動します。
[O-Authローカル認証(O-Auth local authentication)] を [オン(On)] に設定します。
[AuthZサーバ(AuthZ Servers)] に移動して [新規追加(Add New)] を選択します。
すべてのフィールドに詳細を入力して、[証明書エラーを無視する(Ignore Certificate Errors)] を選択します。
[保存(Save)] をクリックします。
Jabber が自動侵入防御をトリガーする
状況:
MRA ソリューションは、OAuth トークンによる承認用に設定されています(更新トークンの有無にかかわらず)
Jabber ユーザのアクセス トークンの有効期限が切れています
Jabber は次のいずれかを行います。
デスクトップの休止状態からの再開
ネットワーク接続の回復
数時間サインアウトした後、高速サインインの試行
動作:
いくつかの Jabber モジュールが、期限切れのアクセス トークンを使用して Expressway-E で認証を試行します。
Expressway-E がこれらの要求を(正しく)拒否します。
特定の Jabber クライアントからの要求が 6 つ以上ある場合、Expressway-E はその IP アドレスを(デフォルトで)10 分間ブロックします。
症状:
影響を受ける Jabber クライアントの IP アドレスは、HTTP プロキシの認証の失敗カテゴリにある Expressway-E のブロックされたアドレス リストに追加されます。このアドレスは、
で確認できます。回避策:
この問題を回避するには 2 つの方法があります。つまり、その特定のカテゴリの検出しきい値を上げるか、または影響を受けるクライアントに対して免除を作成できます。免除は実際の環境では実用的でない可能性があるため、ここではしきい値オプションについて説明します。
[HTTPプロキシの認証の失敗(HTTP proxy authorization failure)] をクリックします。
[トリガーレベル(Trigger level)] を 5 ~ 10 に変更します。期限が切れたトークンを提示する Jabber モジュールを容認するには 10 で十分です。
設定を保存すると、すぐに有効になります。
影響を受けるクライアントのブロックを解除します。
オンプレミス展開:Cisco Unified Communications Manager IM and Presence サービス。
クラウド展開:Cisco WebEx。
2 人のユーザ間で新しい IM セッションが開始されると、最初の着信メッセージが受信ユーザのすべての登録済みクライアントにブロードキャストされます。
その後で、IM and Presence サービス ノードが登録済みクライアントのいずれかからの最初の応答を待機します。
最初に応答したクライアントは、ユーザが別の登録済みクライアントを使用して返信を開始するまで、着信メッセージの残りを受け取ります。
その後で、ノードが以降のメッセージをこの新しいクライアントに再ルーティングします。
(注) | ユーザが複数のデバイスにログインするときにアクティブなリソースがない場合は、最も高い優先順位を持つクライアントが最優先されます。プレゼンスの優先順位がすべてのデバイスで同じ場合は、最後にユーザがログインしたクライアントが最優先されます。 |