วิธีแก้ไขปัญหาการตรวจสอบสิทธิ์ PAM ล้มเหลวบน SUSE Linux Enterprise Server

ข้อความ “การตรวจสอบสิทธิ์ PAM ล้มเหลว” ไม่ได้หมายความว่ารหัสผ่านผิดเสมอไป บน SUSE Linux Enterprise Server (SLES) โมดูลการตรวจสอบสิทธิ์แบบเสียบปลั๊ก (PAM) จะประกอบกันเป็นระบบที่ตรวจสอบตัวตน การเข้าถึงบัญชี การเปลี่ยนรหัสผ่าน และการตั้งค่าเซสชัน ความล้มเหลวอาจเกิดจากการพิมพ์ผิดหรือบัญชีถูกปิดใช้งาน การรวม PAM ที่เสียหาย บริการ LDAP หรือ Active Directory ไม่พร้อมใช้งาน ปัญหาเกี่ยวกับนาฬิกา Kerberos หรือ DNS หรือปัญหาเกี่ยวกับเซสชันเดสก์ท็อปที่เกิดขึ้นหลังจากตรวจสอบสิทธิ์แล้ว

วิธีแก้ไขที่ปลอดภัยที่สุดคือการระบุว่าบริการใดและขั้นตอน PAM ใดล้มเหลวก่อนที่จะเปลี่ยนแปลงการกำหนดค่า คู่มือนี้ใช้เอกสาร SUSE Linux Enterprise Server 15 SP7 เป็นข้อมูลอ้างอิง หากคุณใช้ Service Pack อื่นของ SLES หรืออิมเมจอุปกรณ์เฉพาะ โปรดตรวจสอบเอกสาร SUSE ที่ตรงกันและเวอร์ชันแพ็กเกจที่ติดตั้งก่อนที่จะใช้คำสั่งใดๆ

อันดับแรก ปัญหาเกิดขึ้นกับบริการใดบริการหนึ่ง หรือกับการเข้าสู่ระบบทุกครั้ง?

บันทึกชื่อผู้ใช้ เวลาที่แน่นอน โฮสต์ และจุดเริ่มต้นของความล้มเหลว: SSH, คอนโซลข้อความในเครื่อง, การเข้าสู่ระบบแบบกราฟิกsuหรือแอปพลิเคชัน ทดสอบด้วยบัญชีผู้ใช้ที่รู้จักอีกบัญชีหนึ่งหากเป็นไปได้ หาก SSH ล้มเหลวเฉพาะในขณะที่การเข้าสู่ระบบคอนโซลทำงานได้ ให้มุ่งเน้นไปที่/etc/pam.d/sshdSSH และบริการ SSH หากผู้ใช้ในเครื่องทำงานได้ แต่ผู้ใช้ในไดเร็กทอรีล้มเหลว ให้ตรวจสอบ SSSD, LDAP, Active Directory, Kerberos, DNS หรือนโยบายการอนุญาตของโฮสต์ หากการเข้าสู่ระบบคอนโซลสำเร็จ แต่เดสก์ท็อปปฏิเสธผู้ใช้หรือกลับไปยังหน้าจอเข้าสู่ระบบ ความล้มเหลวอาจอยู่ในเซสชันกราฟิกหรือไดเร็กทอรีโฮมมากกว่าการตรวจสอบสิทธิ์ด้วยรหัสผ่าน

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

1. อ่านบันทึกประจำวันเกี่ยวกับความพยายามที่ล้มเหลว

คู่มือการแก้ไขปัญหาของ SUSE แนะนำให้ตรวจสอบบันทึกระบบเพื่อหาข้อความจากกระบวนการล็อกอินและ PAM ค้นหาข้อมูลในช่วงเวลาสั้นๆ ใกล้เคียงกับช่วงเวลาที่เกิดความล้มเหลว เพื่อไม่ให้ข้อความที่ไม่เกี่ยวข้องบดบังสาเหตุ:

sudo journalctl -b --since "15 minutes ago"

สำหรับปัญหาที่เกี่ยวข้องกับ SSH เท่านั้น ให้จำกัดขอบเขตการตรวจสอบไปที่ SSH daemon:

sudo journalctl -b -u sshd --since "15 minutes ago"

