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

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

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

פרופילים

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

  • SP יזם POST -> איגוד POST

  • SP יזם ניתוב מחדש -> איגוד POST

תבנית NameID

פרוטוקול SAML 2.0 תומך במספר תבניות NameID לתקשורת על משתמש ספציפי. אפליקציית Webex תומכת בתבניות 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 App, משתמש יכול לצאת מהאפליקציה, המשתמשת בפרוטוקול התנתקות יחיד SAML כדי לסיים את ההפעלה ולאשר את ההתנתקות באמצעות ה- IdP שלך. ודא שה-IDP שלך מוגדר עבור SingleLogout.

שילוב מרכז הבקרה עם 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 ושירותים אחרים המנוהלים במרכז הבקרה). אם אתר Webex שלך משולב ב- Control Hub, אתר Webex יורש את ניהול המשתמשים. אם אינך מצליח לגשת לפגישות Webex בדרך זו והוא אינו מנוהל ב - Control Hub, עליך לבצע שילוב נפרד כדי להפוך את SSO לזמין עבור פגישותWebex.

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

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

1

היכנס למרכז הבקרה.

2

עבור אל ניהול > אבטחה > אימות.

3

עבור אל הכרטיסייה ספק זהויות ולחץ על הפעל SSO.

4

בחר ספק זיהוי אישי (IdP).

5

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

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

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

6

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

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

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

לפני שתתחיל

מרכז הבקרה תומך ב-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:חוֹלֵף

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

1

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

2

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

3

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

4

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

5

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

6

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

7

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

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

1

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

2

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

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

  2. בחר את Active Directory כמאגר המאפיינים.

  3. מפה את התכונה LDAP E-mail-Addresses לסוג התביעה היוצאת uid.

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

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

3

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

כלל זה מספק ל-ADFS את התכונה "spname qualifier" ש-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 שהורדת.

      לדוגמה, להלן דוגמה למה שאתם רואים: http://ad0a.identitylab20.ciscolabs.com/adfs/services/trust" ID="_55515dde-8147-4183-8a85-b704d26b5dba">

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

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

      לדוגמה, להלן דוגמה למה שאתם רואים: https://idbroker.webex.com/35a15b0a-0eg1-4029-9f63-a8c54df5df59">

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

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

    הכלל המלא אמור להיראות כך:

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

4

בחר Relying Party Trust בחלון הראשי, ולאחר מכן בחר Properties בחלונית הימנית.

5

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

6

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

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

7

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

מה הלאה?

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

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

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

לפני שתתחיל

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

1

בחר אחד:

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

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

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

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

Okta לא חותמת על המטא-דאטה, לכן עליך לבחור פחות מאובטח עבור שילוב Okta SSO.

3

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

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

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

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

4

חזור לכרטיסיה דפדפן מרכז הבקרה.

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

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

מה הלאה?

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

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

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

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

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

לפני שתתחיל

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

1

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

2

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

3

פתח את Powershell.

4

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

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

5

רוץ Update-AdfsRelyingPartyTrust -MetadataFile "//ADFS_servername/temp/idb-meta--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. בכרטיסייה ספק זהויות, עבור אל ספק הזהויות ולחץ על תפריט 'עוד'

  3. בחר בדיקת IdP.

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

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

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

פתרון בעיות 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/' certificate identified by thumbprint '754B9208F1F75C5CC122740F3675C5D129471D80'. סיבות אפשריות הן שהאישור בוטל, לא ניתן היה לאמת את שרשרת האישורים כפי שצוין על ידי הגדרות ביטול אישור ההצפנה של אמון הצד המסתמך, או שהאישור אינו בתוקף.

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

מזהה הפדרציה

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

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

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

ניתן לאמת את כתובת האתר במידת הצורך על ידי ניווט אל שירות > נקודות קצה > מטא-נתונים > Type:Federation מטא-נתונים בניהול ADFS.

סנכרון זמן

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

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

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