แก้ปัญหาการลงชื่อเพียงครั้งเดียว (SSO)

คุณสามารถแก้ไขข้อผิดพลาดที่พบบ่อยซึ่งอาจพบระหว่างการผสานรวมหรือการใช้การลงชื่อเพียงครั้งเดียว (SSO) กับ Google Workspace เมื่อ Google เป็นผู้ให้บริการ

การกำหนดค่าและการเปิดใช้งาน

"โดเมนนี้ไม่ได้กำหนดค่าให้ใช้การลงชื่อเพียงครั้งเดียว"

ข้อผิดพลาดนี้มักบ่งบอกว่าคุณกำลังใช้ Google Workspace เวอร์ชันที่ไม่รองรับ SSO (เช่น G Suite รุ่นเดิมที่ใช้งานฟรี) Workspace ทุกรุ่นในปัจจุบันรองรับ SSO ผ่านผู้ให้บริการข้อมูลประจำตัว (IdP) ของบุคคลที่สาม

หากคุณใช้ Google Workspace รุ่นที่รองรับ SSO ให้ลองใช้วิธีแก้ปัญหาอื่นๆ ต่อไปนี้

  • ตรวจสอบว่าการกำหนดค่า SSO ของ IdP ใช้ชื่อโดเมน Google Workspace ที่ถูกต้อง
  • หากได้รับข้อผิดพลาดนี้หลังจากตั้งค่าโปรไฟล์ SSO อาจเป็นไปได้ว่ามีการกำหนดค่า IdP ให้ส่งการยืนยัน SAML ไปยังปลายทางของโปรไฟล์ SSO เดิม หาก IdP มีปลายทาง SSO เดิมที่ฮาร์ดโค้ดไว้ โปรดทำดังนี้
    1. ตั้งค่า SSO เดิม
    2. ขอให้ผู้ให้บริการ IdP อัปเดตการผสานรวม Google

"ไม่สามารถเข้าถึงบัญชีนี้เนื่องจากมีการกำหนดค่าโดเมนไม่ถูกต้อง โปรดลองใหม่ในภายหลัง"

