การแจ้งเตือน

Duet AI เปลี่ยนเป็น Gemini สำหรับ Google Workspace แล้ว ดูข้อมูลเพิ่มเติม

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

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

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

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

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

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

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

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

  1. ในคอนโซลผู้ดูแลระบบ ให้ไปที่ความปลอดภัยจากนั้นตั้งค่าการลงชื่อเพียงครั้งเดียว (SSO) ด้วย IdP บุคคลที่สาม แล้วเลือกช่องตั้งค่า SSO ด้วยผู้ให้บริการข้อมูลประจำตัวบุคคลที่สาม
  2. ระบุ URL สำหรับหน้าลงชื่อเข้าใช้ขององค์กร หน้าออกจากระบบ และหน้าเปลี่ยนรหัสผ่านในช่องสำหรับหน้าเหล่านี้
  3. เลือกและอัปโหลดไฟล์ใบรับรองการยืนยันที่ถูกต้อง
  4. คลิกบันทึก จากนั้นรอสักครู่เพื่อให้การเปลี่ยนแปลงมีผล และทดสอบการผสานรวมของคุณอีกครั้ง

การแยกวิเคราะห์คำตอบ 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 โปรดอ่านตารางต่อไปนี้เพื่อดูรายละเอียดและตัวอย่างสำหรับแต่ละอีลิเมนต์

เอลิเมนต์ <Audience>
คำอธิบาย URI ที่ระบุกลุ่มเป้าหมายที่ต้องการ ซึ่งต้องใช้ค่าของ ACS URI หมายเหตุ: ค่าของ Element ต้องไม่ว่างเปล่า
ค่าที่ต้องการ https://www.google.com/a/<example.com>/acs
ตัวอย่าง

<saml:Conditions NotBefore="2014-11-05T17:31:37Z"
NotOnOrAfter="2014-11-05T17:37:07Z">
<saml:AudienceRestriction>
<saml:Audience>https://www.google.com/a/example.com/acs
</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>

 

เอลิเมนต์ แอตทริบิวต์ Destination ชนิด <StatusResponseType>
คำอธิบาย URI ปลายทางที่จะส่งการยืนยันสิทธิ์ SAML ไป ไม่บังคับ แต่ถ้ามีการประกาศ จะต้องมีค่าของ ACS URI
ค่าที่ต้องการ https://www.google.com/a/<example.com>/acs
ตัวอย่าง

<saml:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="7840062d379d82598d87ca04c8622f436bb03aa1c7"
Version="2.0"
IssueInstant="2014-11-05T17:32:07Z"
Destination="https://www.google.com/a/example.com/acs"
InResponseTo="midihfjkfkpcmbmfhhoehbokhbkeapbbinldpeen">

 

เอลิเมนต์ แอตทริบิวต์ Recipient ชนิด <SubjectConfirmationData>
 
คำอธิบาย
  • นิยามเอนทิตีที่ต้องการใช้ในการรับ Subject
  • เป็นแอตทริบิวต์ที่จำเป็นและต้องมี ACS URI
  • คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่
ค่าที่ต้องการ https://www.google.com/a/<example.com>/acs
ตัวอย่าง

<saml:Subject>
<saml:NameID SPNameQualifier="google.com/a/example.com"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@example.com</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2014-11-05T17:37:07Z"
Recipient="https://www.google.com/a/example.com/acs"
InResponseTo="midihfjkfkpcmbmfhjoehbokhbkeapbbinldpeen"/>
</saml:SubjectConfirmation> 
</saml:Subject>

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

ข้อมูลนี้มีประโยชน์ไหม

เราจะปรับปรุงได้อย่างไร
ค้นหา
ล้างการค้นหา
ปิดการค้นหา
เมนูหลัก
12487337654231244523
true
ค้นหาศูนย์ช่วยเหลือ
true
true
true
true
true
73010
false
false