内容

概要

前提条件

要件

使用するコンポーネント

背景説明

SSO の概要

設定の概要

設定

認証タイプ

信頼関係の確立

ADFS 2.0

ADFS 3.0

証明書利用者信頼(Cisco IdS)の署名付きSAMLアサーションの有効化

フェデレーテッド ADFS のマルチドメイン設定の場合

フェデレーテッド ADFS 設定

プライマリ ADFS 設定

ADFS自動証明書ロールオーバー

Kerberos認証（統合Windows認証）

IWAサポート用のMicrosoft Internet Explorerの設定

IWAサポート用のMozilla Firefoxに必要な設定

IWAサポート用のGoogle Chromeに必要な設定

SSOの詳細設定

確認

トラブルシュート

UCCX SSOバイパス/リカバリURL

SSOの無効化

画面キャプチャ

CCX管理：Non_SSO

CCX管理 – SSO有効

Finesseログイン – SSO以外

Finesseログイン – SSO有効

CUIC:Non_SSO

CUIC:SSO有効

概要

このドキュメントでは、シングルサインオン(SSO)を有効にするためのCisco Identity Service(IdS)のアイデンティティプロバイダー(IdP)の設定について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- 必要に応じて、Cisco Unified Contact Center Express(UCCX)リリース11.5、Cisco Unified Contact Center Enterpriseリリース11.5、またはPackaged Contact Center Enterprise(PCCE)リリース11.5

- Microsoft Active Directory：Windows Server にインストールされた AD

- Active Directory フェデレーション サービス（ADFS）バージョン 2.0/3.0

注：このドキュメントでは、画面キャプチャと例でUCCXを参照していますが、設定はCisco IdS(UCCX/UCCE/PCCE)とIdPに関して類似しています。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

Cisco IdS 導入モデル

製品

導入

Unified CCX

共存

PCCE

CUIC（Cisco Unified Intelligence Center）と LD（ライブ データ）の共存

UCCE

2k 導入用の CUIC と LD の共存。

4k および 12k 導入用のスタンドアロン。

SSO の概要

シスコはさまざまな形式で多くのサービスを提供しています。エンドユーザは、一度だけサインインして、すべてのシスコサービスにアクセスする必要があります。シスコのアプリケーションやデバイスから連絡先を検索して管理する場合は、考えられるすべてのソース（社内ディレクトリ、Outlook、モバイル連絡先、Facebook、LinkedIn、履歴）を活用し、標準的で一貫性のある方法でレンダリングします。これにより、連絡先の可用性と最適な連絡方法を知るために必要な情報が提供されます。

SAML(Security Assertion Markup Language)を使用したSSOは、この要件を対象としています。SAML/SSO は、共通アカウントと、IdP と呼ばれる認証 ID を使用して、複数のデバイスとサービスにログインできます。この SSO 機能は、UCCX/UCCE/PCCE 11.5 以降で使用できます。

設定の概要

設定

認証タイプ

Cisco IdSは、IdPのフォームベース認証のみをサポートします。

ADFSでフォーム認証を有効にする方法については、次のMSDNの記事を参照してください。

- ADFS 2.0 の場合は、次の Microsoft TechNet 記事を参照してください。

http://social.technet.microsoft.com/wiki/contents/articles/1600.ad-fs-2-0-how-to-change-the-local-authentication-type.aspx にアクセスしてください。

- ADFS 3.0 の場合は、次の Microsoft TechNet 記事を参照してください。

https://learn.microsoft.com/en-us/archive/blogs/josrod/enabled-forms-based-authentication-in-adfs-3-0

注:Cisco IdS 11.6以降では、フォームベース認証とKerberos認証の両方がサポートされています。 Kerberos認証を機能させるには、フォームベース認証を無効にする必要があります。

信頼関係の確立

オンボーディングおよびアプリケーションでSSOにCisco IdSを使用できるようにするには、IdSとIdPの間でメタデータ交換を実行します。

- SAML SPメタデータファイルのダウンロード  sp.xml.

- 変更前 Settings、に移動します。 IdS Trust タブをクリックします。

- 次の URL の IdP から IdP メタデータ ファイルをダウンロードします。

https://<ADFSServer>/federationmetadata/2007-06/federationmetadata.xml

- [IdS Management]ページで、前の手順でダウンロードしたIdPメタデータファイルをアップロードします。

これは IdS メタデータをアップロードしてクレーム ルールを追加する手順です。これは、ADFS 2.0および3.0に関する概要です。

ADFS 2.0

ステップ 1：ADFSサーバで、に移動します。 Start > All Programs > Administrative Tools > ADFS 2.0 Management（図を参照）。

ステップ 2：移動先 Add ADFS 2.0 > Trust Relationship > Relying Party Trust（図を参照）。

