Sự khôn ngoan phổ biến về xác thực Active Directory cho máy chủ Linux?

Sự khôn ngoan phổ biến trong năm 2014 về xác thực / tích hợp Active Directory cho các máy chủ Linux và các hệ điều hành Windows Server hiện đại (tập trung vào CentOS / RHEL) là gì?

Trong những năm qua kể từ những nỗ lực đầu tiên của tôi với hội nhập vào năm 2004, có vẻ như các thực tiễn tốt nhất xung quanh vấn đề này đã thay đổi. Tôi không chắc chắn phương pháp nào hiện đang có động lực nhất.

Trong lĩnh vực này, tôi đã thấy:

Winbind / Samba
thẳng lên LDAP
Đôi khi LDAP + Kerberos
Microsoft Windows và dịch vụ cho Unix (SFU)
Microsoft Identity Management cho Unix
NSLCD
SSSD
FreeIPA
Centrify
Powerbroker ( nhũ danh Tương tự như vậy )

Winbind luôn có vẻ khủng khiếp và không đáng tin cậy. Các giải pháp thương mại như Centrify và Likewise luôn hoạt động, nhưng dường như không cần thiết, vì khả năng này được đưa vào HĐH.

Một vài cài đặt gần đây tôi đã thực hiện có tính năng Quản lý danh tính Microsoft cho vai trò Unix được thêm vào máy chủ Windows 2008 R2 và NSLCD bên phía Linux (cho RHEL5). Điều này hoạt động cho đến khi RHEL6, trong đó việc thiếu bảo trì NSLCD và các vấn đề quản lý tài nguyên bộ nhớ đã buộc phải thay đổi SSSD. Red Hat dường như cũng ủng hộ cách tiếp cận SSSD, vì vậy điều đó tốt cho việc sử dụng của tôi.

Tôi đang làm việc với một bản cài đặt mới trong đó các bộ điều khiển miền là các hệ thống Windows 2008 R2 Core và không có khả năng thêm tính năng Quản lý danh tính cho vai trò Unix. Và tôi đã nói rằng tính năng này không còn tồn tại trong Windows Server 2012 R2 .

Lợi ích của việc cài đặt vai trò này là sự hiện diện của GUI này, đồng thời cho phép quản trị dễ dàng một bước các thuộc tính người dùng.

Nhưng...

Tùy chọn Công cụ Dịch vụ Thông tin Mạng (NIS) của Công cụ Quản trị Máy chủ Từ xa (RSAT) không được chấp nhận. Sử dụng các tùy chọn LDAP, Samba Client, Kerberos hoặc không phải của Microsoft.

Điều đó làm cho nó thực sự khó dựa vào nếu nó có thể phá vỡ tính tương thích về phía trước. Khách hàng muốn sử dụng Winbind, nhưng mọi thứ tôi thấy từ phía Red Hat đều chỉ ra việc sử dụng SSSD.

Cách tiếp cận đúng?
Làm thế nào để bạn xử lý này trong môi trường của bạn ?

Vào tháng 3 năm 2014, Red Hat đã xuất bản một kiến ​​trúc tham chiếu để tích hợp Red Hat Enterprise Server với Active Directory . (Tài liệu này chắc chắn phải là hiện tại và có liên quan.) Tôi ghét đăng bài này dưới dạng câu trả lời, nhưng thực sự chỉ là quá nhiều tài liệu để chuyển vào trường trả lời.

Tài liệu này (đã được sửa) đang nóng hổi trên báo chí dường như tập trung vào các tính năng mới của Red Hat Enterprise Linux (RHEL) 7. Nó đã được xuất bản cho Hội nghị thượng đỉnh vào tuần trước.

Nếu liên kết này bị cũ, xin vui lòng cho tôi biết và tôi sẽ cập nhật câu trả lời phù hợp.

Cá nhân tôi đã sử dụng WinBind khá đáng tin cậy để xác thực. Có lỗi dịch vụ không thường xuyên đòi hỏi phải có người có tài khoản root hoặc tài khoản cục bộ khác truy cập và trả lại winbindd. Điều này có thể có thể được xử lý thông qua giám sát thích hợp nếu bạn quan tâm để nỗ lực vào nó.

Điều đáng chú ý là Centrify không có chức năng bổ sung, mặc dù điều này có thể được cung cấp bởi quản lý cấu hình riêng biệt. (Con rối, v.v.)

Chỉnh sửa ngày 16 tháng 6 năm 14:

Hướng dẫn tích hợp Windows Red Enterprise Enterprise 7 Windows

re: "Các giải pháp thương mại như Centrify và Likewise luôn hoạt động, nhưng dường như không cần thiết, vì khả năng này được đưa vào hệ điều hành."

