כניסה יחידה ורכזת בקרה

כניסה יחידה (SSO) היא הפעלה או תהליך אימות משתמש המאפשר למשתמש לספק אישורים כדי לגשת לאפליקציה אחת או יותר. התהליך מאמת את המשתמשים עבור כל האפליקציות שקיבלו זכויות עליהן. זה מבטל הנחיות נוספות כאשר משתמשים מחליפים יישומים במהלך הפעלה מסוימת.

פרוטוקול הפדרציה של Security Assertion Markup Language (SAML 2.0) משמש כדי לספק אימות SSO בין ענן Webex לבין ספק הזהות שלך (IdP).

פרופילים

אפליקציית Webex תומכת רק בפרופיל SSO של דפדפן האינטרנט. בפרופיל ה- SSO של דפדפן האינטרנט, Webex App תומכת בקשרים הבאים:

  • SP יזם POST -> POST binding

  • SP יזם REDIRECT -> כריכת פוסט

פורמט NameID

פרוטוקול SAML 2.0 תומך במספר פורמטים של NameID לתקשורת על משתמש ספציפי. Webex App תומכת בפורמטים הבאים של NameID.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

במטא נתונים שאתה טוען מה-IDP שלך, הערך הראשון מוגדר לשימוש ב- Webex.

התנתקות יחידה

יישום Webex תומך בפרופיל ההתנתקות היחידה. ביישום Webex, משתמש יכול לצאת מהיישום, שמשתמש בפרוטוקול ההתנתקות היחידה של SAML כדי לסיים את ההפעלה ולאשר את היציאה הזו עם ה-IdP שלך. ודא ש-IdP שלך מוגדר עבור SingleLogout.

שלב Control Hub עם ADFS


 

מדריכי התצורה כוללים דוגמה ספציפית לשילוב SSO אך אינם מספקים הגדרות לקביעת תצורה לכל האפשרויות. לדוגמה, השלבים לתהליך השילוב עבור nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient מתועדים. פורמטים אחרים כגון urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress יעבדו עבור שילוב SSO אבל אינם כלולים בתיעוד שלנו.

הגדר אינטגרציה זו עבור משתמשים בארגון Webex שלך (כולל Webex App, Webex Meetings ושירותים אחרים המנוהלים ב-Control Hub). אם אתר Webex שלך משולב ב-Control Hub, אתר Webex יורש את ניהול המשתמשים. אם אינך יכול לגשת ל- Webex Meetings בדרך זו והוא אינו מנוהל ב-Control Hub, עליך לבצע אינטגרציה נפרדת כדי לאפשר SSO עבור Webex Meetings. (ראה הגדר כניסה יחידה עבור Webex למידע נוסף בשילוב SSO בניהול ניהול אתר.)

בהתאם למה שהוגדר במנגנוני האימות ב-ADFS, ניתן להפעיל אימות חלונות משולב (IWA) כברירת מחדל. אם האפשרות מופעלת, יישומים שמופעלים דרך Windows (כגון יישום Webex ו-Cisco Directory Connector) מאמתים כמשתמש שנכנס, ללא קשר לכתובת הדוא"ל המוזנת במהלך שורת הדוא"ל הראשונית.

הורד את המטא נתונים של Webex למערכת המקומית שלך

1

ממבט הלקוח פנימהhttps://admin.webex.com , עבור אל ניהול > הגדרות ארגון , ולאחר מכן גלול אל אימות , ולאחר מכן הפעל את כניסה יחידה הגדרה כדי להפעיל את אשף ההגדרה.

2

בחר את סוג האישור עבור הארגון שלך:

  • חתום עצמי על ידי Cisco -אנו ממליצים על בחירה זו. תנו לנו לחתום על התעודה כך שתצטרכו לחדש אותו רק פעם בחמש שנים.
  • חתום על ידי רשות תעודות ציבורית — מאובטח יותר אבל תצטרך לעדכן את המטא נתונים לעתים קרובות (אלא אם ספק ה-IDP שלך תומך בעוגני אמון).

 