ステップ 3：図に示すように、オプションを選択します Import data about the relying party from a file.

ステップ 4：証明書利用者信頼の確立を完了します。

ステップ 5：証明書利用者信頼のプロパティで、 Identifier tab.

手順 6：IDを、そのIDが存在するCisco Identity Serverの完全修飾ホスト名として設定します。sp.xml をダウンロードします。

手順 7：[Relying Party Trust]を右クリックし、 Edit Claim Rules.

2つの要求規則を追加する必要があります。1つはLDAP (Lightweight Directory Access Protocol)属性が一致する場合で、もう1つはカスタム要求規則を使用する場合です。

uid：この属性は、認証されたユーザを識別するためにアプリケーションに必要です。

user_principal：この属性は、認証されたユーザのレルムを識別するためにCisco IdSに必要です。

クレーム ルール 1：

名前によるルールの追加 NameID のタイプ（LDAP属性の値を要求として送信）:

- Active Directoryとしての属性ストアの選択

- LDAP属性のマッピング User-Principal-Name から user_principal （小文字）

- 次のように使用するLDAP属性を選択します。 userId アプリケーションユーザがログインし、そのアプリケーションユーザを uid （小文字）

次の場合の設定例 SamAccountName ユーザIDとして使用されます。

- LDAP属性のマッピング SamAccountName から uid.

- LDAP属性のマッピング User-Principal-Name から user_principal.

次の場合の設定例 UPN ユーザIDとして使用する必要があります。

- LDAP属性のマッピング User-Principal-Name から uid.

- LDAP属性のマッピング User-Principal-Name から user_principal.

次の場合の設定例 PhoneNumber ユーザIDとして使用する必要があります。

- LDAP属性telephoneNumberを uid .

- LDAP属性のマッピング User-Principal-Name から user_principal.

注:CUCM LDAP同期でユーザIDに設定されたLDAP属性が、LDAP属性として設定されたものと一致していることを確認する必要があります。 uid ADFSクレームルール内 NameID.これは、CUICとFinesseのログインを正しく機能させるために行います。

注：このドキュメントでは、クレームルール名の制約を参照し、NameID、UCCXの完全修飾ドメイン名(FQDN)などの名前を表示します。カスタムフィールドおよびカスタムフィールド名は様々なセクションで適用可能ですが、要求ルール名および表示名は、一貫性を維持し、命名規則のベストプラクティスに従って、全体を通して標準に保たれます。

クレーム ルール 2：

- Cisco Identity Serverの完全修飾ホスト名として名前が付いたタイプのカスタム要求ルールを追加し、このルールテキストを追加します。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

- Cisco Identity Serverクラスタでは、すべての完全修飾ホスト名は、Cisco Identity Serverのプライマリノードまたはパブリッシャノードの完全修飾ホスト名です。

- <Cisco Identity Serverの完全修飾ホスト名>は大文字と小文字が区別されるため、Cisco Identity ServerのFQDNと正確に（大文字と小文字を含めて）一致します。

- <ADFSサーバFQDN>では大文字と小文字が区別されるため、ADFS FQDNと（大文字と小文字を含めて）完全に一致します。

ステップ 8：[Relying Party Trust]を右クリックし、 Properties 次の図に示すように、[advanced]タブを選択します。

ステップ 9：図に示すように、SHA-256として[Secure Hash Algorithm (SHA)]を選択します。

ステップ 10：クリック OK.

ADFS 3.0

ステップ 1：ADFSサーバで、 Server Manager > Tools > ADFS Management.

ステップ 2：移動先 ADFS > Trust Relationship > Relying Party Trust.

ステップ 3：オプションを選択します Import data about the relying party from a file.

ステップ 4：証明書利用者信頼の確立を完了します。

ステップ 5：証明書利用者信頼のプロパティで、 Identifier tab.

手順 6：IDを、そのIDが存在するCisco Identity Serverの完全修飾ホスト名として設定します。sp.xml をダウンロードします。

手順 7：[Relying Party Trust]を右クリックし、 Edit Claim Rules.

2つの要求規則を追加する必要があります。1つはLDAP属性が一致する場合で、もう1つはカスタム要求規則を使用する場合です。

uid：この属性は、アプリケーションが認証されたユーザを識別するために必要です。

user_principal：この属性は、認証されたユーザのレルムを識別するためにCisco IdSに必要です。

クレーム ルール 1：

名前によるルールの追加 NameID のタイプ（LDAP属性の値を要求として送信）:

- Active Directoryとしての属性ストアの選択

- LDAP属性のマッピング User-Principal-Name から user_principal （小文字）

- 次のように使用するLDAP属性を選択します。 userId アプリケーションユーザがログインしてマッピングできる uid（小文字）

次の場合の設定例 SamAccountName ユーザIDとして使用されます。

- LDAP属性のマッピング SamAccountName から uid.