Vâng, tôi nghĩ rằng hầu hết chúng ta đã nghe trong nhiều năm rằng hệ điều hành XYZ cuối cùng đã phá vỡ câu đố tích hợp AD. Vấn đề là đối với nhà cung cấp hệ điều hành, tích hợp AD là một tính năng hộp kiểm, tức là họ cần cung cấp một thứ gì đó tương tự để có được hộp kiểm đó và hộp kiểm đó thường chỉ hoạt động trên ...

1. nền tảng hệ điều hành của họ và
2. phiên bản hiện tại của nền tảng đó và
3. đối với phiên bản mới hơn của Active Directory.

Thực tế là hầu hết các môi trường không nguyên khối về mặt nhà cung cấp hệ điều hành và phiên bản HĐH, và sẽ có các phiên bản AD cũ hơn. Đó là lý do tại sao một nhà cung cấp như Centrify phải hỗ trợ hơn 450 hương vị UNIX / Linux / Mac / vv. so với Windows 2000 đến Windows 2012 R2, không chỉ là RHEL 7 nữa Windows 2012 R2.

Ngoài ra, bạn cần phải xác định cách triển khai AD của mình, hỗ trợ tích hợp AD của nhà cung cấp hệ điều hành cũng chỉ đọc Bộ điều khiển miền (RODCs), tin tưởng một chiều, cung cấp hỗ trợ đa rừng, v.v. Và nếu bạn có trước không gian UID hiện tại (mà bạn sẽ), có các công cụ di chuyển để di chuyển UID vào AD. Và hỗ trợ AD của nhà cung cấp hệ điều hành có khả năng ánh xạ nhiều UID thành một AD duy nhất trong các tình huống trong đó không gian UID của bạn không bằng phẳng. Và những gì về ... tốt, bạn có ý tưởng.

Sau đó, có câu hỏi về hỗ trợ ...

Điểm tích hợp AD có vẻ dễ hiểu về mặt khái niệm và có thể "miễn phí" với HĐH mới nhất của nhà cung cấp và có thể hoạt động nếu bạn chỉ có một phiên bản HĐH từ một nhà cung cấp và có vanilla AD là phiên bản mới nhất và bạn có một hợp đồng hỗ trợ cao cấp với nhà cung cấp hệ điều hành, những người sẽ cố gắng hết sức để khắc phục mọi sự cố sẽ xảy ra. Nếu không, bạn có thể muốn xem xét một giải pháp bên thứ ba chuyên ngành.

Tùy chọn Công cụ Dịch vụ Thông tin Mạng (NIS) của Công cụ Quản trị Máy chủ Từ xa (RSAT) không được chấp nhận.

Điều này không gây ngạc nhiên cho tôi - NIS là bằng chứng cho thấy Sun ghét chúng tôi và muốn chúng tôi phải khổ sở.

Sử dụng các tùy chọn LDAP, Samba Client, Kerberos hoặc không phải của Microsoft.

Đây là lời khuyên tốt. Đưa ra các lựa chọn tôi sẽ nói "Sử dụng LDAP gốc (qua SSL, vui lòng)" - có nhiều tùy chọn có sẵn cho việc này, hai tùy chọn tôi quen thuộc nhất là pam_ldap + nss_ldap (từ PADL) hoặc nss -pam- ldapd (có nguồn gốc là một ngã ba và đã thấy sự phát triển và cải tiến liên tục).

Vì bạn đang hỏi về RedHat, điều đáng chú ý là RedHat cung cấp cho bạn các lựa chọn thay thế khác bằng SSSD.
Nếu môi trường của bạn là toàn RedHat (hoặc chỉ có một số lượng lớn các hệ thống RedHat) nhìn vào "Cách làm việc RedHat" được hỗ trợ chính thức chắc chắn sẽ đáng để bạn dành thời gian.

Vì bản thân tôi chưa có kinh nghiệm với RedHat / SSSD, tôi chỉ đi theo các tài liệu, nhưng có vẻ như nó khá mạnh mẽ và được thiết kế tốt.

Trong số các phương pháp được đề xuất, hãy để tôi cung cấp cho bạn danh sách ưu / nhược điểm:

Thẳng lên Kerberos / LDAP

Ưu điểm: Hoạt động tuyệt vời khi được cấu hình đúng. Hiếm khi phá vỡ, kiên cường, sẽ tồn tại sự cố mạng. Không cần thay đổi trong AD, không thay đổi lược đồ, không cần quyền truy cập của Quản trị viên vào AD. Miễn phí.

Nhược điểm: Tương đối khó cấu hình. Nhiều tập tin cần phải được thay đổi. Sẽ không hoạt động nếu máy chủ xác thực (Kerberos / LDAP) không khả dụng.

Winbind

Ưu điểm: Dễ cấu hình. Chức năng sudo cơ bản. Miễn phí.