มองหาชื่อบริการ ชื่อบริการ PAM ชื่อโมดูล และดูว่าข้อความนั้นอ้างถึงauth, account, password, หรือ หรือ ไม่ สแต็ก sessionของ PAM authจะตรวจสอบข้อมูลประจำตัวaccountตรวจสอบว่าผู้ใช้ได้รับอนุญาตให้เข้าถึงบริการนั้นหรือไม่ และsessionเตรียมสภาพแวดล้อมของผู้ใช้ การตรวจสอบรหัสผ่านสำเร็จตามด้วยการปฏิเสธบัญชี บ่งชี้ถึงปัญหาที่แตกต่างจากผู้ใช้ที่ไม่รู้จักหรือรหัสผ่านไม่ถูกต้อง หลีกเลี่ยงการเปิดใช้งานการดีบักแบบละเอียดในระบบที่ใช้งานจริง เว้นแต่จำเป็น บันทึกการวินิจฉัยอาจมีชื่อบัญชีและบริบทที่ละเอียดอ่อนอื่นๆ

โปรดดู คู่มือการแก้ไขปัญหา SLESของ SUSE สำหรับขั้นตอนการตรวจสอบสิทธิ์ทั้งแบบภายในเครื่องและผ่านเครือข่าย

2. ตรวจสอบว่า SLES สามารถค้นหาผู้ใช้ได้หรือไม่

ก่อนเปลี่ยน PAM โปรดตรวจสอบว่า Name Service Switch ของระบบสามารถระบุชื่อบัญชีได้หรือไม่:

getent passwd user_name
id user_name

แทนที่user_nameด้วยข้อมูลล็อกอินที่ได้รับผลกระทบ หากคำสั่งเหล่านี้ไม่พบบัญชีผู้ใช้สำหรับผู้ใช้ในไดเร็กทอรี แสดงว่า PAM อาจทำงานได้อย่างถูกต้อง แต่การค้นหาข้อมูลประจำตัวล้มเหลว ตรวจสอบว่าบริการข้อมูลประจำตัวที่กำหนดค่าไว้ทำงานอยู่ โฮสต์สามารถเข้าถึงไดเร็กทอรีได้ และผู้ใช้ได้รับอนุญาตให้ลงชื่อเข้าใช้ในโฮสต์นี้ สำหรับการตั้งค่าแบบ SSSD ให้ตรวจสอบ daemon และบันทึกเหตุการณ์ล่าสุด:

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

เอกสารของ SUSE ระบุว่า SSSD มีทั้งอินเทอร์เฟซ NSS และ PAM และสามารถแคชข้อมูลประจำตัวได้ หากผู้ใช้รายงานความล้มเหลวเป็นระยะ ให้เปรียบเทียบเวลาและการแก้ไข DNS ของระบบในเครื่องกับไดเร็กทอรีหรือสภาพแวดล้อม Kerberos Kerberos ขึ้นอยู่กับการซิงโครไนซ์เวลาที่ถูกต้อง การเชื่อมต่อเครือข่ายที่ใช้งานได้เพียงอย่างเดียวไม่ได้พิสูจน์ว่าการตรวจสอบสิทธิ์จะสำเร็จ

ตรวจสอบการชนกันของชื่อด้วย SUSE ระบุว่าชื่อผู้ใช้ที่มีอยู่ทั้งในเครื่องและในแหล่งข้อมูลยืนยันตัวตนเครือข่ายอาจเป็นสาเหตุหนึ่งของปัญหาการตรวจสอบสิทธิ์เครือข่าย ตรวจสอบว่าแหล่งข้อมูลยืนยันตัวตนใดเป็นเจ้าของบัญชีก่อนที่จะแก้ไขกฎ PAM ของบัญชีนั้น

3. ตรวจสอบไฟล์บริการ PAM และสแต็กที่ใช้ร่วมกัน

SLES เก็บไฟล์ PAM สำหรับแต่ละบริการไว้ใน/etc/pam.d. ไฟล์บริการ เช่น/etc/pam.d/sshdมักจะมีไฟล์ที่ใช้ร่วมกัน เช่นcommon-auth, common-account, common-password, และcommon-sessionบรรทัดที่ไม่ถูกต้องในไฟล์ที่ใช้ร่วมกันอาจส่งผลกระทบต่อหลายบริการ ในขณะที่บรรทัดที่ไม่ถูกต้องในไฟล์ของแอปพลิเคชันหนึ่งอาจส่งผลกระทบเฉพาะแอปพลิเคชันนั้นเท่านั้น

