المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

معلومات أساسية

نظرة عامة على SSO

نظرة عامة على التكوين

التكوين

أنواع المصادقة

تأسيس علاقة ثقة

نظام الملفات ADFS 2.0

نظام الملفات ADFS 3.0

تمكين تأكيدات SAML الموقعة لثقة الطرف المعتمد (معرفات Cisco)

لتكوين متعدد المجالات ل ADFS المتحد

تكوين ADFS المتحد

تكوين ADFS الأساسي

التبديل التلقائي للشهادة ADFS

مصادقة Kerberos (مصادقة Windows المتكاملة)

تكوين Microsoft Internet Explorer لدعم IWA

يلزم توفر التهيئة لبرنامج Mozilla Firefox لدعم تقنية IWA

يلزم توفر التكوين ل Google Chrome لدعم IWA

مزيد من التكوين ل SSO

التحقق من الصحة

استكشاف الأخطاء وإصلاحها

عناوين URL إسترداد/تجاوز UCCX SSO

تعطيل SSO

مسامير لولبية

إدارة CCX - NON_SSO

إدارة CCX - تمكين SSO

تسجيل دخول Finesse - بخلاف SSO

تسجيل دخول Finesse - تمكين SSO

CUIC - non_SSO

CUIC - تمكين SSO

المقدمة

يصف هذا المستند تكوين موفر الهوية (IdP) لخدمة تعريف Cisco (IdS) لتمكين تسجيل الدخول الأحادي (SSO).

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

- 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 - AD مثبت على Windows Server

- Active Directory Federation Service (ADFS)، الإصدار 2.0/3.0

ملاحظة: يشير هذا المستند إلى UCCX في الشاشة التقاط وأمثلة، ومع ذلك، فإن التكوين مماثل فيما يتعلق بمعرفات Cisco (UCCX/UCCE/PCCE) و IdP.

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

نماذج نشر معرفات Cisco

المنتج

النشر

UCCX

مقيم مشارك

PCCE

مقيم مشترك مع CUIC (Cisco Unified Intelligence Center) و LD (بيانات مباشرة)

UCCE

مشارك مقيم مع CUIC و LD لعمليات نشر 2k.

مستقلة لعمليات النشر التي تبلغ 4 آلاف و 12 ألف عملية.

نظرة عامة على SSO

توفر Cisco العديد من الخدمات في نماذج مختلفة وكمستخدم نهائي، تريد تسجيل الدخول مرة واحدة فقط للحصول على حق الوصول إلى جميع خدمات Cisco. إذا كنت ترغب في العثور على جهات الاتصال وإدارتها من أي من تطبيقات Cisco وأجهزتها، فيمكنك الاستفادة من جميع المصادر المحتملة (دليل الشركة و Outlook وجهات اتصال الهواتف المحمولة و Facebook و LinkIn و History) وتزويدها بطريقة قياسية ومتسقة توفر المعلومات المطلوبة لمعرفة مدى توفرها وكيفية الاتصال بها على أفضل وجه.

ويستهدف SSO باستخدام SAML (لغة تمييز تأكيد الأمان) هذا المتطلب. توفر SAML/SSO قدرة المستخدمين على تسجيل الدخول إلى أجهزة وخدمات متعددة من خلال حساب مشترك وهوية تخويل تسمى IdP. وتتوفر وظيفة تسجيل الدخول الموحد في نظام UCCX/UCCE/PCCE الإصدار 11.5 وما بعده.

نظرة عامة على التكوين

التكوين

أنواع المصادقة

تدعم معرفات Cisco المصادقة المستندة إلى النموذج فقط لمعرف IdPs.

ارجع إلى مقالات MSDN هذه لمعرفة كيفية تمكين مصادقة النموذج في ADFS.

- بالنسبة ل 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 الإصدار 11.6 والإصدارات الأحدث كل من المصادقة المستندة إلى النموذج ومصادقة Kerberos. لكي تعمل مصادقة Kerberos، يجب تعطيل المصادقة المستندة إلى النموذج.

تأسيس علاقة ثقة

للإدراج ولتمكين التطبيقات من إستخدام معرفات Cisco ل SSO، قم بإجراء تبادل بيانات التعريف بين المعرفات والمعرفات.

- تنزيل ملف بيانات تعريف SAML SP  sp.xml.

- من Settings، انتقل إلى IdS Trust علامة التبويب في صفحة إدارة المعرفات.