Nhược điểm: Hỗ trợ chuyên sâu. Không kiên cường mạng. Nếu có sự cố mạng, máy linux có thể bị loại khỏi AD yêu cầu đăng ký lại máy chủ, một nhiệm vụ hỗ trợ. Yêu cầu quyền truy cập vào tài khoản quản trị viên của AD. Có thể thực hiện thay đổi lược đồ trong AD.

Ly tâm / Tương tự như vậy, vv

Ưu điểm: Tương đối dễ cấu hình.

Nhược điểm: Thay đổi chức năng sudo thành độc quyền, khó hỗ trợ hơn. Chi phí giấy phép cho mỗi máy chủ. Cần thêm kỹ năng để quản lý.

SSSD

Ưu điểm: Một tập tin cấu hình, dễ cấu hình. Hoạt động với tất cả các phương thức xác thực hiện tại và tương lai. Có thể mở rộng, phát triển cùng với hệ thống. Sẽ làm việc trong chế độ ngắt kết nối. Mạng kiên cường. Không cần thực hiện bất kỳ thay đổi nào đối với lược đồ AD. Không cần thông tin quản trị viên AD. Miễn phí, được hỗ trợ.

Nhược điểm: Không có dịch vụ giành chiến thắng như cập nhật tự động DNS. Cần cấu hình cổ phiếu CIFS.

Tóm lược

Nhìn vào ưu điểm và nhược điểm, SSSD là người chiến thắng rõ ràng. Nếu đó là một hệ thống mới, không có lý do gì để sử dụng bất cứ thứ gì ngoài SSSD. Nó là một nhà tích hợp hoạt động với tất cả các phương thức xác thực hiện tại và có thể phát triển cùng với hệ thống vì các phương thức mới có thể được thêm vào khi khả dụng. Nó sử dụng các phương thức linux gốc và đáng tin cậy và nhanh hơn nhiều. Nếu bộ nhớ đệm được bật, các hệ thống sẽ hoạt động ngay cả trong một hệ thống hoàn toàn bị ngắt kết nối với lỗi mạng hoàn toàn.

Winbind có thể được sử dụng cho các hệ thống hiện có nếu có quá nhiều công việc liên quan để thay đổi.

Centrify đã có vấn đề với việc tích hợp có thể gây tốn kém. Hầu hết các lỗi đã được sửa trong bản phát hành mới, nhưng vẫn có một số lỗi gây đau đầu.

Tôi đã làm việc với tất cả các phương pháp này và SSSD là người chiến thắng rõ ràng. Ngay cả đối với các hệ thống cũ, ROI để chuyển đổi từ Winbind sang SSSD là rất cao. Trừ khi có một lý do cụ thể để không sử dụng SSSD, hãy luôn sử dụng SSSD.

Phải bình luận về điều này:

Điều đáng chú ý là Centrify không có chức năng bổ sung, mặc dù điều này có thể được cung cấp bởi quản lý cấu hình riêng biệt. (Con rối, v.v.)

Là một người làm việc với Centrify không chắc nhận xét đó đến từ đâu. Nhìn vào điều này và bạn có thể thấy rằng có rất nhiều tính năng bạn không có được với một công cụ cấu hình mgmt ala Puppet. Ví dụ: hỗ trợ ánh xạ nhiều UID vào một tài khoản AD (Vùng), hỗ trợ cho các ủy thác miền Active Directory đầy đủ (mà giải pháp Red Hat tài liệu trên trang 3 không hỗ trợ), v.v.

Nhưng trở lại với hướng dẫn Red Hat này. Thật tuyệt khi Red Hat xuất bản này, các tùy chọn đều tốt. Lưu ý rằng nó cung cấp cho khách hàng 10 tùy chọn để thực hiện tích hợp AD cơ bản. Hầu hết các tùy chọn là các biến thể của Winbind và trang 15 liệt kê các ưu điểm và nhược điểm của từng loại, và có một loạt các bước thủ công cần thiết cho mỗi (với các nhược điểm / thiếu chức năng tương ứng ở trên). Ưu điểm của Centrify Express là theo các bình luận viên khác ở trên là:

1. thật đơn giản để cài đặt tất cả các bước thủ công và ...
2. là miễn phí và ...
3. không giới hạn ở Red Hat V7, điều quan trọng như câu hỏi liên quan đến Linux, không chỉ là một biến thể - Centrify hỗ trợ hơn 300 hương vị của * nix và ...
4. hỗ trợ tất cả các biến thể của Windows AD, không chỉ Windows 2008. Họ đã xuất bản một bản so sánh giữa Centrify và Winbind tại đây , nhưng nó không phải là nguồn mở.

Cuối cùng, nó sôi lên để bạn muốn tự cuộn nó hoặc đi với một giải pháp thương mại. Thực sự là một vấn đề mà bạn và cách bạn dành thời gian của bạn.