פתרון בעיות בכניסה יחידה (SSO)

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

הגדרה והפעלה

"הדומיין הזה לא מוגדר לשימוש בכניסה יחידה".

השגיאה הזו בדרך כלל מציינת שאתם משתמשים בגרסה של Google Workspace שלא תומכת ב-SSO (כמו מהדורת G Suite החינמית מדור קודם). כל מהדורות Workspace הנוכחיות תומכות ב-SSO באמצעות ספק זהויות (IdP) של צד שלישי.

אם אתם משתמשים במהדורה של Google Workspace שתומכת ב-SSO, נסו את הפתרונות האחרים האלה:

  • מוודאים שבהגדרת ה-SSO של ספק הזהויות מוגדר שם הדומיין הנכון של Google Workspace.
  • אם השגיאה הזו מופיעה אחרי שמגדירים פרופילי SSO, יכול להיות שספק הזהויות מוגדר לשלוח את טענת הנכוֹנוּת (assertion) של SAML לנקודת הקצה של פרופיל ה-SSO הקודם. אם נקודת הקצה של ה-SSO מדור קודם מוטמעת ב-IdP שלכם בקידוד קשיח, צריך לבצע את הפעולות הבאות:
    1. מגדירים פרופיל SSO מדור קודם.
    2. צריך לבקש מספק ה-IdP לעדכן את השילוב שלו עם Google.

"אין אפשרות לגשת לחשבון הזה כי הדומיין לא מוגדר כהלכה. אפשר לנסות שוב אחר כך".

השגיאה הזו מציינת שלא הגדרתם נכון את ה-SSO במסוף Google Admin. כדי לתקן את המצב, מבצעים את הפעולות הבאות:

  1. במסוף Admin, עוברים אל אבטחה ואזהגדרת כניסה יחידה (SSO) באמצעות ספק זהויות של צד שלישי ומסמנים את האפשרות הגדרת כניסה יחידה (SSO) באמצעות ספק זהויות של צד שלישי.
  2. בשדות המתאימים, מציינים את כתובות ה-URL של דף הכניסה, דף היציאה ודף שינוי הסיסמה של הארגון.
  3. בוחרים ומעלים קובץ אישור אימות תקין.
  4. לוחצים על שמירה, מחכים כמה דקות עד שהשינויים ייכנסו לתוקף ומנסים שוב את השילוב.

דייר Google שהוגדר עם קידומת אסורה

באפליקציות ל-iOS, כשכתובת ה-URL של דף הכניסה ל-SSO מתחילה ב-'google.'. (או וריאציה כלשהי), אפליקציית Google ל-iOS מופנית ל-Safari. כתוצאה מכך, תהליך הכניסה באמצעות SSO נכשל. הרשימה המלאה של התחיליות האסורות:

  • googl.
  • google.
  • www.googl.
  • www.google.

תצטרכו לשנות את כתובות ה-URL של דפי הכניסה באמצעות SSO שכוללות את הקידומות האלה.

ניתוח תגובת ה-SAML

‫"The required response parameter SAMLResponse was missing"

הודעת השגיאה הזו מציינת שספק הזהויות שלכם לא מספק ל-Google תשובת SAML תקינה כלשהי. הבעיה הזו כמעט בוודאות נובעת מבעיה בהגדרות של ספק הזהויות.

  • בודקים את היומנים של ספק הזהויות ומוודאים שאין שום דבר שמונע ממנו להחזיר תגובת SAML בצורה תקינה.
  • מוודאים שספק הזהויות לא שולח ל-Google Workspace תגובת SAML מוצפנת. ‫Google Workspace מקבל רק תגובות SAML לא מוצפנות. חשוב במיוחד לציין ש-Active Directory Federation Services 2.0 של מיקרוסופט שולח לעיתים קרובות תשובות SAML מוצפנות בהגדרות ברירת המחדל.

‫"The required response parameter RelayState was missing"