โปรดอ่านไฟล์ที่เกี่ยวข้องและตรวจสอบลิงก์ก่อนทำการแก้ไข:

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

ตรวจสอบชื่อโมดูลที่สะกดผิด ไฟล์โมดูลที่หายไป ตัวเลือกที่ไม่ถูกต้อง ลำดับที่ไม่คาดคิด และการเปลี่ยนแปลงที่เกิดขึ้นระหว่างการติดตั้งแพ็กเกจหรือการตรวจสอบสิทธิ์ครั้งล่าสุด แฟล็กควบคุมมีความสำคัญ: requiredบันทึกความล้มเหลวแต่ยังคงดำเนินการต่อไปในสแต็ก; requisiteสามารถหยุดได้ทันที; sufficientสามารถอนุญาตให้กลับมาสำเร็จได้ก่อนกำหนดหากไม่มีโมดูลที่จำเป็นก่อนหน้านี้ล้มเหลว อย่าคัดลอกสแต็ก PAM จากการแจกจ่ายหรือรุ่น SLES อื่นโดยไม่เข้าใจโมดูลและการไหลของการควบคุม

ก่อนทำการเปลี่ยนแปลงใดๆ โปรดทำการสำรองข้อมูลไดเร็กทอรีปัจจุบันโดยใช้สิทธิ์ root เท่านั้น และเก็บรักษา symbolic links ไว้ด้วย:

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

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

4. บน SLES ให้ตรวจสอบว่า pam-config จัดการไฟล์ที่ใช้ร่วมกันหรือไม่

SUSE มีpam-configระบบจัดการไฟล์ PAM ทั่วโลกและการกำหนดค่าแอปพลิเคชันที่รองรับ ซึ่งโดยทั่วไปแล้วจะปลอดภัยกว่าการแก้ไขสแต็กที่ใช้ร่วมกันที่สร้างขึ้นด้วยตนเองเมื่อเพิ่มหรือลบวิธีการที่รองรับ ก่อนอื่นให้ตรวจสอบโมดูลที่มีอยู่และการรวม SSSD ในปัจจุบัน:

sudo pam-config --list-modules
sudo pam-config --query --sss

หากเซิร์ฟเวอร์ใช้ SSSD โดยเจตนาและไม่มีการเชื่อมต่อ เอกสารของ SUSE sudo pam-config --add --sssระบุวิธีการเพิ่มการเชื่อมต่อ ควรทำเช่นนี้หลังจากยืนยันการออกแบบการตรวจสอบสิทธิ์ไดเร็กทอรี ตรวจสอบสแต็กปัจจุบัน เก็บสำรองข้อมูล และตรวจสอบให้แน่ใจว่ามีเส้นทางการกู้คืนแล้วเท่านั้น อย่าใช้เป็นวิธีแก้ปัญหาทั่วไปสำหรับ "ความล้มเหลวในการตรวจสอบสิทธิ์" ทุกครั้ง ตรวจสอบการกำหนดค่าอีกครั้งและทดสอบในเซสชันที่สอง

คำสั่งที่มีความเสี่ยงสูงเป็นพิเศษคือpam-config --create`.` SUSE ระบุว่าคำสั่งนี้จะสร้างการกำหนดค่าการตรวจสอบสิทธิ์ Unix อย่างง่าย และเขียนทับไฟล์การกำหนดค่าที่มีอยู่ซึ่งไม่ได้ถูกดูแลโดย ` .` pam-config(ในขณะที่ยังคงเก็บสำเนาสำรองไว้โดยมี.pam-config-backupคำต่อท้าย) นี่ไม่ใช่การแก้ไขปัญหาการเข้าสู่ระบบล้มเหลวเพียงครั้งเดียวตามปกติ ควรใช้เฉพาะเมื่อคุณตั้งใจที่จะสร้างการกำหนดค่าใหม่และมีการวางแผนการกู้คืนไว้แล้วเท่านั้น