- قم بتنزيل ملف بيانات تعريف IdP من IdP من عنوان URL:

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

- في صفحة إدارة المعرفات، قم بتحميل ملف بيانات تعريف IdP الذي تم تنزيله في الخطوة السابقة.

هذا هو الإجراء الخاص بتحميل بيانات تعريف المعرفات وإضافة قواعد المطالبات. وهذا موضح لبرنامجي 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 علامة تبويب.

الخطوة 6. قم بتعيين المعرف كاسم المضيف المؤهل بالكامل لخادم تعريف Cisco الذي يتم من خلالهsp.xml تم تنزيله.

الخطوة 7. انقر بزر الماوس الأيمن على Relying Party Trust ثم انقر فوق Edit Claim Rules.

يجب إضافة قاعدتي مطالبة، الأولى هي عندما تتم مطابقة سمات LDAP (بروتوكول الوصول إلى الدليل خفيف الوزن) بينما تكون الثانية من خلال قواعد مطالبة مخصصة.

uid - هذه السمة مطلوبة للتطبيقات لتحديد المستخدم المصدق عليه.

user_principal - يلزم أن تكون هذه السمة بواسطة معرفات Cisco لتحديد مجال المستخدم الذي تمت مصادقته.

قاعدة المطالبة 1:

إضافة قاعدة بالاسم NameID من النوع (قم بإرسال قيم سمة LDAP كمطالبات):

- إختيار مخزن السمات كActive Directory

- تعيين سمة LDAP User-Principal-Name               إلى user_principal (الحروف الصغيرة)

- أختر سمة LDAP التي يجب إستخدامها ك userId لمستخدمي التطبيق لتسجيل الدخول وتخطيطه إلى uid (الحروف الصغيرة)

مثال على التكوين عند SamAccountName هو أن يتم إستخدامه كمعرف المستخدم:

- تعيين سمة LDAP SamAccountName               إلى uid.

- تعيين سمة LDAP User-Principal-Name               إلى user_principal.

مثال على التكوين عند UPN يجب إستخدامه كمعرف المستخدم:

- تعيين سمة LDAP User-Principal-Name               إلى uid.

- تعيين سمة LDAP User-Principal-Name               إلى user_principal.

مثال على التكوين عند PhoneNumber يجب إستخدامه كمعرف المستخدم:

- تعيين رقم هاتف سمة LDAP إلى uid .

- تعيين سمة LDAP User-Principal-Name               إلى user_principal.

ملاحظة: يجب التأكد من تطابق سمة LDAP التي تم تكوينها لمعرف المستخدم في مزامنة CUCM LDAP مع ما تم تكوينه كسمة LDAP ل uid في قاعدة مطالبة ADFS NameID. هذا من أجل العمل السليم لمدخل CUIC و Finesse.

ملاحظة: يشير هذا المستند إلى القيود المفروضة على اسم قاعدة المطالبة ويعرض أسماء مثل NameID واسم المجال المؤهل بالكامل (FQDN) من UCCX وما إلى ذلك. وعلى الرغم من إمكانية تطبيق الحقول والأسماء المخصصة على أقسام مختلفة، فإن أسماء قواعد المطالبات وأسماء العرض تبقى قياسية طوال الوقت للحفاظ على الاتساق ولأفضل الممارسات في قاعدة التسمية.

قاعدة المطالبة الثانية:

- أضف قاعدة أخرى من نوع قاعدة مطالبة مخصصة بالاسم كاسم المضيف المؤهل بالكامل لخادم تعريف Cisco وأضف نص القاعدة هذا.

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 الأساسية أو عقدة الناشر.

- ويعتبر <emQualified name لخادم تعريف Cisco> حساسا لحالة الأحرف، لذلك فإنه يتطابق تماما (في الحالة المضمنة) مع FQDN لخادم هوية Cisco.

- <ADFS Server FQDN> حساس لحالة الأحرف، لذلك فإنه يطابق (الحالة المضمنة) تماما مع ADFS FQDN.

الخطوة 8. انقر بزر الماوس الأيمن على Relying Party Trust ثم انقر فوق Properties واختر علامة التبويب خيارات متقدمة، كما هو موضح في الصورة.

الخطوة 9. كما هو موضح في الصورة، أختر خوارزمية التجزئة الآمنة (SHA) على هيئة SHA-256.

الخطوة 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 علامة تبويب.