ข้อผิดพลาดนี้แสดงว่าคุณยังไม่ได้ตั้งค่า SSO อย่างถูกต้องในคอนโซลผู้ดูแลระบบของ Google โปรดดูขั้นตอนต่อไปนี้เพื่อแก้ไขปัญหา

  1. ในคอนโซลผู้ดูแลระบบ ให้ไปที่ความปลอดภัย จากนั้น ตั้งค่าการลงชื่อเพียงครั้งเดียว (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 สำหรับกลุ่มหรือหน่วยขององค์กรของผู้ใช้ ให้ตรวจสอบประเด็นต่อไปนี้ในคอนโซลผู้ดูแลระบบ

  • ลำดับความสำคัญของกลุ่ม - ไปที่จัดการการมอบหมายโปรไฟล์ SSO จากนั้น กลุ่ม แล้วตรวจสอบว่าผู้ใช้อยู่ในกลุ่มอื่นที่มีลำดับความสำคัญสูงกว่าในรายการกลุ่มหรือไม่ เมื่อผู้ใช้อยู่ในกลุ่มหลายกลุ่ม กลุ่มที่มีลำดับความสำคัญสูงสุดจะมีผลเหนือกว่า ให้กลุ่มที่ปิด SSO มีลำดับความสำคัญสูงกว่ากลุ่มที่ใช้โปรไฟล์ SSO ของบุคคลที่สาม หรือนำผู้ใช้ออกจากกลุ่ม SSO ที่มีลำดับความสำคัญสูงกว่า
  • การเป็นสมาชิกกลุ่มที่ซ้อนกัน - ตรวจสอบว่าผู้ใช้อยู่ในกลุ่มย่อยที่ซ้อนกันภายในกลุ่มหลักที่กำหนด SSO หรือไม่ ผู้ใช้จะรับค่าโปรไฟล์ SSO ของกลุ่มหลักทั้งหมดที่ตนเป็นสมาชิกอยู่ นำผู้ใช้ออกจากกลุ่มย่อยหรือกำหนดโปรไฟล์ SSO ให้กับกลุ่มย่อยโดยตรง และกำหนดให้กลุ่มย่อยมีลำดับความสำคัญในรายการสูงกว่ากลุ่มหลัก
  • การรับค่าหน่วยขององค์กร - หากผู้ใช้ไม่มีการมอบหมายกลุ่ม ให้ตรวจสอบโปรไฟล์ SSO ที่มอบหมายให้กับหน่วยขององค์กรของผู้ใช้ หากหน่วยขององค์กรของผู้ใช้ได้รับการมอบหมายให้ใช้โปรไฟล์ SSO ของบุคคลที่สาม ให้ย้ายผู้ใช้ไปยังหน่วยขององค์กรที่ปิด SSO ไว้ หรือปิด SSO สำหรับหน่วยขององค์กรของผู้ใช้
การเปลี่ยนแปลงอาจใช้เวลาถึง 24 ชั่วโมง แต่โดยปกติจะใช้เวลาน้อยกว่านั้น ดูข้อมูลเพิ่มเติม

การแยกวิเคราะห์คำตอบ SAML

"ไม่มีพารามิเตอร์การตอบกลับ SAMLResponse ที่จำเป็น"

ข้อความแสดงข้อผิดพลาดนี้หมายความว่าผู้ให้บริการข้อมูลประจำตัวของคุณไม่ได้ให้การตอบกลับ SAML บางอย่างที่ถูกต้องแก่ Google จึงเป็นไปได้มากว่ากรณีนี้น่าจะเกิดจากปัญหาการกำหนดค่าในระบบผู้ให้บริการข้อมูลประจำตัว

  • ตรวจสอบบันทึกของผู้ให้บริการข้อมูลประจำตัวให้มั่นใจว่าไม่มีสิ่งใดขัดขวางการส่งการตอบกลับ SAML คืนอย่างถูกต้อง
  • ตรวจสอบว่าผู้ให้บริการข้อมูลประจำตัวของคุณไม่ได้ส่งการตอบกลับ SAML ที่เข้ารหัสไปยัง Google Workspace Google Workspace จะยอมรับเฉพาะการตอบกลับ SAML ที่ไม่ได้เข้ารหัสเท่านั้น โดยเฉพาะอย่างยิ่ง Active Directory Federation Services 2.0 ของ Microsoft ที่การกำหนดค่าเริ่มต้นมักจะส่งการตอบกลับ 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

"ไม่สามารถเข้าถึงบริการนี้เนื่องจากคำขอเข้าสู่ระบบของคุณมีข้อมูล [ปลายทาง|ผู้ชม|ผู้รับ] ที่ไม่ถูกต้อง โปรดเข้าสู่ระบบและลองอีกครั้ง"

ข้อผิดพลาดนี้บ่งบอกว่าเอลิเมนต์ปลายทาง กลุ่มเป้าหมาย หรือผู้รับ ในการยืนยันสิทธิ์ SAML มีข้อมูลที่ไม่ถูกต้องหรือว่างเปล่า เอลิเมนต์ทั้งหมดจะต้องอยู่ในการยืนยันสิทธิ์ SAML โปรดดูตารางต่อไปนี้ในข้อกำหนดในการยืนยันสิทธิ์ SSO เพื่อดูรายละเอียดและตัวอย่างสำหรับแต่ละองค์ประกอบ

"ไม่สามารถเข้าถึงบริการนี้เนื่องจากคำขอเข้าสู่ระบบของคุณไม่มีข้อมูลของผู้รับ โปรดเข้าสู่ระบบและลองอีกครั้ง"

ตามปกติข้อผิดพลาดนี้มักแสดงว่าการตอบกลับ SAML จากผู้ให้บริการข้อมูลประจำตัวของคุณไม่มีค่า Recipient ที่สามารถอ่านได้ (หรือค่า Recipient ไม่ถูกต้อง) ค่า 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 ให้ไปที่ความปลอดภัย จากนั้น ตั้งค่าการลงชื่อเพียงครั้งเดียว (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
  • หากผู้ให้บริการข้อมูลประจำตัวของคุณเข้ารหัสการยืนยันสิทธิ์ 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 ได้ที่ข้อกําหนดในการยืนยันสิทธิ์ SSO

"เข้าถึงบริการนี้ไม่ได้เนื่องจากข้อมูลเข้าสู่ระบบของคุณหมดอายุ โปรดเข้าสู่ระบบและลองอีกครั้ง"

เพื่อความปลอดภัย กระบวนการเข้าสู่ระบบ SSO จะต้องเสร็จสิ้นภายในกรอบระยะเวลาที่กำหนด ไม่เช่นนั้นการตรวจสอบสิทธิ์จะไม่สำเร็จ หากนาฬิกาของผู้ให้บริการข้อมูลประจำตัวบอกเวลาไม่ถูกต้อง การพยายามเข้าสู่ระบบส่วนใหญ่หรือทั้งหมดจะดูเหมือนว่าไม่อยู่ในกรอบเวลาที่ยอมรับได้ และการตรวจสอบสิทธิ์จะดำเนินการไม่สำเร็จโดยมีข้อความแสดงข้อผิดพลาดข้างต้นปรากฏขึ้น

  • ตรวจสอบนาฬิกาของเซิร์ฟเวอร์ผู้ให้บริการข้อมูลประจำตัว ข้อผิดพลาดนี้แทบทั้งหมดเกิดจากการที่นาฬิกาของผู้ให้บริการข้อมูลประจำตัวบอกเวลาไม่ถูกต้อง ซึ่งจะเพิ่มการประทับเวลาที่ไม่ถูกต้องในการตอบกลับ SAML
  • ซิงค์นาฬิกาของเซิร์ฟเวอร์ผู้ให้บริการข้อมูลประจำตัวกับเซิร์ฟเวอร์เวลาอินเทอร์เน็ตที่เชื่อถือได้ใหม่อีกครั้ง เมื่อเกิดปัญหานี้ในสภาพแวดล้อมการใช้งานจริง ปกติมักเกิดจากการซิงค์เวลาครั้งล่าสุดล้มเหลว ทำให้เวลาของเซิร์ฟเวอร์ไม่ถูกต้อง การซิงค์เวลาซ้ำ (โดยอาจซิงค์กับเซิร์ฟเวอร์เวลาที่เชื่อถือได้มากขึ้น) จะแก้ไขปัญหานี้ได้โดยเร็ว
  • ปัญหานี้อาจเกิดขึ้นได้เช่นกัน ถ้าคุณส่ง SAML ซ้ำจากการพยายามเข้าสู่ระบบก่อนหน้านี้ การตรวจสอบคำขอและการตอบกลับ SAML (ที่ได้รับจากบันทึกส่วนหัว HTTP ที่บันทึกไว้ระหว่างการพยายามเข้าสู่ระบบ) จะช่วยให้คุณแก้ไขข้อบกพร่องในกรณีนี้ได้ดีขึ้น

"เข้าถึงบริการนี้ไม่ได้เนื่องจากข้อมูลเข้าสู่ระบบของคุณยังไม่ถูกต้อง โปรดเข้าสู่ระบบและลองอีกครั้ง"

เพื่อความปลอดภัย กระบวนการเข้าสู่ระบบ SSO จะต้องเสร็จสิ้นภายในกรอบระยะเวลาที่กำหนด ไม่เช่นนั้นการตรวจสอบสิทธิ์จะไม่สำเร็จ หากนาฬิกาของผู้ให้บริการข้อมูลประจำตัวบอกเวลาไม่ถูกต้อง การพยายามเข้าสู่ระบบส่วนใหญ่หรือทั้งหมดจะดูเหมือนว่าไม่อยู่ในกรอบเวลาที่ยอมรับได้ และการตรวจสอบสิทธิ์จะดำเนินการไม่สำเร็จโดยมีข้อความแสดงข้อผิดพลาดข้างต้นปรากฏขึ้น

  • ตรวจสอบนาฬิกาของเซิร์ฟเวอร์ผู้ให้บริการข้อมูลประจำตัว ข้อผิดพลาดนี้แทบทั้งหมดเกิดจากการที่นาฬิกาของผู้ให้บริการข้อมูลประจำตัวบอกเวลาไม่ถูกต้อง ซึ่งจะเพิ่มการประทับเวลาที่ไม่ถูกต้องในการตอบกลับ SAML
  • ซิงค์นาฬิกาของเซิร์ฟเวอร์ผู้ให้บริการข้อมูลประจำตัวกับเซิร์ฟเวอร์เวลาอินเทอร์เน็ตที่เชื่อถือได้ใหม่อีกครั้ง เมื่อเกิดปัญหานี้ในสภาพแวดล้อมการใช้งานจริง ปกติมักเกิดจากการซิงค์เวลาครั้งล่าสุดล้มเหลว ทำให้เวลาของเซิร์ฟเวอร์ไม่ถูกต้อง การซิงค์เวลาซ้ำ (โดยอาจซิงค์กับเซิร์ฟเวอร์เวลาที่เชื่อถือได้มากขึ้น) จะแก้ไขปัญหานี้ได้โดยเร็ว