หากองค์กรของคุณจงใจดูแลรักษาไฟล์ PAM ด้วยตนเอง โปรดปฏิบัติตามรูปแบบนั้นอย่างสม่ำเสมอ SUSE ระบุว่าการกำหนดค่าด้วยตนเองจำเป็นต้องปิดใช้pam-configงานไฟล์เหล่านั้น สแต็กแบบกำหนดเองควรเก็บรักษาโมดูลเซสชันที่จำเป็นไว้ รวมpam_systemd.soถึงโมดูลเซสชันเสริมในกรณีที่เหมาะสม

5. แยกปัญหาที่เกี่ยวข้องกับ SSH, ไดเร็กทอรี และเดสก์ท็อป ออกจากกัน

หาก SSH ปฏิเสธบัญชีเท่านั้น

เปรียบเทียบ/etc/pam.d/sshdกับค่าการตั้งค่า SLES ที่ใช้งานได้ปกติ และตรวจสอบบันทึกของ SSH daemon ในช่วงเวลาที่การเข้าสู่ระบบล้มเหลว ยืนยันว่าบัญชีได้รับอนุญาตจากค่าการตั้งค่าและการควบคุมการเข้าถึงของ SSH เอง รวมถึงจาก PAM ด้วย อย่าลดความเข้มงวดของการตรวจสอบสิทธิ์ SSH หรือลบการตรวจสอบบัญชีออกเพียงเพื่อให้ข้อผิดพลาดหายไป

หากผู้ใช้ไดเร็กทอรีล้มเหลวเพียงอย่างเดียว

ยืนยันการค้นหาบัญชีด้วยคำสั่ง `yaST-administrator` getentตรวจสอบสถานะและบันทึกของ SSSD และตรวจสอบการเข้าถึงไดเร็กทอรี DNS การซิงโครไนซ์เวลา การลงทะเบียนโฮสต์ และนโยบายการเข้าถึงของผู้ใช้ หากผู้ใช้ไดเร็กทอรีรายอื่นประสบความสำเร็จ ให้เปรียบเทียบกลุ่ม เชลล์ ไดเร็กทอรีโฮม และกฎการเข้าถึงเฉพาะโฮสต์ของบัญชีที่ได้รับผลกระทบคู่มือไคลเอ็นต์การตรวจสอบสิทธิ์ ของ SUSE อธิบายถึง SSSD ที่จัดการโดย YaST และการตรวจสอบสถานะ

หากการเข้าสู่ระบบคอนโซลสำเร็จ แต่การเข้าใช้งานแบบกราฟิกไม่สำเร็จ

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

6. ตรวจสอบการซ่อมแซมโดยไม่ต้องเสี่ยงต่อการถูกล็อกเอาต์

หลังจากทำการเปลี่ยนแปลงแล้ว ให้เปิดเซสชันทดสอบใหม่ในขณะที่ Recovery Shell ยังคงใช้งานได้ ทดสอบบริการที่ได้รับผลกระทบด้วยบัญชีที่ได้รับผลกระทบ จากนั้นทดสอบบัญชีที่สองและผู้ดูแลระบบในเครื่อง สำหรับการตรวจสอบสิทธิ์ไดเร็กทอรี ให้ยืนยันการค้นหาบัญชีและสถานะของบริการ รวมถึงการเข้าสู่ระบบที่สำเร็จ ตรวจสอบบันทึกอีกครั้งเพื่อหาข้อผิดพลาด PAM ใหม่ และลบการตั้งค่าการดีบักชั่วคราวใดๆ ที่มีpam-config --deleteตัวเลือกที่ตรงกันเมื่อการทดสอบเสร็จสิ้น

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

คุณควรหยุดรถและใช้โหมดกู้ภัยเมื่อใด?

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

สำหรับโครงสร้างไฟล์ PAM ที่ถูกต้อง แฟล็กโมดูลpam-configพฤติกรรม และขั้นตอนการกู้คืน โปรดใช้คู่มือ PAM ของ SUSE SLES 15 SP7 ที่ตรงกับเวอร์ชัน และคู่มือปัญหาทั่วไปของ SUSEสแต็ก PAM เป็นนโยบายด้านความปลอดภัย ดังนั้นควรทำการเปลี่ยนแปลงที่น้อยที่สุดเท่าที่จำเป็น จากนั้นตรวจสอบทั้งการเข้าถึงและข้อจำกัด