עוגני אמון הם מפתחות ציבוריים הפועלים כסמכות לאימות אישור של חתימה דיגיטלית. למידע נוסף, עיין בתיעוד ה-IDP שלך.

3

הורד את קובץ המטא נתונים.

שם קובץ המטא-נתונים של Webex הוא idb-meta-<org-ID> -SP.xml .

התקן מטה-נתונים של Webex ב-ADFS

לפני שתתחיל

Control Hub תומך ב-ADFS 2.x ואילך.

Windows 2008 R2 כולל רק ADFS 1.0. עליך להתקין לפחות ADFS 2.x מ-Microsoft.

עבור שירותי SSO ו-Webex, ספקי הזהויות (IdPs) חייבים להתאים למפרט הבא של SAML 2.0:

  • הגדר את התכונה תבנית NameID באופן הבא urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • קבע תצורה של טענה ב-IdP כך שתכלול את שם התכונה uid עם ערך שממופה לתכונה שנבחרה במחבר ספר הטלפונים של Cisco או לתכונת המשתמש התואמת לזו שנבחרה בשירות הזהויות של Webex. (למשל, תכונה זו יכולה להיות כתובות דוא"ל או השם העיקרי של המשתמש (UPN).) עיין במידע על התכונה המותאמת אישית ב-https://www.cisco.com/go/hybrid-services-directory לקבלת הדרכה.

1

היכנס לשרת ADFS עם הרשאות מנהל.

2

פתח את מסוף הניהול של ADFS וגלוש אל יחסי אמון > הסתמכות על נאמנויות המפלגה > הוסף אמון צד להסתמך.

3

בחלון אשף הוספת אמון צד סומך, בחר התחל.

4

עבור מקור נתונים בחר ייבוא נתונים על הצד הנתמך מקובץ, עיין בקובץ המטה-נתונים של Control Hub שהורדת ובחר ב-Next.

5

עבור ציין שם תצוגה, צור שם תצוגה עבור אמון צד זה להסתמך על אמון זה, כגון Webex ובחר הבא.

6

עבור בחירת כללי הרשאת הנפקה, בחר אפשר לכל המשתמשים לגשת לצד ההסתמכות הזה ובחר הבא.

7

עבור המוכן להוספת אמון, בחר הבא ולסיים להוסיף את האמון להסתמך ל-ADFS.

צור כללי תביעה עבור אימות Webex

1

בחלונית ADFS הראשית, בחר את יחסי האמון שיצרת ולאחר מכן בחר ערוך כללי תביעות. בלשונית 'כללי המרה של הנפקה', בחר הוסף כלל.

2

בשלב 'בחר סוג כלל', בחר 'שלח תכונות LDAP כ'תביעות, ולאחר מכן בחר הבא.

  1. הזן שם כלל דרישת בעלות.

  2. בחר ב-Active Directory כ-Attribute Store.

  3. מפה את תכונת כתובת הדוא"ל - LDAP לסוג דרישת בעלות יוצאות של uid.

    כלל זה אומר ל-ADFS אילו שדות יש למפות ל-Webex כדי לזהות משתמש. איית סוגי דרישת הבעלות היוצאות בדיוק כפי שמוצג.

  4. שמור את השינויים.

3

בחר הוסף כלל שוב, בחר שלח תביעות באמצעות כלל מותאם אישית, ולאחר מכן בחר הבא.

כלל זה מספק ל-ADFS את התכונה "מוסמכת spname" ש-Webex לא מספק אחרת.

  1. פתח את עורך הטקסט והעתק את התוכן הבא.

    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"] = "URL1", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "URL2");

    החלף את URL1 ו-URL2 בטקסט באופן הבא:

    • כתובת URL1 היא ה-entityID מקובץ המטה-נתונים של ADFS שהורדת.

      לדוגמה, להלן דוגמה של מה שאתה רואה: <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://ad0a.identitylab20.ciscolabs.com/adfs/services/trust" ID="_55515dde-8147-4183-8a85-b704d26b5dba">

      העתק רק את ה-entityID מקובץ המטה-נתונים של ADFS והדבק אותו בקובץ הטקסט כדי להחליף את ה-URL1

    • URL2 מופיע בשורה הראשונה בקובץ המטה-נתונים של Webex שהורדת.

      לדוגמה, להלן דוגמה של מה שאתה רואה: <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID=" https://idbroker.webex.com/35a15b0a-0eg1-4029-9f63-a8c54df5df59">

      העתק רק את ה-entityID מקובץ המטה-נתונים של Webex והדבק אותו בקובץ הטקסט כדי להחליף את URL2.

  2. עם כתובות ה-URL המעודכנות, העתק את הכלל מעורך הטקסט (החל מ-"C:") והדבק אותו בתיבת הכלל המותאמת אישית בשרת ה-ADFS שלך.

    החוק השלם אמור להיראות כך:

  3. בחר סיום כדי ליצור את הכלל, ולאחר מכן צא מהחלון 'ערוך כללי דרישת בעלות'.

4

בחר להסתמך על אמון צד בחלון הראשי, ולאחר מכן בחר מאפיינים בחלונית הימנית.

5

כאשר מופיע חלון 'מאפיינים', עיין בלשונית המתקדם , SHA-256 ולאחר מכן בחר אישור כדי לשמור את השינויים.

6

עיין בכתובת ה-URL הבאה בשרת ה-ADFS הפנימי כדי להוריד את הקובץ: https://<AD_FS_Server>/FederationMetadata/2007-06/FederationMetadata.xml


 

ייתכן שיהיה עליך ללחוץ ימנית על הדף ולהציג את מקור הדף כדי לקבל את קובץ ה-XML המעוצב כראוי.

7

שמור את הקובץ במחשב המקומי שלך.

מה הלאה?

אתה מוכן לייבא את המטה-נתונים של ADFS בחזרה אל Webex מפורטל הניהול.

ייבא את המטא נתונים של IdP והפעל כניסה יחידה לאחר בדיקה

לאחר ייצוא המטא נתונים של Webex , הגדרת ה-IDP שלך והורדת המטא נתונים של IdP למערכת המקומית שלך, אתה מוכן לייבא אותם לארגון ה- Webex שלך מ-Control Hub.

לפני שתתחיל

אל תבדוק שילוב SSO מממשק ספק הזהות (IdP). אנו תומכים רק בזרימות יזומות של ספק שירות (יזום SP), לכן עליך להשתמש במבחן Control Hub SSO עבור שילוב זה.

1

בחר אחד:

  • חזור למרכז הבקרה - דף בחירת אישור בדפדפן שלך, ולאחר מכן לחץ הבא .
  • אם Control Hub כבר לא פתוח בכרטיסיית הדפדפן, מתצוגת הלקוח פנימהhttps://admin.webex.com , עבור אל ניהול > הגדרות ארגון , גלול אל אימות , ולאחר מכן בחר פעולות > ייבוא מטא נתונים .
2

בדף ייבוא מטה-נתונים של IdP , גרור ושחרר את קובץ המטא נתונים של IdP אל הדף או השתמש באפשרות דפדפן הקבצים כדי לאתר ולהעלות את קובץ המטא נתונים. לחץ על הבא.

כדאי להשתמש ב בטוח יותר אפשרות, אם אתה יכול. זה אפשרי רק אם ה-IDP שלך השתמש ב-CA ציבורי כדי לחתום על המטא נתונים שלו.

בכל שאר המקרים, עליך להשתמש ב- פחות בטוח אפשרות. זה כולל אם המטא נתונים אינם חתומים, חתומים בעצמם או חתומים על ידי CA פרטי.


 

Okta לא חותם על המטא נתונים, אז אתה חייב לבחור פחות בטוח עבור שילוב Okta SSO .

3

בחר בדוק את הגדרת SSO , וכאשר נפתחת כרטיסיית דפדפן חדשה, בצע אימות עם ה-IDP על ידי כניסה.


 

אם אתה מקבל שגיאת אימות ייתכן שיש בעיה עם האישורים. בדוק את שם המשתמש והסיסמה ונסה שוב.

שגיאת Webex App פירושה בדרך כלל בעיה בהגדרת SSO . במקרה זה, עברו שוב על השלבים, במיוחד השלבים שבהם אתם מעתיקים ומדביקים את המטא-נתונים של Control Hub להגדרת IdP.


 

כדי לנסות בעצמך את חוויית הכניסה עם SSO, אתה יכול גם ללחוץ על העתקת URL ללוח ממסך זה ולהדביק אותו בחלון דפדפן פרטי. משם תוכל לפעול על פי השלבים לכניסה באמצעות SSO. שלב זה מפסיק תוצאות חיוביות כוזבות בגלל אסימון גישה שעשוי להיות בהפעלה קיימת לאחר הכניסה שלך.

4

חזור לכרטיסיית הדפדפן Control Hub.

  • אם הבדיקה הצליחה, בחר מבחן מוצלח. הפעל SSO ולחץ הבא .
  • אם הבדיקה לא הצליחה, בחר בדיקה לא מוצלחת. כבה את SSO ולחץ הבא .

 

תצורת ה- SSO לא תיכנס לתוקף בארגון שלך אלא אם תבחר לחצן בחירה הבחירה הראשון והפעלת SSO.

מה הלאה?

השתמש בהליכים ב סנכרן את משתמשי Okta לתוך Cisco Webex Control Hub אם ברצונך לבצע הקצאת משתמשים מתוך Okta לענן Webex .

השתמש בהליכים ב סנכרן משתמשי Azure נוכחות פעילה לתוך Cisco Webex Control Hub אם ברצונך לבצע הקצאת משתמש מתוך Azure AD לענן Webex .

אתה יכול לעקוב אחר הנוהל ב דחק הודעות דוא"ל אוטומטיות כדי להשבית הודעות דוא"ל שנשלחות למשתמשי Webex App חדשים בארגון שלך. המסמך מכיל גם שיטות מומלצות לשליחת תקשורת למשתמשים בארגון שלך.

עדכן את אמון הצד המסתמך של Webex ב-ADFS

משימה זו עוסקת במיוחד בעדכון ADFS עם מטא נתונים חדשים של SAML מ- Webex. יש מאמרים קשורים אם אתה צריך להגדיר SSO עם ADFS , או אם אתה צריך עדכן (שונה) IdP עם מטא נתונים של SAML עבור אישור Webex SSO חדש .

לפני שתתחיל

עליך לייצא את קובץ המטא נתונים של SAML מ-Control Hub לפני שתוכל לעדכן את Webex Party Trust ב-ADFS.

1

היכנס לשרת ADFS עם הרשאות מנהל.

2

העלה את קובץ המטא נתונים של SAML מ- Webex לתיקיה מקומית זמנית בשרת ADFS, למשל. //ADFS_servername/temp/idb-meta-<org-ID>-SP.xml.

3

פתח את Powershell.

4

הפעל Get-AdfsRelyingPartyTrust לקרוא את כל הנאמנויות של הצדדים המסתמכים.

שימו לב ל TargetName פרמטר של אמון הצד המסתמך של Webex . אנו משתמשים בדוגמה "Webex" אבל זה יכול להיות שונה ב-ADFS שלך.

5

הפעל Update-AdfsRelyingPartyTrust -MetadataFile "//ADFS_servername/temp/idb-meta-<org-ID>-SP.xml" -TargetName "Webex".

הקפד להחליף את שם הקובץ ושם היעד בערכים הנכונים מהסביבה שלך.

ראהhttps://docs.microsoft.com/powershell/module/adfs/update-adfsrelyingpartytrust .

 

אם הורדתם את אישור Webex SP 5 שנים והפעלתם ביטול אישור חתימה או הצפנה, עליכם להפעיל את שתי הפקודות הבאות: Set-AdfsRelyingPartyTrust -SigningCertificateRevocationCheck None -EncryptionCertificateRevocationCheck None -TargetName "Webex".

6

היכנס ל-Control Hub ולאחר מכן בדוק את שילוב SSO :

  1. עבור אל ניהול > הגדרות ארגון , גלול אל אימות , והפעל את ה- כניסה יחידה הגדרה כדי להפעיל את אשף התצורה.

  2. לחץ הבא כדי לדלג על דף ייבוא מטה-נתונים של IdP .

    אינך צריך לחזור על השלב הזה, מכיוון שייבאת בעבר את המטא נתונים של IdP.

  3. בדוק את חיבור ה- SSO לפני שתפעיל אותו. שלב זה פועל כמו הרצה יבשה ואינו משפיע על הגדרות הארגון שלך עד שתפעיל את האפשרות SSO בשלב הבא.


     

    כדי לנסות בעצמך את חוויית הכניסה עם SSO, אתה יכול גם ללחוץ על העתקת URL ללוח ממסך זה ולהדביק אותו בחלון דפדפן פרטי. משם תוכל לפעול על פי השלבים לכניסה באמצעות SSO. הליך זה עוזר להסיר מידע השמור בדפדפן האינטרנט שלך שעלול לספק תוצאה חיובית שגויה בעת בדיקת התצורה של ה-SSO.

  4. היכנס כדי להשלים את הבדיקה.

פתרון בעיות של ADFS

שגיאות ADFS ביומני Windows

ביומני הרישום של Windows, ייתכן שתראה קוד שגיאה 364 של יומן ADFS. פרטי האירוע מזהים אישור לא חוקי. במקרים אלה, מארח ADFS אינו מורשה לעבור דרך חומת האש ביציאה 80 כדי לאמת את האישור.

אירעה שגיאה במהלך ניסיון לבנות את שרשרת התעודות עבור אמון הצד הנתמך

בעת עדכון תעודת SSO, ייתכן שתוצג לך שגיאה זו בעת הכניסה: Invalid status code in response.

אם אתה רואה את השגיאה הזו, בדוק את יומני הרישום של מציג האירועים בשרת ה-ADFS וחפש את השגיאה הבאה: An error occurred during an attempt to build the certificate chain for the relying party trust 'https://idbroker.webex.com/<org-ID>' certificate identified by thumbprint '754B9208F1F75C5CC122740F3675C5D129471D80'. גורמים אפשריים הם שהאישור בוטל, לא ניתן לאמת את שרשרת האישורים כפי שצוין על ידי הגדרות ביטול תעודת ההצפנה של אמון הצד המסתמך, או שהאישור אינו בתקופת התוקף שלו.

אם שגיאה זו מתרחשת, עליך להפעיל את הפקודות Set-ADFSRelyingPartyTrust -TargetIdentifier https://idbroker.webex.com/<orgID> -EncryptionCertificateRevocationCheck None

מזהה איחוד

מזהה הפדרציה הוא תלוי רישיות. אם זוהי כתובת הדוא"ל הארגונית שלך, הזן אותה בדיוק כפי ש-ADFS שולח אותה, או ש-Webex לא יכול למצוא את המשתמש המתאים.

לא ניתן לכתוב כלל דרישת בעלות מותאמת אישית כדי לנרמל את תכונת LDAP לפני שהיא תישלח.

יבא את המטה-נתונים שלך משרת ה-ADFS שהגדרת בסביבה שלך.

באפשרותך לאמת את כתובת ה-URL במידת הצורך על-ידי ניווט אל שירות >> נקודות קצה >> מטה-נתונים >> סוג:מטה-נתונים של הפדרציה בניהול ADFS.

סנכרון זמן

ודא ששעון המערכת של שרת ADFS מסונכרן למקור זמן אמין באינטרנט המשתמש בפרוטוקול הזמן ברשת (NTP). השתמש בפקודה הבאה של PowerShell כדי להטות את השעון עבור יחסי האמון של Webex להסתמך על Webex.

Set-ADFSRelyingPartyTrust -TargetIdentifier "https://idbroker.webex.com/$ENTITY_ID_HEX_VALUE" -NotBeforeSkew 3

הערך הקסדצימלי הוא ייחודי לסביבה שלך. החלף את הערך מערך מזהה ה-SP EntityDescriptor בקובץ המטה-נתונים של Webex. לדוגמה:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID=" https://idbroker.webex.com/c0cb726f-a187-4ef6-b89d-46749e1abd7a">