เปิดแอปพลิเคชัน AD FS Management บนเซิร์ฟเวอร์ และภายในโฟลเดอร์ AD FS > Service > Endpoints ให้เลือก Federation Metadata
อัปเดตครั้งล่าสุดเมื่อ
16 ธ.ค. 2024
แก้ไขข้อผิดพลาดการรับรองความถูกต้องทั่วไป ตรวจสอบการกำหนดค่า และแก้ไขปัญหาการลงชื่อเข้าใช้ที่เกี่ยวข้องกับ Federated ID (SSO) ในผลิตภัณฑ์ Adobeรับเทคนิคแก้ไขข้อผิดพลาด SAML ปัญหาใบรับรอง และความท้าทายด้านการรับรองความถูกต้องอื่นๆ
หลังจากกำหนดค่า SSO ใน Adobe Admin Console เรียบร้อยแล้ว เลือก ดาวน์โหลดไฟล์ Adobe Metadata และบันทึกไฟล์ SAML XML Metadata ลงในคอมพิวเตอร์ผู้ให้บริการข้อมูลประจำตัวต้องใช้ไฟล์นี้เพื่อเปิดใช้งานการลงชื่อเข้าระบบครั้งเดียวนำเข้ารายละเอียดการกำหนดค่า XML เข้าสู่ผู้ให้บริการข้อมูลประจำตัว (IdP) อย่างถูกต้องจำเป็นต้องดำเนินการนี้สำหรับการผสานการทำงาน SAML กับ IdP และช่วยให้มั่นใจว่าข้อมูลได้รับการกำหนดค่าอย่างถูกต้อง
หากมีคำถามเกี่ยวกับวิธีใช้ไฟล์ข้อมูลเมตา SAML XML เพื่อกำหนดค่า IdP โปรดติดต่อ IdP โดยตรงเพื่อขอคำแนะนำ เนื่องจากวิธีการแตกต่างกันไปตาม IdP แต่ละตัว
หมายเหตุ
อ้างอิงจากบทความต่อไปนี้หากองค์กรได้ตั้งค่า SSO ผ่าน Google Federation หรือ Microsoft Azure Sync:
การแก้ไขปัญหาเบื้องต้น
ปัญหาเกี่ยวกับการลงชื่อเข้าระบบครั้งเดียวมักเกิดจากข้อผิดพลาดพื้นฐานที่มักมองข้ามได้ง่ายโดยเฉพาะอย่างยิ่ง ตรวจสอบรายการต่อไปนี้:
- ผู้ใช้ได้รับมอบหมายให้อยู่ในโปรไฟล์ผลิตภัณฑ์ที่มีสิทธิ์
- ชื่อผู้ใช้ที่ส่งไปยัง SAML ตรงกับชื่อผู้ใช้ในแดชบอร์ดองค์กร
- ตรวจสอบรายการทั้งหมดใน Admin Console และผู้ให้บริการข้อมูลประจำตัวเพื่อหาข้อผิดพลาดในการสะกดหรือไวยากรณ์
- แอป Creative Cloud บนเดสก์ท็อปได้รับการอัปเดตเป็นเวอร์ชันล่าสุดแล้ว
- ผู้ใช้ลงชื่อเข้าใช้ในที่ถูกต้อง (แอป Creative Cloud บนเดสก์ท็อป แอปพลิเคชัน Creative Cloud หรือ Adobe.com)
วิธีแก้ไขข้อผิดพลาดทั่วไปอื่นๆ
ข้อผิดพลาด: "เกิดข้อผิดพลาด" พร้อมปุ่มที่มีป้ายกำกับ "ลองอีกครั้ง"
ข้อผิดพลาดนี้มักเกิดขึ้นหลังจากการรับรองความถูกต้องของผู้ใช้สำเร็จแล้ว และ Okta ได้ส่งต่อการตอบกลับการรับรองความถูกต้องไปยัง Adobe
ใน Adobe Admin Console ให้ตรวจสอบสิ่งต่อไปนี้:
ในแท็บ Identity:
- ตรวจสอบให้แน่ใจว่าโดเมนที่เกี่ยวข้องได้รับการเปิดใช้งานแล้ว
ในแท็บ Products:
- ตรวจสอบให้แน่ใจว่าผู้ใช้เชื่อมโยงกับชื่อเล่นของผลิตภัณฑ์ที่ถูกต้องและอยู่ในโดเมนที่ได้รับการกำหนดค่าเป็น Federated ID
- ตรวจสอบให้แน่ใจว่าชื่อเล่นผลิตภัณฑ์มีการกำหนดสิทธิ์ที่ถูกต้อง
ในแท็บ Users:
- ตรวจสอบให้แน่ใจว่าชื่อผู้ใช้อยู่ในรูปแบบของอีเมลแอดเดรสที่สมบูรณ์
ข้อผิดพลาด: "การเข้าถึงถูกปฏิเสธ" ขณะลงชื่อเข้าใช้
สาเหตุที่เป็นไปได้สำหรับข้อผิดพลาดนี้:
- ชื่อผู้ใช้หรืออีเมลแอดเดรสใน SAML assertion ไม่ตรงกับข้อมูลที่ป้อนใน Admin Console
- ผู้ใช้ไม่ได้เชื่อมโยงกับผลิตภัณฑ์ที่ถูกต้อง หรือผลิตภัณฑ์ไม่ได้เชื่อมโยงกับสิทธิ์ที่ถูกต้อง
- ชื่อผู้ใช้ SAML มาเป็นอย่างอื่นที่ไม่ใช่อีเมลแอดเดรสผู้ใช้ทั้งหมดต้องอยู่ในโดเมนที่ระบุเป็นส่วนหนึ่งของขั้นตอนการตั้งค่า
- ลูกค้า SSO ของคุณใช้ JavaScript เป็นส่วนหนึ่งของกระบวนการลงชื่อเข้าใช้ และคุณกำลังพยายามลงชื่อเข้าใช้ลูกค้าที่ไม่รองรับ JavaScript
วิธีแก้ไข:
- ตรวจสอบชื่อผู้ใช้และอีเมลใน Adobe Admin Console และจับคู่กับแอตทริบิวต์ NameID และ Email ในบันทึก SAML
- ตรวจสอบการกำหนดค่าแดชบอร์ดสำหรับผู้ใช้: ข้อมูลผู้ใช้และโปรไฟล์ผลิตภัณฑ์
- เริ่มต้น {1}SAML trace{2} และตรวจสอบว่าข้อมูลที่ส่งตรงกับแดชบอร์ด จากนั้นแก้ไขความไม่สอดคล้องใดๆ
ข้อผิดพลาด: "ผู้ใช้อื่นกำลังลงชื่อเข้าใช้อยู่"
ข้อผิดพลาด "ผู้ใช้อื่นกำลังลงชื่อเข้าใช้อยู่" เกิดขึ้นเมื่อแอตทริบิวต์ที่ส่งใน SAML assertion ไม่ตรงกับอีเมลแอดเดรสที่ใช้เริ่มต้นกระบวนการลงชื่อเข้าใช้
เริ่มต้น SAML trace และ ตรวจสอบให้แน่ใจว่าอีเมลแอดเดรสของผู้ใช้สำหรับลงชื่อเข้าใช้ตรงกับสิ่งต่อไปนี้:
- อีเมลแอดเดรสของผู้ใช้ที่แสดงใน Admin Console
- ชื่อผู้ใช้ของผู้ใช้ที่ส่งกลับมาในฟิลด์ NameID ของ SAML Assertion
ข้อผิดพลาด: "ผู้ออกในการตอบกลับ SAML ไม่ตรงกับผู้ออกที่กำหนดค่าไว้สำหรับตัวให้บริการข้อมูลประจำตัว"
ผู้ออก IDP ใน SAML Assertion แตกต่างจากที่กำหนดค่าไว้ใน Inbound SAMLตรวจหาข้อผิดพลาดในการพิมพ์ (เช่น http เทียบกับ https) เมื่อตรวจสอบสตริง IDP Issuer กับระบบ SAML ของลูกค้า จำเป็นต้องมีการจับคู่ที่ตรงกันทุกตัวอักษรกับสตริงที่ได้รับมาปัญหานี้มักเกิดขึ้นเพราะขาดเครื่องหมายทับที่ส่วนท้าย
หากต้องการความช่วยเหลือเกี่ยวกับข้อผิดพลาดนี้ โปรดส่ง SAML trace และค่าที่ป้อนใน Adobe dashboard
ข้อผิดพลาด: "ลายเซ็นดิจิทัลในการตอบกลับ SAML ไม่สามารถตรวจสอบได้ด้วยใบรับรองของตัวให้บริการข้อมูลประจำตัว"
ปัญหานี้เกิดขึ้นเมื่อใบรับรองของไดเรกทอรีหมดอายุเพื่ออัปเดตใบรับรอง คุณต้องดาวน์โหลดใบรับรองหรือข้อมูลเมตาจากตัวให้บริการข้อมูลประจำตัวและอัปโหลดไปยัง Adobe Admin Console
ตัวอย่างเช่น ให้ทำตามขั้นตอนด้านล่างหาก IdP คือ Microsoft AD FS:
ใช้เบราว์เซอร์เพื่อไปยัง URL ที่ให้ไว้สำหรับ Federation Metadata และดาวน์โหลดไฟล์ ตัวอย่างเช่น https://<your AD FS hostname>/FederationMetadata/2007-06/FederationMetadata.xml
หมายเหตุ
ยอมรับคำเตือนใดๆ หากมีการแจ้ง
บนแท็บ การตั้งค่า ของ Admin Console และไปที่ Identity Settings > Directories เลือกไดเรกทอรีที่ต้องการอัปเดตและคลิก Configure บนการ์ด SAML provider
จากนั้น อัปโหลดไฟล์ข้อมูลเมตา IdP และ บันทึก
ข้อผิดพลาด: "เวลาปัจจุบันอยู่ก่อนช่วงเวลาที่ระบุไว้ในเงื่อนไขการยืนยัน"
เซิร์ฟเวอร์ IdP ที่ใช้ Windows:
- ตรวจสอบให้แน่ใจว่านาฬิการะบบซิงโครไนซ์กับเซิร์ฟเวอร์เวลาที่แม่นยำ
ตรวจสอบความแม่นยำของนาฬิการะบบเทียบกับเซิร์ฟเวอร์เวลาของคุณด้วยคำสั่งนี้ ค่า "Phase Offset" ควรเป็นเศษเสี้ยวเล็กๆ ของวินาที:
w32tm /query /status /verbose
คุณสามารถทำให้เกิดการซิงโครไนซ์นาฬิการะบบกับ Time Server ทันทีด้วยคำสั่งต่อไปนี้:
w32tm /resync
หากนาฬิการะบบตั้งค่าถูกต้องแล้วและคุณยังคงเห็นข้อผิดพลาดข้างต้น คุณอาจต้องปรับการตั้งค่า time-skew เพื่อเพิ่มความอดทนต่อความแตกต่างของนาฬิการะหว่างเซิร์ฟเวอร์และลูกข่าย - เพิ่มความแตกต่างที่อนุญาตในนาฬิการะบบระหว่างเซิร์ฟเวอร์
จากหน้าต่าง PowerShell ที่มีสิทธิ์ผู้ดูแลระบบ ให้ตั้งค่า allowed skew เป็น 2 นาที ตรวจสอบว่าสามารถลงชื่อเข้าใช้ได้หรือไม่ จากนั้นเพิ่มหรือลดค่าตามผลลัพธ์
กำหนดการตั้งค่า time-skew ปัจจุบันสำหรับ Relying Party Trust ที่เกี่ยวข้องด้วยคำสั่งต่อไปนี้:
Get-ADFSRelyingPartyTrust | Format-List -property Identifier,Name,NotBeforeSkew
Relying Party Trust จะถูกระบุด้วย URL ที่แสดงในฟิลด์ "Identifier" ของผลลัพธ์จากคำสั่งก่อนหน้าสำหรับการกำหนดค่าเฉพาะนั้น URL นี้จะแสดงในยูทิลิตี้ ADFS Management ในหน้าต่างคุณสมบัติสำหรับ Relying Party Trust ที่เกี่ยวข้องในแท็บ "Identifiers" ในฟิลด์ "Relying Party Trusts" ดังที่แสดงในภาพหน้าจอด้านล่าง
กำหนด time skew เป็น 2 นาทีด้วยคำสั่งต่อไปนี้ โดยแทนที่แอดเดรส Identifier ตามความเหมาะสม:
Set-ADFSRelyingPartyTrust –TargetIdentifier 'https://www.okta.com/saml2/service-provider/xxxxxxxxxxxxxxxxxxxx' –NotBeforeSkew 2
เซิร์ฟเวอร์ IdP บน UNIX
ตรวจสอบให้แน่ใจว่านาฬิการะบบได้รับการตั้งค่าอย่างถูกต้องโดยใช้บริการ ntpd หรือด้วยตนเองด้วยคำสั่ง ntpdate จาก root shell หรือด้วย sudo ดังที่แสดงด้านล่าง (โปรดทราบว่าหากเวลาคลาดเคลื่อนมากกว่า 0.5 วินาที การเปลี่ยนแปลงจะไม่เกิดขึ้นทันที แต่จะปรับแก้นาฬิการะบบอย่างช้าๆ) ตรวจสอบให้แน่ใจว่าเขตเวลาได้รับการตั้งค่าอย่างถูกต้อง
# ntpdate -u pool.ntp.org
หมายเหตุ
วิธีนี้ใช้ได้กับ identity provider เช่น Shibboleth
ข้อผิดพลาด: 401 unauthorized credentials
ข้อผิดพลาดนี้เกิดขึ้นเมื่อแอปพลิเคชันไม่รองรับการลงชื่อเข้าใช้แบบ Federated และต้องลงชื่อเข้าใช้ในฐานะ Adobe ID FrameMaker, RoboHelp และ Adobe Captivate เป็นตัวอย่างของแอปพลิเคชันที่มีข้อกำหนดนี้
ข้อผิดพลาด: "Inbound SAML login failed with message: The SAML response contained no assertions"
ตรวจสอบเวิร์กโฟลว์การลงชื่อเข้าใช้ หากสามารถเข้าถึงหน้าลงชื่อเข้าใช้บนเครื่องหรือเครือข่ายอื่นได้แต่ไม่สามารถเข้าถึงจากภายในได้ ปัญหาอาจเกิดจาก block agent string นอกจากนี้ ให้ทำ SAML trace และยืนยันว่าชื่อ นามสกุล และชื่อผู้ใช้ในรูปแบบอีเมลแอดเดรสที่ถูกต้อง อยู่ใน SAML subject
ตรวจสอบว่ามีการส่ง SAML assertion ที่ถูกต้อง:
- ไม่มีองค์ประกอบ NameID ใน subject ตรวจสอบว่าองค์ประกอบ Subject มีองค์ประกอบ NameId ต้องตรงกับแอตทริบิวต์ Email ซึ่งควรเป็นอีเมลแอดเดรสของผู้ใช้ที่ต้องการรับรองความถูกต้อง
- ข้อผิดพลาดการสะกด โดยเฉพาะที่มองข้ามได้ง่าย เช่น https กับ http
- ตรวจสอบว่าได้ให้ใบรับรองที่ถูกต้อง IDP ต้องได้รับการกำหนดค่าให้ใช้ SAML request และ response ที่ไม่ถูกบีบอัด
เครื่องมือเช่น SAML tracer สำหรับ Firefox สามารถช่วยแยกข้อมูล assertion และแสดงผลเพื่อการตรวจสอบได้หากต้องการความช่วยเหลือจากการดูแลลูกค้าของ Adobe จะถูกขอให้ส่งไฟล์นี้ สำหรับรายละเอียด ดู วิธีการทำ SAML trace
ตัวอย่าง SAML ที่ใช้งานได้นี้ อาจช่วยในการจัดรูปแบบ SAML assertion ให้ถูกต้อง:
ด้วย Microsoft ADFS
ตรวจสอบให้แน่ใจว่าทุกบัญชี Active Directory มีที่อยู่อีเมลที่ระบุไว้ใน Active Directory เพื่อลงชื่อเข้าใช้ได้สำเร็จ (event log: The SAML response does not have NameId in the assertion)
เข้าถึง Admin Console แล้วเลือกแท็บ Identity และโดเมน
เลือก Edit Configuration และค้นหา IDP Bindingเปลี่ยนเป็น HTTP-POST แล้วบันทึก
ทดสอบประสบการณ์การลงชื่อเข้าใช้อีกครั้ง
หากใช้งานได้แต่คุณต้องการการตั้งค่าก่อนหน้า ให้เปลี่ยนกลับเป็น HTTP-REDIRECT และอัปโหลด metadata เข้า ADFS อีกครั้ง
ด้วย IdPs อื่นๆ
การพบข้อผิดพลาด 400 หมายความว่า IdP ของคุณปฏิเสธการลงชื่อเข้าใช้ที่สำเร็จ
ตรวจสอบบันทึก IdP เพื่อหาต้นตอของข้อผิดพลาดและแก้ไขปัญหาก่อนลองใหม่อีกครั้ง
ข้อผิดพลาด: "403 malfunctioned certificate"
อัปเดตใบรับรองใน Google Console ภายใต้แอป Adobe SAML และ อัปโหลดไฟล์ metadata ใหม่ใน Adobe Admin Console
ข้อผิดพลาด: "403 app_not_configured_for_user"
อัปเดต Entity ID ใน Google Consoleจากนั้นส่งออกไฟล์ metadata และ อัปโหลดใน Adobe Admin Console
ข้อผิดพลาด: "you cannot access this right now" หรือ "you can't get there from here"
ข้อผิดพลาดนี้มักเกิดขึ้นเมื่อองค์กรเปิดใช้งาน Conditional Access Policy ใน IdP
หากคุณใช้แพ็กเกจที่มีการจัดการเพื่อปรับใช้ผลิตภัณฑ์ ให้สร้างแพ็กเกจที่มีการจัดการจาก Adobe Admin Console โดยเลือกตัวเลือกการรับรองความถูกต้องผ่านเบราว์เซอร์จากนั้นปรับใช้บนอุปกรณ์ของผู้ใช้
หากไม่ใช่ ผู้ใช้สามารถเปิดแอปพลิเคชัน Creative Cloud บนเดสก์ท็อปและเลือก ลงชื่อเข้าใช้โดยใช้เบราว์เซอร์ จากเมนู ช่วยเหลือ
ข้อผิดพลาด: "App Not Assigned"
ในกรณีนี้ ผู้ดูแลระบบต้องเพิ่มผู้ใช้ไปยังแอป Adobe SAML ที่สร้างบน IdP ของตนเรียนรู้การสร้างแอป Adobe SAML บน Google Admin Console หรือ Microsoft Azure Portal
ข้อผิดพลาด: "คุณไม่มีการเข้าถึงบริการนี้ ติดต่อผู้ดูแลระบบ IT เพื่อขอการเข้าถึงหรือลงชื่อเข้าใช้ด้วย Adobe ID"
ตรวจสอบ บันทึก SAML เนื่องจากชื่อผู้ใช้หรืออีเมลแอดเดรสที่ส่งใน SAML assertion ไม่ตรงกับข้อมูลที่ป้อนใน Admin Console