الخطوة 6. قم بتعيين المعرف كاسم المضيف المؤهل بالكامل لخادم تعريف Cisco الذي يتم من خلالهsp.xml تم تنزيله.

الخطوة 7. انقر بزر الماوس الأيمن فوق ثقة الطرف المعتمد ثم انقر فوق Edit Claim Rules.

يجب إضافة قاعدتي مطالبة، الأولى هي عندما تتم مطابقة سمات LDAP بينما تكون الثانية من خلال قواعد مطالبة مخصصة.

uid - هذه السمة مطلوبة للتطبيقات لتعريف المستخدم المصدق عليه.

user_principal - يلزم أن تكون هذه السمة بواسطة معرفات Cisco لتحديد مجال المستخدم الذي تمت مصادقته.

قاعدة المطالبة 1:

إضافة قاعدة بالاسم NameID من نوع (إرسال قيم سمة LDAP كمطالبات):

- إختيار مخزن السمات كActive Directory

- تعيين سمة LDAP User-Principal-Name               إلى user_principal (الحروف الصغيرة)

- أختر سمة LDAP التي يجب إستخدامها ك userId لمستخدمي التطبيق لتسجيل الدخول وتخطيطه إلى uid(الحروف الصغيرة)

مثال على التكوين عند SamAccountName هو أن يتم إستخدامه كمعرف مستخدم:

- تعيين سمة LDAP SamAccountName               إلى uid.

- تعيين سمة LDAP User-Principal-Name               إلى user_principal.

مثال التكوين عندما يجب إستخدام UPN كمعرف مستخدم:

- تعيين سمة LDAP User-Principal-Name               إلى uid.

- تعيين سمة LDAP User-Principal-Name               إلى user_principal.

مثال على التكوين عند PhoneNumber يجب إستخدامه كمعرف المستخدم:

- تعيين سمة LDAP telephoneNumber               إلى uid.

- تعيين سمة LDAP User-Principal-Name               إلى user_principal.

ملاحظة: يجب التأكد من تطابق سمة LDAP التي تم تكوينها لمعرف المستخدم في مزامنة CUCM LDAP مع ما تم تكوينه كسمة LDAP ل uid في NameID لقاعدة مطالبة ADFS. هذا من أجل الوظيفة المناسبة لتسجيل دخول CUIC و Finesse.

ملاحظة: يشير هذا المستند إلى القيود المفروضة على اسم قاعدة المطالبة وأسماء العرض مثل NameID و FQDN ل UCCX وما إلى ذلك. وعلى الرغم من إمكانية تطبيق الحقول والأسماء المخصصة على مختلف الأقسام، فإن أسماء قواعد المطالبات وأسماء العرض تبقى قياسية طوال الوقت من أجل المحافظة على الاتساق وعلى أفضل الممارسات في قاعدة التسمية.

قاعدة المطالبة الثانية:

- أضف قاعدة أخرى من نوع قاعدة مطالبة مخصصة بالاسم كاسم المضيف المؤهل بالكامل لخادم تعريف Cisco وأضف نص القاعدة هذا.

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 الأساسية أو عقدة الناشر.

- ويعتبر <emQualified name لخادم تعريف Cisco> حساسا لحالة الأحرف، لذلك فإنه يتطابق تماما (في الحالة المضمنة) مع FQDN لخادم هوية Cisco.

- <ADFS Server FQDN> حساس لحالة الأحرف، لذلك فإنه يطابق (الحالة المضمنة) تماما مع ADFS FQDN.

الخطوة 8. انقر بزر الماوس الأيمن فوق ثقة الطرف المعتمد ثم انقر فوق Properties واختيار advanced علامة تبويب.

الخطوة 9. كما هو موضح في الصورة، أختر SHA على هيئة SHA-256.

الخطوة 10. انقر OK.

هذه الخطوات إلزامية بعد الخطوة 10.

تمكين تأكيدات SAML الموقعة لثقة الطرف المعتمد (معرفات Cisco)

الخطوة 1. انقر Start وأدخل PowerShell لفتح Windows Powershell.

الخطوة 2. إضافة ADFS CmdLet إلى PowerShell باستخدام الأمر Add-PSSnapin Microsoft.Adfs.Powershell.

الخطوة 3. قم بتشغيل الأمر، Set-ADFSRelyingPartyTrust -TargetName

-SamlResponseSignature "MessageAndAssertion"

.

ملاحظة: لا حاجة إلى الخطوة 2. إذا كنت تستخدم ADFS 3.0 لأن CmdLet مثبت بالفعل كجزء من إضافة الأدوار والميزات.

