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

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

הגדרה והפעלה

‫"This domain is not configured to use single sign-on." (הדומיין הזה לא מוגדר לשימוש בכניסה יחידה).

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

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

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

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

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

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

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

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

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