この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、シングルサインオン(SSO)を有効にするためのCisco Identity Service(IdS)のアイデンティティプロバイダー(IdP)の設定について説明します。
次の項目に関する知識があることが推奨されます。
注:このドキュメントでは、画面キャプチャと例でUCCXを参照していますが、設定はCisco IdS(UCCX/UCCE/PCCE)とIdPに関して類似しています。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
Cisco IdS 導入モデル
製品 |
導入 |
Unified CCX |
共存 |
PCCE |
CUIC(Cisco Unified Intelligence Center)と LD(ライブ データ)の共存 |
UCCE |
2k 導入用の CUIC と LD の共存。 4k および 12k 導入用のスタンドアロン。 |
シスコはさまざまな形式で多くのサービスを提供しています。エンドユーザは、一度だけサインインして、すべてのシスコサービスにアクセスする必要があります。シスコのアプリケーションやデバイスから連絡先を検索して管理する場合は、考えられるすべてのソース(社内ディレクトリ、Outlook、モバイル連絡先、Facebook、LinkedIn、履歴)を活用し、標準的で一貫性のある方法でレンダリングします。これにより、連絡先の可用性と最適な連絡方法を知るために必要な情報が提供されます。
SAML(Security Assertion Markup Language)を使用したSSOは、この要件を対象としています。SAML/SSO は、共通アカウントと、IdP と呼ばれる認証 ID を使用して、複数のデバイスとサービスにログインできます。この SSO 機能は、UCCX/UCCE/PCCE 11.5 以降で使用できます。
Cisco IdSは、IdPのフォームベース認証のみをサポートします。
ADFSでフォーム認証を有効にする方法については、次のMSDNの記事を参照してください。
注:Cisco IdS 11.6以降では、フォームベース認証とKerberos認証の両方がサポートされています。 Kerberos認証を機能させるには、フォームベース認証を無効にする必要があります。
オンボーディングおよびアプリケーションでSSOにCisco IdSを使用できるようにするには、IdSとIdPの間でメタデータ交換を実行します。
sp.xml
.Settings
、に移動します。 IdS Trust
タブをクリックします。
これは IdS メタデータをアップロードしてクレーム ルールを追加する手順です。これは、ADFS 2.0および3.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属性の値を要求として送信):
User-Principal-Name
から user_principal
(小文字)userId
アプリケーションユーザがログインし、そのアプリケーションユーザを uid
(小文字)
次の場合の設定例 SamAccountName
ユーザIDとして使用されます。
SamAccountName
から uid
.User-Principal-Name
から user_principal
.次の場合の設定例 UPN
ユーザIDとして使用する必要があります。
User-Principal-Name
から uid
.User-Principal-Name
から user_principal
.次の場合の設定例 PhoneNumber
ユーザIDとして使用する必要があります。
uid
.User-Principal-Name
から user_principal
.
注:CUCM LDAP同期でユーザIDに設定されたLDAP属性が、LDAP属性として設定されたものと一致していることを確認する必要があります。 uid
ADFSクレームルール内 NameID
.これは、CUICとFinesseのログインを正しく機能させるために行います。
注:このドキュメントでは、クレームルール名の制約を参照し、NameID、UCCXの完全修飾ドメイン名(FQDN)などの名前を表示します。カスタムフィールドおよびカスタムフィールド名は様々なセクションで適用可能ですが、要求ルール名および表示名は、一貫性を維持し、命名規則のベストプラクティスに従って、全体を通して標準に保たれます。
クレーム ルール 2:
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>");
ステップ 8:[Relying Party Trust]を右クリックし、 Properties
次の図に示すように、[advanced]タブを選択します。
ステップ 9:図に示すように、SHA-256として[Secure Hash Algorithm (SHA)]を選択します。
ステップ 10:クリック OK
.
ステップ 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属性の値を要求として送信):
User-Principal-Name
から user_principal
(小文字)userId
アプリケーションユーザがログインしてマッピングできる uid
(小文字)
次の場合の設定例 SamAccountName
ユーザIDとして使用されます。
SamAccountName
から uid
.User-Principal-Name
から user_principal
.ユーザIDとしてUPNを使用する必要がある場合の設定例:
User-Principal-Name
から uid
.User-Principal-Name
から user_principal
.次の場合の設定例 PhoneNumber
ユーザIDとして使用する必要があります。
telephoneNumber
から uid
.User-Principal-Name
から user_principal
.
注:CUCM LDAP同期でユーザIDに設定されたLDAP属性が、LDAP属性として設定されたものと一致していることを確認する必要があります。 uid
ADFSクレームルールのNameIDで指定します。これは、CUICおよびFinesseログインの適切な機能のためのものです。
注:このドキュメントでは、クレームルール名と表示名に関する制約(NameID、UCCXのFQDNなど)を参照します。カスタムフィールドおよびカスタムフィールド名は様々なセクションで適用可能ですが、要求規則名および表示名は、一貫性を維持し、命名規則のベストプラクティスを実現するために、全体を通して標準に保たれます。
クレーム ルール 2:
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>");
ステップ 8:[Relying Party Trust]を右クリックし、 Properties
を選択し、 advanced
tab.
ステップ 9:図に示すように、SHAとしてSHA-256を選択します。
ステップ 10:クリック OK
.
これらは、手順 10 の後に必ず行うべき手順です。
ステップ 1:クリック Start
PowerShellを入力して、Windows PowerShellを開きます。
ステップ 2:コマンドを使用してADFS CmdLetをPowerShellに追加します Add-PSSnapin Microsoft.Adfs.Powershell
.
ステップ 3:コマンドを実行します。 Set-ADFSRelyingPartyTrust -TargetName
.
注:ADFS 3.0を使用する場合、CmdLetは役割と機能の追加の一部としてすでにインストールされているため、手順2.は必要ありません。
注:
大文字と小文字が区別されるため、証明書利用者信頼プロパティの[Identifier]タブで設定されている内容と一致します(大文字と小文字が含まれます)。
注:UCCXバージョン12.0以降、Cisco IdSはSHA-256をサポートしています。証明書利用者信頼はSHA-256を使用してSAML要求に署名し、ADFSからの同じ応答を期待します。
ADFSでのフェデレーションの場合、特定のドメイン内のADFSが他の設定済みドメイン内のユーザに対してフェデレーションSAML認証を提供する場合は、追加の設定が必要です。
このセクションでは、プライマリADFSという用語は、IdSで使用する必要があるADFSを指します。フェデレーテッドADFSという用語は、ユーザがIdS経由でログインできるADFSを示します。つまり、このADFSがプライマリADFSです。
各フェデレーテッドADFSでは、前のセクションで説明したように、プライマリADFSとクレームルールに対して証明書利用者信頼を作成する必要があります。
プライマリADFSでは、IdSの証明書利用者信頼とは別に、この追加設定が必要です。
追加 Claim Provider Trust
フェデレーションを設定する必要があるADFSを使用します。
クレームプロバイダー信頼で、 Pass through or Filter an Incoming Claim
ルールは、オプションとしてパススルーのすべての要求値で設定されます。
Incoming Claim Type
DropboxTransient
着信NameID形式のオプションとしてIncoming Claim Type
DropboxIncoming Claim Type
Dropbox[Relying Party Trust for IdS]で、 Pass though or Filter an Incoming Claim
すべての要求値をパススルーするルールをオプションとして使用します。
Incoming Claim Type
DropboxTransient
着信NameID形式のオプションとしてIncoming Claim Type
DropboxIncoming Claim Type
Dropbox証明書の自動ロールオーバーは、UCCX 11.6.1以降でサポートされています。(UCCX 11.6のFedletライブラリをバージョン14.0にアップグレードすると、この問題が解決されました)。
統合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]のチェックマークを外します)。
ステップ 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
は、イントラネットサイトにログインしたクレデンシャルを使用するように設定されています。
ステップ 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を明示的に指定します。
WindowsのGoogle ChromeはInternet Explorerの設定を使用するため、Internet Explorer内で設定します Tools > Internet Options
ダイアログを表示するか、コントロールパネルの Internet Options
サブカテゴリ内で Network and Internet
.
このドキュメントでは、Cisco IdSと統合するためのSSOのIdPの側面からの設定について説明します。詳細については、個々の製品のコンフィギュレーション ガイドを参照してください。
この手順は、信頼当事者証明が Cisco IdS と IDP との間で正しく設定されているかどうかを判別するために使用します。
注:検証プロセスの一部として表示される[Checklist]ページは、エラーではなく、信頼が正しく確立されていることを確認するものです。
トラブルシューティングについては、https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200662-ADFS-IdS-Troubleshooting-and-Common-Prob.htmlを参照してください。
CCX Administration > Single Sign-On (SSO) > Disable
.set authmode non_sso
(このコマンドは、パブリッシャとサブの両方に対してSSOを無効にする必要があります。ハイアベイラビリティ(HA)クラスタの場合は、UCCXノードのいずれかから実行できます)。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
24-Aug-2021 |
初版 |