- LDAP属性のマッピング User-Principal-Name から user_principal.

ユーザIDとしてUPNを使用する必要がある場合の設定例：

- LDAP属性のマッピング User-Principal-Name から uid.

- LDAP属性のマッピング User-Principal-Name から user_principal.

次の場合の設定例 PhoneNumber ユーザIDとして使用する必要があります。

- LDAP属性のマッピング telephoneNumber から uid.

- LDAP属性のマッピング User-Principal-Name から user_principal.

注:CUCM LDAP同期でユーザIDに設定されたLDAP属性が、LDAP属性として設定されたものと一致していることを確認する必要があります。 uid ADFSクレームルールのNameIDで指定します。これは、CUICおよびFinesseログインの適切な機能のためのものです。

注：このドキュメントでは、クレームルール名と表示名に関する制約（NameID、UCCXのFQDNなど）を参照します。カスタムフィールドおよびカスタムフィールド名は様々なセクションで適用可能ですが、要求規則名および表示名は、一貫性を維持し、命名規則のベストプラクティスを実現するために、全体を通して標準に保たれます。

クレーム ルール 2：

- Cisco Identity Serverの完全修飾ホスト名として名前が付いたタイプのカスタム要求ルールを追加し、このルールテキストを追加します。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

- Cisco Identity Serverクラスタでは、すべての完全修飾ホスト名は、Cisco Identity Serverのプライマリノードまたはパブリッシャノードの完全修飾ホスト名です。

- <Cisco Identity Serverの完全修飾ホスト名>は大文字と小文字が区別されるため、Cisco Identity ServerのFQDNと正確に（大文字と小文字を含めて）一致します。

- <ADFSサーバFQDN>では大文字と小文字が区別されるため、ADFS FQDNと（大文字と小文字を含めて）完全に一致します。

ステップ 8：[Relying Party Trust]を右クリックし、 Properties を選択し、 advanced tab.

ステップ 9：図に示すように、SHAとしてSHA-256を選択します。

ステップ 10：クリック OK.

これらは、手順 10 の後に必ず行うべき手順です。

証明書利用者信頼(Cisco IdS)の署名付きSAMLアサーションの有効化

ステップ 1：クリック Start PowerShellを入力して、Windows PowerShellを開きます。

ステップ 2：コマンドを使用してADFS CmdLetをPowerShellに追加します Add-PSSnapin Microsoft.Adfs.Powershell.

ステップ 3：コマンドを実行します。 Set-ADFSRelyingPartyTrust -TargetName

-SamlResponseSignature "MessageAndAssertion"

.

注：ADFS 3.0を使用する場合、CmdLetは役割と機能の追加の一部としてすでにインストールされているため、手順2.は必要ありません。

注:

大文字と小文字が区別されるため、証明書利用者信頼プロパティの[Identifier]タブで設定されている内容と一致します（大文字と小文字が含まれます）。

注:UCCXバージョン12.0以降、Cisco IdSはSHA-256をサポートしています。証明書利用者信頼はSHA-256を使用してSAML要求に署名し、ADFSからの同じ応答を期待します。

フェデレーテッド ADFS のマルチドメイン設定の場合

ADFSでのフェデレーションの場合、特定のドメイン内のADFSが他の設定済みドメイン内のユーザに対してフェデレーションSAML認証を提供する場合は、追加の設定が必要です。

このセクションでは、プライマリADFSという用語は、IdSで使用する必要があるADFSを指します。フェデレーテッドADFSという用語は、ユーザがIdS経由でログインできるADFSを示します。つまり、このADFSがプライマリADFSです。

フェデレーテッド ADFS 設定

各フェデレーテッドADFSでは、前のセクションで説明したように、プライマリADFSとクレームルールに対して証明書利用者信頼を作成する必要があります。

プライマリ ADFS 設定

プライマリADFSでは、IdSの証明書利用者信頼とは別に、この追加設定が必要です。

追加 Claim Provider Trust フェデレーションを設定する必要があるADFSを使用します。

クレームプロバイダー信頼で、 Pass through or Filter an Incoming Claim ルールは、オプションとしてパススルーのすべての要求値で設定されます。

- Name ID

- [Name ID]を Incoming Claim Type Dropbox

- 選択 Transient 着信NameID形式のオプションとして

- uid：これはカスタム要求です。値uidを Incoming Claim Type Dropbox

- user_principal：これはカスタム要求です。値user_principalを Incoming Claim Type Dropbox

[Relying Party Trust for IdS]で、 Pass though or Filter an Incoming Claim すべての要求値をパススルーするルールをオプションとして使用します。

- NameIDFromSubdomain

- 名前IDの選択元 Incoming Claim Type Dropbox

- 選択 Transient 着信NameID形式のオプションとして

- uid：これはカスタム要求です。値uidを Incoming Claim Type Dropbox

