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

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

הגדרה והפעלה

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

השגיאה הזו בדרך כלל מציינת שאתם משתמשים בגרסה של 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) עם IdP של צד שלישי, ומסמנים את האפשרות הגדרת SSO עם ספק זהויות של צד שלישי.
  2. בשדות המתאימים, מזינים את כתובות ה-URL של דף הכניסה, דף היציאה ודף שינוי הסיסמה של הארגון.
  3. בוחרים ומעלים קובץ אישור אימות תקין.
  4. לוחצים על שמירה, ממתינים כמה דקות עד שהשינויים ייכנסו לתוקף ובודקים שוב את השילוב.

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

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

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

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

המשתמש מופנה באופן בלתי צפוי לספק זהויות (IdP) של צד שלישי במקום לדף הכניסה באמצעות חשבון Google

אם משתמש מופנה ל-IdP של צד שלישי אחרי שהסרתם אותו מקבוצת SSO או השבתתם את ה-SSO לקבוצה או ליחידה הארגונית שלו, בדקו את הנקודות הבאות במסוף Admin:

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

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

"חסר פרמטר התגובה הנדרש SAMLResponse"

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

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

"חסר פרמטר התגובה הנדרש RelayState"

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

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

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

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

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

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

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

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

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

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

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

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

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