במפרט של SAML 2.0 נדרש שספקי זהויות יאחזרו וישלחו בחזרה פרמטר של כתובת URL מסוג RelayState מספקי משאבים (כמו Google Workspace). ‫Google Workspace מספק את הערך הזה לספק הזהויות בבקשת SAML, והתוכן המדויק יכול להיות שונה בכל התחברות. כדי שהאימות יושלם בהצלחה, צריך להחזיר את הערך המדויק של RelayState בתגובת SAML. בהתאם למפרט התקן של SAML, ספק הזהויות לא אמור לשנות את RelayState במהלך תהליך הכניסה.

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

התוכן של תגובת SAML

"לא ניתן לגשת לשירות הזה מפני שבקשת ההתחברות כללה מידע לא חוקי ביחס ל-[destination|audience|recipient]. צריך להתחבר לחשבון ולנסות שוב".

השגיאה הזו מציינת שהרכיבים destination, ‏ audience או recipient בהצהרת SAML הכילו מידע לא תקין או היו ריקים. חובה לכלול את כל הרכיבים בהצהרת ה-SAML. בטבלאות הבאות שבמאמר דרישות טענת נכוֹנוּת (assertion) ב-SSO מופיעים תיאורים ודוגמאות לכל רכיב:

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

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

  1. כדי לאבחן את הבעיה הזו לעומק, צריך לצלם את כותרות ה-HTTP במהלך ניסיון התחברות.
  2. מחפשים את בקשת SAML ואת תגובת SAML בכותרות ה-HTTP.
  3. מוודאים שהערך של הנמען בתגובת SAML קיים ושהוא תואם לערך בבקשת SAML.

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

"לא ניתן לקבל גישה לחשבון הזה כי לא היתה אפשרות לאמת את אישורי הכניסה".

השגיאה הזו מעידה על בעיה באישורים שבהם אתם משתמשים כדי לחתום על תהליך האימות. בדרך כלל, המשמעות היא שהמפתח הפרטי ששימש לחתימה על תגובת SAML לא תואם לאישור המפתח הציבורי ששמור ב-Google Workspace.

השגיאה יכולה להתרחש גם אם תגובת ה-SAML לא מכילה שם משתמש תקין בחשבונות Google. ‫Google Workspace מנתח את תגובת SAML כדי למצוא רכיב XML שנקרא NameID, ומצפה שהרכיב הזה יכיל שם משתמש ב-Google Workspace או כתובת אימייל מלאה ב-Google Workspace.

  • מוודאים שהעליתם אישור תקין ל-Google Workspace, ואם צריך, מחליפים את האישור. במסוף Google Admin, עוברים אל אבטחה ואזהגדרת כניסה יחידה (SSO) באמצעות ספק זהויות של צד שלישי ולוחצים על החלפת אישור.
  • אם אתם משתמשים בכתובת אימייל מלאה ברכיב NameID (אתם חייבים לעשות זאת אם אתם משתמשים ב-SSO עם סביבת Apps מרובת דומיינים), ודאו שמאפיין Format של רכיב NameID מציין שיש להשתמש בכתובת אימייל מלאה, כמו בדוגמה הבאה: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress".
  • מוודאים שמאכלסים את הרכיב NameID בשם משתמש או בכתובת אימייל תקינים. כדי להיות בטוחים, כדאי לחלץ את תגובת ה-SAML שאתם שולחים ל-Google Workspace ולבדוק את הערך של רכיב NameID.
  • הערך של NameID הוא תלוי אותיות רישיות: צריך לוודא שתגובת SAML מאכלסת את NameID בערך שתואם לאותיות הרישיות של שם המשתמש או כתובת האימייל ב-Google Workspace.
  • אם ספק הזהויות מצפין את טענת הנכונות (assertion) ב-SAML, צריך להשבית את ההצפנה.
  • מוודאים שתגובת SAML לא כוללת תווים לא סטנדרטיים של ASCII. הבעיה הזו מתרחשת בדרך כלל במאפיינים DisplayName,‏ GivenName ו-Surname ב-AttributeStatement, לדוגמה:
    • ‪<Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
      <AttributeValue>Blüte, Eva</AttributeValue> </Attribute>
    • <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
      <AttributeValue>Blüte</AttributeValue> </Attribute>

מידע נוסף על הפורמט של רכיב NameID זמין במאמר בנושא דרישות טענת נכוֹנוּת (assertion) ב-SSO.

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

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

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

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

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

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