สำหรับเซิร์ฟเวอร์ SUSE Linux Enterprise Server 15 ทั่วไปที่ต้องการให้ผู้ใช้โดเมนล็อกอินเข้าสู่ระบบนั้น เอกสารของ SUSE ระบุว่า YaST User Logon Management ร่วมกับ SSSD เป็นตัวเลือกที่ดีที่สุดในสภาพแวดล้อม Active Directory ส่วนใหญ่ SSSD ให้บริการข้อมูลประจำตัวของ Linux และเส้นทางการตรวจสอบสิทธิ์ PAM ในขณะที่ Active Directory ยังคงเป็นแหล่งที่มาของบัญชีและการตรวจสอบสิทธิ์ Kerberos Winbind จะเหมาะสมกว่าเมื่อการออกแบบของคุณขึ้นอยู่กับ NTLM หรือการสนับสนุนความเชื่อถือข้ามโดเมน หากคุณต้องการระบบอัตโนมัติ SUSE ยังระบุถึงการเข้าร่วมด้วยrealmdWinbind ซึ่งเป็นเครื่องมือค้นหาโดเมนและการเป็นสมาชิก ดังนั้นโปรดตรวจสอบซอฟต์แวร์ไคลเอ็นต์และนโยบายการเข้าถึงที่ระบบของคุณจะกำหนดค่าก่อนที่จะใช้งานในวงกว้าง
คู่มือนี้อ้างอิงจากคู่มือความปลอดภัยและการเสริมความแข็งแกร่งของ SLES 15 SP7 ซึ่งตรวจสอบแล้วเมื่อวันที่ 6 ตุลาคม 2026 Service Pack ของ SUSE อาจแตกต่างกัน และคำแนะนำด้านล่างนี้เป็นขั้นตอนที่อ้างอิงจากเอกสาร ไม่ใช่การรับประกันว่าคำสั่งเหล่านี้ใช้งานได้กับโดเมนของคุณ โปรดแทนที่ชื่อโดเมนและชื่อโฮสต์ในตัวอย่างด้วยค่าจากสภาพแวดล้อมของคุณ ทดสอบก่อนบนเครื่อง SLES ที่ไม่สำคัญ และเตรียมบัญชีผู้ดูแลระบบในเครื่องไว้เผื่อกรณีที่การตรวจสอบสิทธิ์โดเมนมีการกำหนดค่าผิดพลาด
เลือกวิธีการผสานรวมที่เหมาะสมกับงาน
| วิธี | เหมาะสมเมื่อ | การแลกเปลี่ยนที่ต้องวางแผน |
| การจัดการการเข้าสู่ระบบของผู้ใช้ YaST ด้วย SSSD | คุณต้องการการค้นหาผู้ใช้และกลุ่ม AD มาตรฐาน รวมถึงการเข้าสู่ระบบ PAM บนไคลเอ็นต์ SLES หรือเซิร์ฟเวอร์อเนกประสงค์ | YaST ใช้การตั้งค่าผ่าน SSSD และบริการระบบที่เกี่ยวข้อง ตรวจสอบรูปแบบชื่อ กฎการเข้าถึง และพฤติกรรมของไดเร็กทอรีโฮมก่อนการใช้งานจริง |
| YaST Windows Domain Membership with Winbind | คุณจำเป็นต้องมีการเป็นสมาชิกโดเมนที่มุ่งเน้น Samba, การสนับสนุน NTLM หรือพฤติกรรมความเชื่อถือข้ามฟอเรสต์ | ระบบนี้ใช้ Winbind แทน SSSD สำหรับการระบุตัวตนและการตรวจสอบสิทธิ์โดเมน ดังนั้นควรหลีกเลี่ยงการใช้ผู้ให้บริการทั้งสองรายซ้อนทับกันในการกำหนดค่าการเข้าสู่ระบบเดียวกัน |
| บรรทัดคำสั่ง realmd | คุณต้องการเวิร์กโฟลว์แบบเทอร์มินัล หรือต้องการเขียนสคริปต์สำหรับการค้นหาและลงทะเบียนโดเมน | ตัวเลือกการลงทะเบียนและการกำหนดค่าไคลเอ็นต์ที่ได้นั้นขึ้นอยู่กับส่วนประกอบที่ติดตั้งและนโยบาย ตรวจสอบขอบเขตที่ค้นพบและการกำหนดค่าที่ได้แทนที่จะสันนิษฐานว่าค่าเริ่มต้นตรงกับกฎการเข้าถึงในสภาพแวดล้อมการใช้งานจริงของคุณ |
SUSE ระบุว่า YaST ที่ใช้ SSSD เป็นตัวเลือกที่เหมาะสมสำหรับการเข้าร่วม Active Directory ส่วนใหญ่ และแนะนำ Winbind สำหรับกรณีที่ต้องการ NTLM หรือความเชื่อถือข้ามโดเมน นี่เป็นเพียงจุดเริ่มต้นที่ใช้งานได้จริง ไม่ใช่สิ่งที่จะมาทดแทนการทดสอบความต้องการเฉพาะของแอปพลิเคชัน เช่น การให้บริการไฟล์ Samba, กฎ sudo, การค้นหาคีย์ SSH หรือการชนกันของชื่อโดเมนหลายโดเมน สำหรับระบบล็อกอิน Linux ทั่วไป ให้เริ่มต้นด้วย SSSD เว้นแต่จะมีข้อกำหนดที่ระบุไว้เป็นอย่างอื่น
สิ่งที่ต้องเตรียมก่อนเชื่อมต่อ SLES กับ Active Directory
- ชื่อโฮสต์ที่เสถียร:เลือกชื่อโฮสต์แบบเต็มที่ต้องการ และตรวจสอบให้แน่ใจว่าสามารถใช้งานได้อย่างสม่ำเสมอในเครือข่ายของคุณและใน Active Directory ประสานงานกับทีมผู้ดูแลระบบไดเร็กทอรีเกี่ยวกับหลักเกณฑ์การตั้งชื่อบัญชีคอมพิวเตอร์
- การทำงานของ DNS ที่รองรับ Active Directory:ไคลเอ็นต์ SLES ต้องสอบถามเซิร์ฟเวอร์ DNS ที่สามารถแก้ไขโซน Active Directory และระเบียนบริการ (SRV) ได้ การใช้ตัวแก้ไขสาธารณะเพียงอย่างเดียวมักจะทำให้การค้นหาโดเมนล้มเหลว
- การซิงโครไนซ์เวลา: Kerberos ขึ้นอยู่กับว่านาฬิกาของไคลเอ็นต์และตัวควบคุมโดเมนนั้นตรงกันอย่างใกล้เคียง ตรวจสอบการซิงโครไนซ์ NTP ก่อนแก้ไขปัญหาเกี่ยวกับรหัสผ่านหรือ SSSD
- การเข้าถึงเครือข่ายไปยังตัวควบคุมโดเมน:ตรวจสอบให้แน่ใจว่าไฟร์วอลล์และการกำหนดเส้นทางอนุญาตโปรโตคอลและพอร์ตที่จำเป็นสำหรับการออกแบบ AD ขององค์กรของคุณ รวมถึง DNS, Kerberos, LDAP และการรับส่งข้อมูลแคตตาล็อกส่วนกลางหรือการเปลี่ยนรหัสผ่านที่จำเป็น อย่าเปิดทุกพอร์ตอย่างกว้าง ๆ ให้ผู้ดูแลระบบ AD/เครือข่ายจัดเตรียมกฎที่ได้รับอนุมัติ
- ข้อมูลประจำตัวการลงทะเบียนที่ได้รับอนุญาต:ใช้บัญชีที่ได้รับอนุญาตให้เพิ่มหรือใช้งานวัตถุคอมพิวเตอร์ในหน่วยงานที่ถูกต้อง หลีกเลี่ยงการใช้บัญชีที่มีสิทธิ์สูงเป็นประจำเมื่อมีสิทธิ์เข้าร่วมที่ได้รับมอบหมายอยู่แล้ว
- การเข้าถึงเพื่อกู้คืน:เก็บรักษาข้อมูลการเข้าสู่ระบบของผู้ดูแลระบบในเครื่องที่ผ่านการทดสอบแล้ว และวิธีการเข้าถึงคอนโซล อย่ากำหนดให้โดเมนเป็นเส้นทางเดียวในการเข้าถึงเซิร์ฟเวอร์ก่อนที่จะตรวจสอบความถูกต้องของเส้นทางการเข้าสู่ระบบใหม่
SUSE เน้นย้ำเป็นพิเศษถึงความสำคัญของ DNS ที่สามารถเข้าถึงได้จาก Active Directory และเวลาที่ถูกต้องสำหรับ Kerberos คู่มือของ SUSE ระบุว่าโดเมนที่ลงท้ายด้วย .dip .localอาจขัดแย้งกับ DNS แบบมัลติแคสต์ในบางสถานการณ์การเข้าร่วม หาก Active Directory ของคุณใช้คำต่อท้ายดังกล่าว โปรดตรวจสอบผลกระทบต่อเวอร์ชัน SLES และการกำหนดค่าเครือข่ายของคุณกับผู้ดูแลระบบไดเร็กทอรีก่อนที่จะเปลี่ยนแปลงการตั้งชื่อหรือการตั้งค่าตัวแก้ไข
hostnamectl --static
hostname -f
timedatectl status
getent hosts ad01.corp.example.com
host -t SRV _ldap._tcp.dc._msdcs.corp.example.com
คำสั่ง นี้hostอาจต้องการแพ็คเกจยูทิลิตี้ DNS ในการติดตั้งแบบขั้นต่ำ การตรวจสอบเหล่านี้ไม่ได้พิสูจน์ว่าเส้นทางไฟร์วอลล์ที่จำเป็นทั้งหมดเปิดอยู่ แต่ช่วยตรวจจับปัญหาการแก้ไขชื่อโดเมนและปัญหาเวลาที่พบบ่อยก่อนการลงทะเบียน
เข้าร่วมโดเมนโดยใช้ YaST และ SSSD
- ตั้งค่าตัวแก้ไข DNSเปิด YaST แล้วเลือกการตั้งค่าเครือข่ายจากนั้น เลือก ชื่อโฮสต์/DNSกำหนดค่าเซิร์ฟเวอร์ DNS ของ AD หรือตัวแก้ไขภายในที่ส่งต่อโซน AD อย่างถูกต้อง บันทึกและตรวจสอบว่าโฮสต์สามารถแก้ไขตัวควบคุมโดเมนและระเบียนบริการ AD ได้หรือไม่
- เปิดการจัดการการเข้าสู่ระบบของผู้ใช้จากหน้าต่างหลักของ YaST ให้เปิดการจัดการการเข้าสู่ระบบของผู้ใช้และเลือกเปลี่ยนการตั้งค่านี่คือโมดูลการตรวจสอบสิทธิ์แบบ SSSD ในคู่มือ SLES 15 SP7 ซึ่งแตกต่างจาก โมดูล การเป็นสมาชิกโดเมนของ Windowsที่ใช้ Winbind
- เพิ่มโดเมน ADเลือกเพิ่มโดเมนป้อนชื่อโดเมน DNS เช่น
corp.example.comและเลือกMicrosoft Active Directoryสำหรับทั้งข้อมูลประจำตัวและการตรวจสอบสิทธิ์ ตรวจสอบให้แน่ใจว่าได้เปิดใช้งานโดเมนแล้ว หากการค้นหา DNS อัตโนมัติไม่เหมาะสมในเครือข่ายของคุณ ให้ระบุชื่อโฮสต์ตัวควบคุมโดเมนที่ได้รับอนุมัติตามที่คู่มืออธิบายไว้
- ตรวจสอบชื่อเครื่องและผลการค้นหาเปรียบเทียบชื่อโฮสต์ในเครื่องกับชื่อคอมพิวเตอร์ที่ต้องการใน Active Directory (AD) แก้ไขความไม่ตรงกันใดๆ ก่อนการลงทะเบียน YaST ควรค้นหาเซิร์ฟเวอร์ AD และรายงานว่าไคลเอ็นต์ยังไม่ได้ลงทะเบียน หากการค้นหาล้มเหลว ให้กลับไปตรวจสอบ DNS เวลา การกำหนดเส้นทาง และไฟร์วอลล์ แทนที่จะลองใช้ผู้ให้บริการการตรวจสอบสิทธิ์แบบสุ่ม
- ลงทะเบียนด้วยบัญชีที่ได้รับอนุญาตป้อนข้อมูลรับรอง AD ที่ได้รับอนุญาตให้เข้าร่วมเครื่อง YaST สามารถติดตั้งซอฟต์แวร์ที่ขาดหายไปในระหว่างกระบวนการนี้ได้ หน้าต่างโต้ตอบอาจมีตัวเลือกให้เขียนทับการกำหนดค่า Samba เปิดใช้งานเฉพาะเมื่อการเปลี่ยนแปลงนั้นมีไว้สำหรับการตั้งค่า Samba/AD ของคุณ และรักษารูปแบบการกำหนดค่าที่มีอยู่ก่อนหากมีการใช้งานบริการ Samba อยู่แล้ว
- เปิดใช้งานพฤติกรรมการเข้าสู่ระบบที่ต้องการในส่วน " จัดการการเข้าสู่ระบบของผู้ใช้โดเมน"ให้เปิดใช้งานการเข้าสู่ระบบของผู้ใช้โดเมนหลังจากตัดสินใจแล้วว่าบัญชีใดควรมีสิทธิ์เข้าถึง กำหนดค่าการสร้างไดเร็กทอรีโฮมในเครื่องหากผู้ใช้ต้องการใช้งาน เอกสารของ SUSE อธิบาย ตัวเลือก
fallback_homedirต่างๆoverride_homedirและแสดง/home/%uรูปแบบที่เป็นไปได้ ในสภาพแวดล้อมแบบหลายโดเมน ให้ออกแบบเส้นทางที่ไม่ซ้ำกันและตรวจสอบคู่มือ SSSD ก่อนที่จะใช้ชื่อผู้ใช้แบบสั้นเพียงอย่างเดียว
- บันทึก ตรวจสอบ และทดสอบด้วยผู้ใช้ที่ไม่ได้รับสิทธิ์พิเศษใช้การตั้งค่า ตรวจสอบว่าโดเมนและตัวเลือกที่เลือกถูกต้อง จากนั้นทดสอบด้วยบัญชีโดเมนปกติที่คอนโซลหรือผ่านบริการล็อกอินจริงที่คุณวางแผนจะใช้ อย่าทดสอบเฉพาะกับบัญชีที่เข้าร่วมเครื่องเท่านั้น
คุณตรวจสอบการเข้าร่วม SSSD ได้อย่างไร?
ตรวจสอบว่า SSSD ทำงานอยู่ ตรวจสอบว่า NSS สามารถระบุโดเมนที่รู้จักได้ และตรวจสอบว่าการเข้าสู่ระบบจริงสำเร็จ หลังจากผู้ใช้ทดสอบเข้าสู่ระบบแล้ว ให้ตรวจสอบหาตั๋ว Kerberos SUSE แสดงรายการนี้ ไว้ klistใน รายการ getent passwdตรวจสอบการเชื่อมต่อ
systemctl status sssd
getent passwd 'alex@corp.example.com'
id 'alex@corp.example.com'
klist
สตริงระบุตัวตนที่แน่นอนขึ้นอยู่กับการตั้งค่าการตั้งชื่อของ SSSD บางสภาพแวดล้อมใช้DOMAIN\userชื่อแบบอื่นแทนชื่อแบบ UPN หากgetentไม่พบข้อมูลใดๆ ให้ตรวจสอบว่าคุณกำลังสอบถามรูปแบบชื่อและโดเมนที่กำหนดค่าไว้ จากนั้นตรวจสอบบันทึกการบริการ:
sudo journalctl -u sssd --since "15 minutes ago"
การค้นหาสำเร็จเพียงอย่างเดียวไม่ได้พิสูจน์ว่าผู้ใช้สามารถล็อกอินได้ และตั๋ว Kerberos ที่มีอยู่แล้วไม่ได้พิสูจน์ว่าทุกแอปพลิเคชันใช้สแต็ก PAM ที่ตั้งใจไว้ ทดสอบเซสชันใหม่ การเปลี่ยนรหัสผ่านหากจำเป็น การอนุญาตตามกลุ่ม และเส้นทางการล็อกอิน SSH หรือเดสก์ท็อปที่เกี่ยวข้อง ตรวจสอบให้แน่ใจว่าการเข้าถึงถูกจำกัดเฉพาะบุคคลที่คุณต้องการอนุญาตเท่านั้น
SSSD หรือ Winbind: การแลกเปลี่ยนแบบไหนสำคัญที่สุด?
สำหรับไคลเอ็นต์ SLES ส่วนใหญ่ที่ต้องการข้อมูลประจำตัว AD และการเข้าสู่ระบบแบบโต้ตอบ SSSD เป็นตัวเลือกที่ตรงไปตรงมาซึ่งได้รับการสนับสนุนจากคำแนะนำการจัดการการเข้าสู่ระบบของผู้ใช้ของ SUSE SSSD ผสานรวมการค้นหาข้อมูลประจำตัวและการตรวจสอบสิทธิ์ PAM และสามารถแคชข้อมูลเพื่อความยืดหยุ่นเมื่อไดเร็กทอรีไม่สามารถเข้าถึงได้ชั่วคราว อย่างไรก็ตาม การเข้าถึงที่แคชไว้มีข้อจำกัด: การเข้าสู่ระบบครั้งแรกไม่สามารถอาศัยข้อมูลประจำตัวที่แคชไว้ได้ และทรัพยากรที่สนับสนุนโดยไดเร็กทอรีหรือการเปลี่ยนแปลงรหัสผ่านยังคงต้องการตัวควบคุมโดเมนที่สามารถเข้าถึงได้ ควรสร้างและทดสอบนโยบายการเข้าสู่ระบบแบบออฟไลน์ของคุณ แทนที่จะมองว่าการแคชเป็นโซลูชันที่สมบูรณ์แบบสำหรับการหยุดชะงักของ AD
เลือก Winbind เมื่อความต้องการขึ้นอยู่กับการผสานรวมโดเมนของ Samba, NTLM หรือความเชื่อถือข้ามฟอเรสต์โดยเฉพาะ ไม่ใช่แค่ตัวเลือกเสริมสำหรับ SSSD เท่านั้น แต่ละเส้นทางใช้เดมอนและส่วนประกอบ NSS/PAM ที่แตกต่างกัน ระบุว่าบริการใดเป็นเจ้าของการค้นหาโดเมนและการเข้าสู่ระบบ และหลีกเลี่ยงการผสมผสานการแก้ไข PAM/NSS ด้วยตนเองแบบเก่ากับการตั้งค่าที่จัดการโดย YaST
ใช้realmdเมื่อเวิร์กโฟลว์เชลล์ที่ทำซ้ำได้มีความสำคัญ คู่มือการดูแลระบบจัดเก็บข้อมูล SLES 15 SP7 ของ SUSE อธิบายrealm discover --verboseเกี่ยวกับการค้นหาโดยใช้ DNS realm join --verboseการลงทะเบียน และrealm permitสิทธิ์การเข้าสู่ระบบ ตรวจสอบว่าซอฟต์แวร์ไคลเอ็นต์ใดถูกเลือก และการกำหนดค่า SSSD ใดที่สร้างขึ้นในเวอร์ชันของคุณ หลีกเลี่ยงการอนุญาตให้ทุกคนเข้าถึงได้ในวงกว้างในสภาพแวดล้อมการใช้งานจริง เว้นแต่จะเป็นนโยบายที่ระบุไว้อย่างชัดเจน
ข้อผิดพลาดที่พบบ่อยและการตรวจสอบครั้งต่อไป
- การค้นหาโดเมนไม่พบข้อมูลใดๆ:ตรวจสอบเซิร์ฟเวอร์ DNS ของไคลเอ็นต์และระเบียน AD SRV จากนั้นยืนยันว่าโฮสต์สามารถเข้าถึงตัวควบคุมโดเมนที่แสดงอยู่ได้
- เกิดข้อผิดพลาด Kerberos แม้จะใส่รหัสผ่านถูกต้อง:ตรวจสอบการซิงโครไนซ์เวลาของระบบ ชื่อ DNS ที่ใช้สำหรับตัวควบคุมโดเมน และตรวจสอบว่าบัญชีคอมพิวเตอร์เปิดใช้งานและตั้งชื่ออย่างถูกต้องหรือไม่
- ผู้ใช้แก้ไขปัญหาได้แต่เข้าสู่ระบบไม่ได้:ตรวจสอบว่าการเข้าสู่ระบบโดเมนเปิดใช้งานอยู่ใน YaST แล้ว ตรวจสอบข้อจำกัดการเข้าถึงและสถานะบัญชีใน AD และตรวจสอบบันทึก SSSD/PAM
- การเข้าสู่ระบบใช้งานได้ แต่ไม่พบไดเร็กทอรีโฮม:โปรดยืนยันว่าการสร้างไดเร็กทอรีโฮมเปิดใช้งานอยู่ และเส้นทางที่กำหนดค่าไว้นั้นถูกต้องและไม่ซ้ำกันสำหรับผู้ใช้
- การเข้าร่วมล้มเหลวหลังจากการทดลองก่อนหน้านี้:ตรวจสอบวัตถุคอมพิวเตอร์ที่ล้าสมัย ชื่อโฮสต์ที่ซ้ำกัน การกำหนดค่า Winbind หรือ NSS/PAM ด้วยตนเองที่เหลืออยู่ และรหัสผ่านเครื่องที่ไม่ตรงกัน ประสานงานกับผู้ดูแลระบบ AD ก่อนที่จะลบวัตถุคอมพิวเตอร์หรือล้างข้อมูล SSSD ในเครื่อง
เมื่อไหร่ที่คุณควรหยุดและเลือกใช้วิธีอื่น?
หยุดการทดสอบก่อนเริ่มใช้งานจริง หากสภาพแวดล้อมของคุณต้องอาศัยพฤติกรรมการเชื่อถือข้ามฟอเรสต์, NTLM, บทบาทเซิร์ฟเวอร์ Samba, หลายฟอเรสต์ที่มีชื่อผู้ใช้สั้นซ้ำกัน หรือกฎการเข้าถึงที่ซับซ้อนซึ่งการตั้งค่าพื้นฐานของ YaST ไม่รองรับ เงื่อนไขเหล่านี้อาจเปลี่ยนแปลงผู้ให้บริการที่ต้องการ หรืออาจต้องมีการกำหนดค่า SSSD เพิ่มเติม ทดสอบด้วยบัญชีตัวแทนและบริการจริงในระบบทดสอบ และเก็บข้อมูลการเข้าสู่ระบบกู้คืนไว้จนกว่านโยบายจะได้รับการพิสูจน์แล้ว
สรุป:สำหรับเวิร์กสเตชันหรือเซิร์ฟเวอร์ SLES 15 SP7 มาตรฐานที่ต้องการข้อมูลประจำตัวและการเข้าสู่ระบบ Active Directory ให้เริ่มต้นด้วยวิธีการจัดการการเข้าสู่ระบบผู้ใช้ YaST ที่รองรับโดย SSSD ก่อนอื่นให้ตั้งค่า DNS, เวลา, การตั้งชื่อโฮสต์ และสิทธิ์การเข้าร่วมให้ถูกต้อง จากนั้นตรวจสอบการค้นหาชื่อ, Kerberos, การเข้าสู่ระบบ PAM และขอบเขตการเข้าถึง เลือกใช้ Winbind สำหรับข้อกำหนดเฉพาะของ Samba, NTLM หรือการใช้งานข้ามฟอเรสต์ที่ SUSE กำหนด และใช้realmdเมื่อเวิร์กโฟลว์แบบบรรทัดคำสั่งเหมาะสมกับกระบวนการทำงานของคุณมากกว่า
แหล่งที่มา: คู่มือความปลอดภัยและการเสริมความแข็งแกร่งของ SUSE SLES 15 SP7: การสนับสนุน Active Directory ; คู่มือการดูแลระบบจัดเก็บข้อมูล SUSE SLES 15 SP7: realmd ; SUSE SLES 15 SP7: ไคลเอ็นต์การตรวจสอบสิทธิ์และ SSSD ; บันทึกประจำรุ่นของ SUSE SLES 15 SP7