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

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

הגדרה והפעלה

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

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

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

  • מוודאים שבהגדרת ה-SSO של ספק הזהויות מוגדר שם הדומיין הנכון של Google Workspace.
  • אם השגיאה הזו מופיעה אחרי שמגדירים פרופילים של כניסה יחידה (SSO), יכול להיות שספק הזהויות (IdP) מוגדר לשלוח את טענת הנכוֹנוּת (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" (חסר פרמטר התגובה הנדרש SAMLResponse)

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

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

‫"The required response parameter RelayState was missing" (חסר פרמטר התגובה הנדרש RelayState)

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

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

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

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

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