Mối quan hệ phức tạp Kerberos và LDAP

Tôi gặp vấn đề trong việc hiểu mối quan hệ giữa LDAP và Kerberos (Về mặt khái niệm).

Tôi hiểu LDAP là một dịch vụ thư mục và Kerberos là một dịch vụ xác thực.

Chúng tôi cũng biết rằng LDAP cũng có khả năng lưu trữ mật khẩu, nhưng thiết kế của LDAP là thư mục có thể truy cập công khai và không phù hợp để lưu trữ thông tin nhạy cảm. Đó là lý do tại sao nó được ưu tiên ủy quyền xác thực cho một dịch vụ khác, như Kerberos.

Bây giờ những gì tôi không hiểu là hai câu hỏi:

1. Máy chủ nào gửi khách hàng yêu cầu của họ khi người dùng cố gắng đăng nhập? Trực giác của tôi nói với tôi rằng nó phải là máy chủ Kerberos. Nếu có, máy chủ LDAP đi vào đâu?
2. Trường hợp nào sysadmin đặt quyền? Trong trường hợp này, trực giác của tôi cho tôi biết LDAP. Tôi có thể tưởng tượng rằng có thể có một mục nhập cho mỗi hệ thống và / hoặc dịch vụ và người dùng sẽ được cấp quyền truy cập vào chúng thông qua tư cách thành viên nhóm hoặc trực tiếp. Nếu có, điều đó có nghĩa là máy chủ LDAP (thông qua giao diện như phpLDAPadmin) sẽ đặt các nhóm và người dùng phù hợp trong máy chủ Kerberos?

Tôi đặc biệt bối rối vì tôi thấy mối liên hệ giữa LDAP và Kerberos trong cả hai tài liệu. LDAP nói về việc ủy ​​quyền xác thực cho Kerberos đây và Kerberos nói về việc có LDAP làm phụ trợ đây .

Tất cả các tài liệu tôi đọc dường như là những mảnh ghép mà tôi không thể xoay xở được. Tôi đánh giá cao nếu ai đó có thể giải thích làm thế nào để làm như vậy.

Ồ, đó là một thời gian dài. Hãy xem những gì tôi có thể nhớ.

Có, nó chắc chắn có thể gây nhầm lẫn bởi vì bạn có thể sử dụng Kerberos để xác thực LDAP và bạn cũng có thể để Kerberos sử dụng LDAP làm phụ trợ. Mặc dù chúng không giống nhau, nhưng thật khó để phân biệt cái nào đang được nói đến khi bạn cố gắng tìm kiếm nó. Tôi chỉ có thể nói về LDAP bằng cách sử dụng Kerberos để xác thực vì tôi không có kinh nghiệm với nó theo cách khác.

1. Trực giác của bạn là đúng rằng nó sử dụng máy chủ Kerberos. Theo tôi hiểu, khách hàng yêu cầu TGT từ máy chủ Kerberos CHO máy chủ LDAP (sử dụng tên chính của dịch vụ là "ldap/hostname@DOMAIN.NAME" hoặc tương tự). Sau đó, khách hàng có thể sử dụng điều này để đăng nhập vào máy chủ LDAP vì nó có thể xác thực vé. Mật khẩu máy khách không bao giờ được gửi đến máy chủ LDAP.
2. Đây là nếu bạn đang sử dụng LDAP làm phụ trợ cho Kerberos tôi tưởng tượng. Bạn có thể sử dụng thư mục LDAP tại đây để lưu các thuộc tính và giá trị cho nhiều thứ khác nhau. Bạn, tất nhiên, không có để sử dụng LDAP làm back-end cho Kerberos.

Mọi thứ càng trở nên rối rắm hơn khi họ bắt đầu nói về SASL bởi vì thật khó để biết liệu họ đang nói về SASL ở mặt trước hay mặt sau của LDAP. Nói cách khác, nó có được khách hàng sử dụng để xác thực LDAP không? Hoặc nó đang được LDAP sử dụng để chuyển mật khẩu sang nguồn xác thực khác? Chỉ cần cẩn thận để xem cho.