ملاحظة:

حساسة لحالة الأحرف، لذلك تتطابق (الحالة المضمنة) مع ما تم تعيينه في علامة التبويب "معرف" لخصائص "ثقة الطرف المعول".

ملاحظة: من UCCX، الإصدار 12.0 من معرفات Cisco تدعم SHA-256. وتستخدم ثقة الطرف المعول SHA-256 لتوقيع طلب SAML وتتوقع نفس الاستجابة من ADFS.

لتكوين متعدد المجالات ل ADFS المتحد

في حالة الاتحاد في ADFS، حيث توفر ADFS في مجال معين مصادقة SAML الموحدة للمستخدمين في مجالات أخرى تم تكوينها، تكون هذه التكوينات إضافية مطلوبة.

بالنسبة لهذا القسم، يشير مصطلح ADFS الأساسي إلى ADFS التي يجب إستخدامها في المعرفات. يشير مصطلح ADFS المتحد إلى ADFS، والتي يمكن لمستخدميها تسجيل الدخول من خلال معرفات وبالتالي، تكون ADFS الأساسية.

تكوين ADFS المتحد

وفي كل من هذه المكاتب، يجب إنشاء صندوق ثقة الطرف المعول من أجل قواعد المطالبات الرئيسية وقواعد المطالبات التي تم تكوينها على النحو المذكور في الفرع السابق.

تكوين ADFS الأساسي

بالنسبة ل ADFS الأساسية، بخلاف "ثقة الطرف المعتمد" بالمعرفات، يلزم هذا التكوين الإضافي.

إضافة Claim Provider Trust باستخدام ADFS التي يجب إعداد الاتحاد لها.

في ثقة موفر المطالبات، تأكد من أن Pass through or Filter an Incoming Claim يتم تكوين القواعد مع تمرير كافة قيم المطالبات كخيار:

- معرف الاسم

- أختر معرف الاسم من Incoming Claim Type صندوق الإسقاط

- نختار Transient كخيار لتنسيق NameID الوارد

- UID: هذه مطالبة مخصصة. أدخل معرف القيمة في Incoming Claim Type صندوق الإسقاط

- user_principal: هذه مطالبة مخصصة. اكتب value user_principal في Incoming Claim Type صندوق الإسقاط

في ثقة جهة الاعتماد بالمعرفات، أضف Pass though or Filter an Incoming Claim قواعد مع تمرير كافة قيم المطالبات كخيار.

- NameIDFromSubdomain

- إختيار معرف الاسم من Incoming Claim Type صندوق الإسقاط

- نختار Transient كخيار لتنسيق NameID الوارد

- UID: هذه مطالبة مخصصة. اكتب معرف القيمة في Incoming Claim Type صندوق الإسقاط

- user_principal: هذه مطالبة مخصصة. اكتب value user_principal في Incoming Claim Type صندوق الإسقاط

التبديل التلقائي للشهادة ADFS

يتم دعم التمرير التلقائي للشهادة ل UCCX 11.6.1 والإصدارات الأحدث. (ساعدت ترقية مكتبة Fedlet إلى الإصدار 14.0 في UCCX 11.6 على حل هذه المشكلة.)

مصادقة Kerberos (مصادقة Windows المتكاملة)

توفر مصادقة Windows المتكاملة (IWA) آلية لمصادقة المستخدمين لكنها لا تسمح بإرسال بيانات الاعتماد عبر الشبكة. عند تمكين مصادقة Windows المتكاملة، فإنه يعمل على أساس التذاكر للسماح للعقد بالتواصل عبر شبكة غير آمنة لإثبات هويتها لبعضها البعض بطريقة آمنة. وهو يمكن المستخدمين من تسجيل الدخول إلى مجال بعد تسجيل الدخول إلى أجهزة Windows الخاصة بهم.

ملاحظة: مصادقة Kerberos مدعومة فقط من الإصدار 11.6 والإصدارات الأحدث.

يتم تسجيل دخول مستخدمي المجال الذين قاموا بالفعل بتسجيل دخولهم إلى وحدة التحكم بالمجال (DC) إلى عملاء SSO بسلاسة دون الحاجة إلى إعادة إدخال بيانات الاعتماد. بالنسبة للمستخدمين من غير المجالات، يرجع IWA إلى New Technology Local Area Network Manager (NTLM) ويظهر مربع حوار تسجيل الدخول. يتم إجراء التأهيل للمعرفات باستخدام مصادقة IWA باستخدام Kerberos مقابل ADFS 3.0.