- user_principal：これはカスタム要求です。値user_principalを Incoming Claim Type Dropbox

ADFS自動証明書ロールオーバー

証明書の自動ロールオーバーは、UCCX 11.6.1以降でサポートされています。(UCCX 11.6のFedletライブラリをバージョン14.0にアップグレードすると、この問題が解決されました)。

Kerberos認証（統合Windows認証）

統合Windows認証(IWA)は、ユーザの認証メカニズムを提供しますが、クレデンシャルをネットワーク経由で送信することはできません。統合Windows認証を有効にすると、 チケットに基づいて動作し、ノードが非セキュアなネットワークを介して通信し、セキュアな方法で相互にIDを証明できるようにします。ユーザは、Windowsマシンにログインした後にドメインにログインできます。

注:Kerberos認証は11.6以降でのみサポートされています。

すでにドメインコントローラ(DC)にログインしているドメインユーザは、クレデンシャルを再入力しなくてもSSOクライアントにシームレスにログインできます。非ドメインユーザの場合、IWAはNew Technology Local Area Network Manager(NTLM)にフォールバックし、ログインダイアログが表示されます。IWA認証を使用するIdSの認定は、ADFS 3.0に対してKerberosを使用して行われます。

ステップ 1：Windowsコマンドプロンプトを開き、Adminユーザとして実行して、HTTPサービスを setspn command setspn -s http/

\

.

ステップ 2：フォーム認証を無効にし、イントラネットサイトのWindows認証を有効にします。移動先 ADFS Management > Authentication Policies > Primary Authentication > Global Settings > Edit.[Intranet]で、[Windows Authentication]だけがオンになっていることを確認します([Form Authentication]のチェックマークを外します)。

IWAサポート用のMicrosoft Internet Explorerの設定

ステップ 1： 次のことを確認します。 Internet Explorer > Advanced > Enable Integrated Windows Authentication チェックが入っていることを確認します。

ステップ 2： ADFS URLを追加する必要があります Security > Intranet zones > Sites  (winadcom215.uccx116.com はADFS URLです)。

ステップ 3： 次のことを確認します。Internet Explorer > Security > Local Intranet > Security Settings > User Authentication - Logon  は、イントラネットサイトにログインしたクレデンシャルを使用するように設定されています。

IWAサポート用のMozilla Firefoxに必要な設定

ステップ 1：Firefoxの設定モードに入ります。Firefoxを開き、次のように入力します about:config  をURLに入力します。リスクステートメントを受け入れます。

ステップ 2：検索 ntlm  を有効にし、 network.automatic-ntlm-auth.allow-non-fqdn  trueに設定します。

ステップ 3：設定 network.automatic-ntlm-auth.trusted-uris  ADFS URLを明示的に指定します。

IWAサポート用のGoogle Chromeに必要な設定

WindowsのGoogle ChromeはInternet Explorerの設定を使用するため、Internet Explorer内で設定します Tools > Internet Options ダイアログを表示するか、コントロールパネルの Internet Options サブカテゴリ内で Network and Internet.

SSOの詳細設定

このドキュメントでは、Cisco IdSと統合するためのSSOのIdPの側面からの設定について説明します。詳細については、個々の製品のコンフィギュレーション ガイドを参照してください。

- Unified CCX

- UCCE

- PCCE

確認

この手順は、信頼当事者証明が Cisco IdS と IDP との間で正しく設定されているかどうかを判別するために使用します。

- ブラウザからURL https://<ADFS_FQDN>/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=<IDS_FQDN>を入力します。

- ADFSはログインフォームを提供します。これは、上記の設定が正しい場合に使用できます。

- 認証に成功すると、ブラウザはhttps://<IDS_FQDN>:8553/ids/saml/responseにリダイレクトする必要があり、チェックリストページが表示されます。

注：検証プロセスの一部として表示される[Checklist]ページは、エラーではなく、信頼が正しく確立されていることを確認するものです。

トラブルシュート

トラブルシューティングについては、https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200662-ADFS-IdS-Troubleshooting-and-Common-Prob.htmlを参照してください。

UCCX SSOバイパス/リカバリURL

- Cisco Unified CCX Administration

- Cisco Unified CCXサービスアビリティ

SSOの無効化

- GUI：次に移動します。 CCX Administration > Single Sign-On (SSO) > Disable.

- CLI： set authmode non_sso (このコマンドは、パブリッシャとサブの両方に対してSSOを無効にする必要があります。ハイアベイラビリティ(HA)クラスタの場合は、UCCXノードのいずれかから実行できます)。

画面キャプチャ

CCX管理：Non_SSO

CCX管理 – SSO有効

Finesseログイン – SSO以外

Finesseログイン – SSO有効

CUIC:Non_SSO

CUIC:SSO有効