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

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

הגדרה והפעלה

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

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

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

  • מוודאים שבהגדרת ה-SSO של ספק ה-IdP מוגדר שם הדומיין הנכון של 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" (חסר פרמטר התגובה הנדרש RelayState)

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

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