ผู้ดูแลระบบดูแลรักษาบัญชีผู้ใช้ในเซิร์ฟเวอร์ linux หลายร้อยเครื่องอย่างไร

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

ส่วนประกอบกลางหนึ่งของ Active Directory คือ LDAP ซึ่งมีอยู่ใน Linux ในรูปแบบOpenLDAPและ389DS (และอื่น ๆ ) นอกจากนี้องค์ประกอบอื่น ๆ ที่สำคัญของ Kerberos มีให้บริการในรูปแบบของMIT KerberosและHeimdal ในที่สุดคุณสามารถเชื่อมต่อเครื่องของคุณกับ AD

คุณสามารถลองใช้หุ่นกระบอกสำหรับการจัดการผู้ใช้:

ทำไมต้องใช้ Puppet เพื่อจัดการบัญชีผู้ใช้? (และไม่ใช่ NIS, LDAP และอื่น ๆ )

ข้อดีอย่างหนึ่งของการจัดการบัญชีผู้ใช้ในหุ่นเชิดคือการกระจายอำนาจ บัญชีผู้ใช้แต่ละบัญชีเป็นเพียงบัญชีผู้ใช้ปกติบนเซิร์ฟเวอร์ที่ได้รับการจัดการ ไม่มีอะไรพิเศษเกี่ยวกับหุ่นของบัญชีผู้ใช้ที่สร้างขึ้นนอกเหนือจากความจริงที่พวกเขาสร้างขึ้นโดยหุ่นเชิดและไม่ใช่โดยผู้ดูแลระบบคน สิ่งที่ดีเกี่ยวกับเรื่องนี้คือถ้าโฮสต์หลักตายเราจะไม่สูญเสียการรับรองความถูกต้อง ซึ่งหมายความว่าเซิร์ฟเวอร์ puppetmaster ของเรา (หรือเซิร์ฟเวอร์ NIS / LDAP) ไม่จำเป็นต้องมีข้อกำหนดการใช้งานพิเศษใด ๆ หากมีเหตุฉุกเฉินเกิดขึ้นเราสามารถมุ่งเน้นไปที่การผลิตเซิร์ฟเวอร์ของเราและมุ่งเน้นไปที่การทำให้ผู้ดูแลหุ่นเชิดขึ้นบนพื้นฐานที่ "จำเป็น" ข้อเสียของเรื่องนี้ก็คือหุ่นเชิดไม่จำเป็นต้องออกแบบมาเพื่อจัดการบัญชีผู้ใช้เข้าสู่ระบบ "ปกติ" (ตรงข้ามกับบัญชีระบบ) วิธีที่ใหญ่ที่สุดที่เกิดขึ้นคือ แม้ว่าคุณจะสามารถตั้งรหัสผ่านเป็นหุ่นเชิด แต่หุ่นก็ตรวจสอบการตั้งค่าระบบ (ดี) อย่างต่อเนื่องและหากสังเกตว่ามีการเปลี่ยนรหัสผ่านก็จะทำการรีเซ็ต (ไม่ดี) ฉันไม่ต้องการตรวจสอบรหัสผ่านของผู้ใช้ในเครือข่ายของเราดังนั้นจึงจำเป็นต้องมีวิธีการตั้งรหัสผ่านและให้หุ่นเชิดหยุดการตรวจสอบรหัสผ่านนี้ โชคดีที่เมื่อคุณเข้าใจกลอุบายได้จริง ๆ แล้วค่อนข้างง่าย แต่ก่อนอื่นมานิยามกันก่อน

http://docs.puppetlabs.com/pe/2.5/console_auth.html

ในฐานะที่เป็น SvenW กล่าวถึงมี 389DS และ Kerberos ตั้งแต่ RHEL 6.2 Red Hat ได้รวมIPAไว้ในการจัดจำหน่าย (และอยู่ใน CentOS ด้วย) นี่เป็นชุดการจัดการข้อมูลประจำตัวแบบเต็มรูปแบบซึ่งประกอบด้วย 389DS และ Kerberos พร้อมการควบคุมตามนโยบายการรับรองความถูกต้องและการอนุญาตและ DNS ทางเลือก สามารถกำหนดค่าสำหรับการซิงค์ทางเดียวหรือสองทางด้วย Active Directory

IPA ค่อนข้างต้องการ SSSD บนโฮสต์ RHEL แต่ใช้งานไม่ได้ ฉันได้ทดสอบการเชื่อมต่อ Solaris 10 กับ IPA (ใช้งานได้ดี แต่เล่นลิ้นเล็กน้อย) IPA นั้นค่อนข้างตรงไปตรงมาสำหรับการติดตั้งสำหรับโฮสต์ RHEL

นี่คือพื้นฐานของโครงการFreeIPA

สำหรับบัญชีผู้ใช้เครือข่ายของคุณ OpenLDAP เช่น SvW ที่กล่าวถึง

คุณควรดูที่ "ระบบการจัดการการกำหนดค่า" เพื่อจัดการบัญชีท้องถิ่นของคุณและทุกอย่างอื่นบนเซิร์ฟเวอร์ของคุณ ดู CFEngine, Bcfg2, Puppet และ Chef หากคุณใช้ AWS พวกเขามีสิ่งที่ Chefy กับ OpsWorks

หากคุณต้องการจัดการเซิร์ฟเวอร์มากกว่า 100+ ตัวคุณมี Sysadmins 10 ตัวหรือใช้ซอฟต์แวร์จัดการการกำหนดค่า

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

อาจมีประโยชน์น้อยกว่าหากคุณเป็นร้าน Unix เพียงแห่งเดียว - แต่ฉันไม่ได้เห็นของเหล่านั้นมากมาย แต่จริงๆแล้ว AD นั้นเป็นการผสานที่ดีขององค์ประกอบหลักของ LDAP และ Kerberos ฉันพบว่าบิตแดกดันจริง

แต่สิ่งที่คุณจะได้รับ 'ฟรี' คือบัญชีข้ามแพลตฟอร์มและการรวม Kerberos เพื่อให้คุณสามารถส่งออก NFSv4 โดยใช้ ACLs ที่รู้จัก 'CIFS' และ Krb5i / p NFS mounts พร้อมการพิสูจน์ตัวตนผู้ใช้ที่รัดกุม