Bên cạnh: Có thể sử dụng một liên kết đơn giản với LDAP, gửi mật khẩu đến máy chủ LDAP, sau đó chuyển mật khẩu đến một nguồn xác thực khác (như Kerberos). Nếu bạn đang làm một cái gì đó tương tự, thì thật tuyệt vì mật khẩu không được lưu trong LDAP, nhưng vì một liên kết đơn giản là văn bản rõ ràng, bạn muốn đảm bảo sử dụng TLS giữa máy khách và máy chủ LDAP.

Hy vọng điều này sẽ giúp một chút. Âm thanh như bạn về cơ bản đã có ý tưởng đúng.

Trực giác của bạn đang đi đúng hướng trong cả hai trường hợp. Hãy thực hiện từng câu hỏi của bạn từng người một.

1. Ở đây, dịch vụ kerberos là xác thực hệ thống. Khách hàng sẽ nhận được một vé được mã hóa từ máy chủ kerberos (sau khi xác thực thành công), và sau đó sẽ trình bày điều này cho máy chủ để cho thấy họ được xác thực.
2. Ở đây, dịch vụ ldap là ủy quyền hệ thống. Thông tin người dùng được lưu trữ trong thư mục (chẳng hạn như UID / GID, v.v.). Về bản chất, điều này thay thế thông tin trong / etc / passwd. Máy chủ ldap không cập nhật bất kỳ thông tin nào trong máy chủ kerberos.

Nó thực sự phụ thuộc vào thiết lập của bạn. Tôi đã vật lộn với điều này một chút, nhưng tôi không phải là chuyên gia.

Đối với người quản trị hệ thống, mối quan hệ giữa LDAP và Kerberos có thể đơn giản như một máy sử dụng cả hai. Thiết lập của bạn có thể đơn giản như sử dụng LDAP làm nguồn cho / etc / passwd và / etc / group qua nsswitch.conf (và một plugin như nss-pam-ldapd từ archlinux repo), để lại thuộc tính userPassword trong LDAP điểm hoặc dấu hoa thị (có nghĩa là không có mật khẩu và không có khả năng đăng nhập).

Kerberos KDC cung cấp xác thực mật khẩu cho bất kỳ máy nào bạn muốn, nơi tích hợp đăng nhập hệ thống sẽ khác nhau tùy thuộc vào dịch vụ mà nó cung cấp. Chẳng hạn, nếu đó là một máy từ xa chỉ yêu cầu truy cập qua ssh, LDAP vẫn cung cấp thông tin giống như mọi nơi khác, nhưng Kerberos chỉ cần một vài dòng trong tệp cấu hình ssh. Trên một hệ thống khác yêu cầu tích hợp đăng nhập đầy đủ, điều này có thể trở thành một nỗi đau lớn ở mông, bởi vì nó đòi hỏi phải thực hiện nhiều thay đổi đối với cấu hình PAM. Điều này thật dễ dàng trong các máy khách RHEL với authconfig, nhưng hy vọng nó sẽ là một vấn đề đau đầu lớn ở nơi khác trừ khi bạn cảm thấy thoải mái với PAM. Điều tích cực về việc làm cho nó hoạt động với PAM là hầu hết các chương trình (như ssh) có thể sử dụng PAM, vì vậy bạn không cần phải lo lắng về cấu hình ssh nữa.

Nói cách khác, nếu KDC ngừng hoạt động, hệ thống sẽ không chấp nhận mật khẩu của bạn đúng hay không (nhưng nó biết bạn là người dùng vì LDAP) và nếu máy chủ LDAP ngừng hoạt động, hệ thống sẽ nghĩ tên người dùng của bạn không t tồn tại