الخطوة 1. افتح موجه أوامر Windows وقم بالتشغيل كمستخدم مسؤول لتسجيل خدمة HTTP مع setspn  setspn -s http/

\

.

الخطوة 2. تعطيل مصادقة النموذج وتمكين مصادقة Windows لمواقع إنترانت. انتقل إلى ADFS Management > Authentication Policies > Primary Authentication > Global Settings > Edit. تحت إنترانت، تأكد من التحقق من مصادقة Windows فقط (قم بإلغاء تحديد مصادقة النموذج).

تكوين Microsoft Internet Explorer لدعم IWA

الخطوة 1. تأكد من Internet Explorer > Advanced > Enable Integrated Windows Authentication تم تحديده.

الخطوة 2. يجب إضافة عنوان URL ل ADFS إلى Security > Intranet zones > Sites  (winadcom215.uccx116.com هو عنوان URL الخاص ب ADFS).

الخطوة 3. تأكد منInternet Explorer > Security > Local Intranet > Security Settings > User Authentication - Logon  من أجل إستخدام بيانات اعتماد تسجيل الدخول لمواقع إنترانت.

يلزم توفر التهيئة لبرنامج Mozilla Firefox لدعم تقنية IWA

الخطوة 1. دخلت التشكيل أسلوب ل Firefox. فتح Firefox والدخول about:config  في URL. قبول بيان المخاطر.

الخطوة 2. البحث عن ntlm  وتمكين network.automatic-ntlm-auth.allow-non-fqdn  ووضعها على حقيقتها.

الخطوة 3. تعيين network.automatic-ntlm-auth.trusted-uris  للمجال أو بشكل صريح عنوان URL الخاص ب ADFS.

يلزم توفر التكوين ل Google Chrome لدعم IWA

يستخدم Google Chrome الموجود في Windows إعدادات Internet Explorer، لذا قم بالتكوين داخل Internet Explorer Tools > Internet Options حوار، أو من لوحة التحكم تحت Internet Options ضمن الفئة الفرعية Network and Internet.

مزيد من التكوين ل SSO

يصف هذا وثيقة التشكيل من ال IDp جانب ل SSO in order to تكامل مع ال cisco id. لمزيد من التفاصيل، ارجع إلى أدلة تكوين المنتج الفردي:

- UCCX

- UCCE

- PCCE

التحقق من الصحة

يستخدم هذا الإجراء لتحديد ما إذا كان قد تم إنشاء ثقة الطرف المعول بشكل صحيح بين معرفات Cisco و IDP.

- من Broswer أدخل عنوان URL https://<ADFS_FQDN>/adfs/ls/IdpInitiatedSignOn.aspx؟loginToRp=<IDS_FQDN>

- توفر ADFS نموذج تسجيل الدخول. ويكون هذا الإجراء متاحا عندما يكون التكوين المذكور صحيحا.

- في المصادقة الناجحة، يجب إعادة توجيه المستعرض إلى https://<IDS_FQDN>:8553/IDS/saml/response، وتظهر صفحة قائمة إختيار.

ملاحظة: صفحة القائمة المرجعية التي تظهر كجزء من عملية التحقق ليست خطأ وإنما تأكيد على إنشاء الثقة بشكل صحيح.

استكشاف الأخطاء وإصلاحها

لاستكشاف الأخطاء وإصلاحها، ارجع إلى https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200662-ADFS-IdS-Troubleshooting-and-Common-Prob.html.

عناوين URL إسترداد/تجاوز UCCX SSO

- إدارة CCX الموحدة من Cisco

- خدمة CCX الموحدة من Cisco

تعطيل SSO

- واجهة المستخدم الرسومية (GUI): انتقل إلى CCX Administration > Single Sign-On (SSO) > Disable.

- CLI: set authmode non_sso (يجب أن يقوم هذا الأمر بتعطيل SSO لكل من PUB و Sub - يمكن تنفيذه من أي من عقد UCCX في حالة وجود مجموعة عالية التوفر (HA)).

مسامير لولبية

إدارة CCX - NON_SSO

إدارة CCX - تمكين SSO

تسجيل دخول Finesse - بخلاف SSO

تسجيل دخول Finesse - تمكين SSO

CUIC - non_SSO

CUIC - تمكين SSO