SAML ベースの SSO 前提条件
SAML ベースの SSO 設定には以下のシステム設定が必要です:
-
NTP セットアップ
-
DNS セットアップ
-
ディレクトリのセットアップ
NTP セットアップ
SAML SSO では、Network Time Protocol(NTP)を使用することで Unified Communications アプリケーションと IdP の間で時刻を同期させることができます。 SAML は時間に依存するプロトコルであり、IdP は SAML アサーションの時間ベースの有効性を決定します。 IdP と Unified Communications アプリケーションのクロックが同期していない場合、アサーションが無効になり、SAML SSO 機能が停止します。 IdP と Unified Communications アプリケーション間で許容されている最大時差は 3 秒です。
![]() (注) |
SAML SSO を有効にするには、正しい NTP セットアップをインストールし、IdP と Unified Communications アプリケーションとの時差が 3 秒を超えないことを確認する必要があります。 |
クロックを同期するために NTP サーバを追加する方法については、『 Cisco Unified Communications Manager のシステム構成ガイド』の「デバイスプールのコア設定」の章を参照してください。
DNS セットアップ
ドメイン ネーム システム (DNS) は、ネットワーク内でホスト名とネットワーク サービスの IP アドレスへのマッピングを有効にします。 ネットワーク内に展開された DNS サーバは、ネットワークサービスをホスト名にマッピングし、さらにホスト名を IP アドレスにマッピングするデータベースを提供します。 ネットワーク上のデバイスは、DNS サーバにクエリを行い、ネットワーク内の他のデバイスの IP アドレスを受け取ることができるため、ネットワーク デバイス間の通信が容易になります。
Unified Communications アプリケーションは DNS を使用して、完全修飾ドメイン名を IP アドレスに解決できます。 サービス プロバイダーと IdP は、ブラウザーによって解決可能である必要があります。 例えば、管理者がサービスプロバイダのホスト名 (http://www.cucm.com/ccmadmin) をブラウザに入力すると、ブラウザはホスト名を解決する必要があります。 SAML SSO のために、サービスプロバイダーがブラウザを IdP(http://www.idp.com/saml)にリダイレクトする場合、ブラウザは IdP ホスト名を解決する必要があります。 さらに、IdP がサービスプロバイダーの ACS URL にリダイレクトする場合、ブラウザはそれも解決する必要があります。
ディレクトリのセットアップ
LDAP ディレクトリの同期は、さまざまな Unified Communications アプリケーションで SAML SSO を有効にするための前提条件および必須の手順です。 Unified Communications アプリケーションと LDAP ディレクトリの同期により、管理者は Unified Communications アプリケーションのデータフィールドをディレクトリ属性にマッピングすることで、ユーザを簡単にプロビジョニングできます。
![]() (注) |
SAML SSO を有効にするには、LDAP サーバが IdP サーバにより信頼され、Unified Communications アプリケーションによりサポートされている必要があります。 |
詳細については、次の場所にある『Cisco コラボレーション システム ソリューション リファレンス ネットワーク デザイン(SRND)』の「ディレクトリ統合と ID 管理」の章を参照してください。
証明書管理と検証
![]() 重要 |
Cisco は、サーバ証明書が SAML SSO に対して署名され、製品サポートが利用できる場合にはマルチサーバ証明書が使用されることを強く推奨します。 |
![]() (注) |
|
SAML SSO では、ユーザのウェブブラウザを含む、SAML メッセージ交換に参加している各エンティティは、要求されたエンティティへのシームレスで安全な HTTPS 接続を確立する必要があります。 Cisco は、SAML SSO 展開に参加する各 UC 製品で、信頼できる認証局により発行された署名付き証明書を設定することを強く推奨します。
Unified Communications アプリケーションは証明書の検証を使用して、サーバーとのセキュアな接続を確立します。 証明書はエンドポイント間で使用され、データの信頼/認証と暗号化を構築します。 これにより、エンドポイントが目的のデバイスと通信し、2 つのエンドポイント間でデータを暗号化するオプションがあることを確認します。
安全な接続の確立を試みる際、サーバは Unified Communications クライアントに証明書を提示します。 クライアントが証明書を検証できない場合、証明書を受け入れるかどうかを確認するプロンプトをユーザに表示します。
認証局によって署名された証明書
Cisco は、以下のタイプの認証局 (CA) のいずれかによって署名されたサーバ証明書の使用を推奨しています。
- 公開 CA - サードパーティがサーバの身元を確認し、信頼できる証明書を発行します。
- プライベート CA - ローカル CA を作成、管理し、信頼できる証明書を発行します。
署名プロセスは各製品によって異なり、サーバのバージョンによっても異なります。 各サーバの各バージョンに対する詳細な手順を提供することは、このドキュメントの範囲を超えます。 CA によって署名された証明書を取得する方法に関する詳細な手順については、適切なサーバのドキュメントを参照してください。
しかし、次のステップは、手順の大まかな概要を説明しています。
手順
|
ステップ 1 |
クライアントに証明書を提示できる各製品で、証明書署名リクエスト(CSR)を生成します。 |
|
ステップ 2 |
各 CSR を CA に送信します。 |
|
ステップ 3 |
CA が発行する証明書を各サーバにアップロードします。 |
パブリック CA により署名されたサーバ証明書を取得する場合、クライアントコンピュータのトラストストアに、パブリック CA のルート証明書がすでにあるはずです。 この場合、クライアントコンピュータにルート証明書をインポートする必要はありません。
証明書がプライベート CA などの信頼ストアにまだ存在しない CA によって署名されている場合、ルート証明書をインポートする必要があります。
SAML SSO では、IdP とサービスプロバイダは CN または SAN の正しいドメインを持つ CA の署名入りの証明書を持っている必要があります。 正しい CA 証明書が検証されない場合、ブラウザはポップアップ警告を発行します。
例えば、管理者がブラウザで https://www.cucm.com/ccmadmin; Unified Communications Manager ポータルは CA 証明書をブラウザに提示します。 ブラウザが https://www.idp.com/saml にリダイレクトされると、IdP は CA 証明書を提示します。 ブラウザは、サーバによって提示された証明書にそのドメインの CN または SAN フィールドが含まれていること、および証明書が信頼された CA によって署名されていることを確認します。
代わりに、顧客が独自のプライベート CA を持っている場合、その CA は、管理者がブラウザを起動しているコンピュータにルート トラスト アンカーとしてインストールする必要があります。マルチサーバ SAN 証明書の設定
各 Cisco 製品には、マルチサーバ SAN 証明書を生成するための独自のプロセスがあります。 マルチサーバ SAN 証明書をサポートする Cisco 製品についての情報は、関連するガイドを参照してください。
Microsoft Edge 相互運用のための証明書発行者を展開する
Microsoft Edge ブラウザが展開されている SAML SSO 展開には、相互運用性の問題が存在します。 SSO が有効なマシンに Edge ブラウザが展開されている場合、Edge ブラウザは Unified Communications Manager 証明書の発行者を認識せず、アクセスを提供しません。
この手順を使用して、グループ ポリシー オブジェクト (GPO) および Active Directory 経由でこの問題を修正します。これにより、Unified Communications Manager 証明書の発行者を、Edge ブラウザを使用するローカル マシンの信頼されたルート証明書にプッシュできます。
![]() (注) |
「証明書の発行者」は、証明書のセットアップ方法によって異なります。 たとえば、サードパーティ CA 証明書の場合、CA 自体が Unified Communications Manager 証明書に署名する場合にのみ、CA 証明書をプッシュする必要があります。 ただし、中間 CA が Unified Communications Manager 証明書に署名する場合、ルート証明書、中間証明書、およびリーフ証明書を含む完全な証明書チェーンをプッシュする必要があるかもしれません。 |
始める前に
この手順を実行するには、ローカルマシンのローカル Administrators グループのメンバーシップ、またはそれと同等の権限が最低限必要です。
手順
|
ステップ 1 |
Active Directory で、グループポリシー管理コンソールを開きます。 |
|
ステップ 2 |
既存の GPO を検索するか、証明書の設定を含む新しい GPO を作成します。 GPO は、ポリシーの影響を受けるユーザのドメイン、サイト、または組織単位と関連付けられている必要があります。 |
|
ステップ 3 |
GPO を右クリックして、[編集(Edit)] を選択します。 |
|
ステップ 4 |
ナビゲーションペインで を開きます。 |
|
ステップ 5 |
[アクション(Action)] メニューをクリックし、[インポート(Import)] をクリックします。 |
|
ステップ 6 |
証明書インポートウィザード の手順に従い、証明書を見つけてインポートしてください。 |
|
ステップ 7 |
証明書が自己署名証明書で、[信頼されたルート証明機関(Trusted Root Certification Authorities)] 証明書ストアにある証明書までさかのぼることができない場合は、証明書をそのストアにコピーする必要があります。 ナビゲーションペインで、[ 信頼されたルート証明機関] をクリックし、ステップ 5 と 6 を繰り返してストアに証明書のコピーをインストールします。 |
![]() (注) |
Active Directory での信頼されたルート証明書の管理についての詳細は、 https://technet.microsoft.com/en-us/library/cc754841(v=ws.11).aspxを参照してください。 |

フィードバック