Đối phó với hàng trăm máy chủ RHEL, làm thế nào chúng ta có thể duy trì tài khoản root cục bộ và tài khoản người dùng mạng? Có một giải pháp loại thư mục hoạt động quản lý chúng từ một vị trí trung tâm?
Đối phó với hàng trăm máy chủ RHEL, làm thế nào chúng ta có thể duy trì tài khoản root cục bộ và tài khoản người dùng mạng? Có một giải pháp loại thư mục hoạt động quản lý chúng từ một vị trí trung tâm?
Câu trả lời:
Một thành phần trung tâm của Active Directory là LDAP, có sẵn trên Linux dưới dạng OpenLDAP và 389DS (và một số thứ khác). Ngoài ra, thành phần chính khác Kerberos có sẵn dưới dạng MIT Kerberos và Heimdal . Cuối cùng, bạn thậm chí có thể kết nối máy của bạn với AD.
sudoersquy tắc (hoặc cả hai).
Bạn có thể thử với con rối để quản lý người dùng:
Tại sao nên sử dụng rối để quản lý tài khoản người dùng? (và không phải NIS, LDAP, v.v.)
Một trong những lợi ích để quản lý tài khoản người dùng trong con rối là thực tế là nó được phân cấp. Mỗi tài khoản người dùng chỉ là một tài khoản người dùng bình thường trên máy chủ được quản lý. Không có gì đặc biệt về tài khoản người dùng mà con rối tạo ra ngoài thực tế chúng được tạo bởi con rối chứ không phải bởi người quản trị con người. Điều tuyệt vời ở đây là nếu máy chủ chính chết, chúng tôi không mất xác thực. Điều đó có nghĩa là máy chủ rối của chúng tôi (hoặc máy chủ NIS / LDAP) không cần có bất kỳ yêu cầu thời gian hoạt động đặc biệt nào. Nếu trường hợp khẩn cấp xảy ra, chúng ta có thể tập trung vào việc đưa các máy chủ sản xuất của mình lên và tập trung vào việc đưa con rối lên trên một cơ sở khi cần thiết. Nhược điểm của điều này là con rối không nhất thiết phải được thiết kế để quản lý các tài khoản người dùng đăng nhập bình thường của Wap (trái ngược với tài khoản hệ thống). Cách lớn nhất này xuất hiện là, mặc dù bạn có thể đặt mật khẩu trong con rối, con rối liên tục theo dõi cài đặt hệ thống (tốt) và nếu thông báo rằng mật khẩu đã thay đổi, sẽ đặt lại mật khẩu. (xấu) Tôi không muốn theo dõi mật khẩu người dùng trên mạng của chúng tôi, vì vậy cần có một cách để đặt mật khẩu và dừng rối theo dõi mật khẩu này. May mắn thay, một khi bạn tìm ra mánh khóe, điều này thực sự khá dễ dàng. Nhưng trước tiên, hãy lấy một số định nghĩa theo cách này.
Như SvenW đã đề cập, có 389DS và Kerberos. Kể từ RHEL 6.2, Red Hat đã đưa IPA vào bản phân phối (và do đó cũng nằm trong CentOS). Đây là bộ quản lý danh tính đầy đủ kết hợp 389DS và Kerberos, với quyền kiểm soát dựa trên chính sách đối với xác thực và ủy quyền và DNS tùy chọn. Nó thậm chí có thể được cấu hình để đồng bộ một chiều hoặc hai chiều với Active Directory.
IPA khá nhiều yêu cầu SSSD trên các máy chủ RHEL nhưng nó hoạt động mà không có nó. Tôi thậm chí đã thử kết nối Solaris 10 với IPA (hoạt động, nhưng hơi khó). IPA khá đơn giản để thiết lập cho các máy chủ RHEL.
Điều này dựa trên dự án FreeIPA .
Đối với tài khoản người dùng mạng của bạn, OpenLDAP như SvW đã đề cập.
Bạn cũng nên xem "Hệ thống quản lý cấu hình" để quản lý tài khoản cục bộ và mọi thứ khác trên máy chủ của bạn. Hãy xem CFEngine, Bcfg2, Puppet và Chef. Nếu bạn đang sử dụng AWS, họ có một điều Chefy với OpsWorks.
Nếu bạn thực sự cần quản lý hơn 100 máy chủ, bạn có 10 Sysadins hoặc bạn sử dụng phần mềm Quản lý cấu hình.
Đây có thể là một câu trả lời rõ ràng, nhưng 'sử dụng thư mục hoạt động'. Bạn cần sửa đổi lược đồ AD của chúng tôi một chút, để bao gồm các trường cụ thể unix, nhưng một khi bạn làm như vậy, bạn có một thư mục duy nhất của tất cả các tài khoản người dùng của bạn hoạt động đa nền tảng.
Có lẽ ít hữu ích hơn nếu bạn là cửa hàng chỉ dành cho Unix - nhưng thực tế tôi chưa thấy nhiều thứ như vậy. Nhưng AD thực sự là một sự chia lưới khá tốt của các yếu tố chính của LDAP và Kerberos. Tôi thấy điều đó thật mỉa mai.
Nhưng những gì bạn sẽ nhận được 'miễn phí' là các tài khoản đa nền tảng và tích hợp Kerberos để bạn có thể thực hiện xuất khẩu NFSv4 áp dụng 'ACLs được công nhận' CIFS và gắn kết NFS krb5i / p, với xác thực người dùng (er) mạnh mẽ.