Tôi quản lý mạng LAN với danh sách người dùng truy cập vào ngôi nhà dùng chung NFS của họ trong khi được xác thực thông qua NIS/YP (máy khách và máy chủ dựa trên CentOS/Fedora).
Tôi đang trong quá trình đau đớn để di chuyển ra khỏi NIS/YP (vốn đang bị loại bỏ dần dần nhưng không thể đảo ngược trên Red Hat và những thứ tương tự) sang phần thay thế có vẻ ít khó thiết lập nhất cho phần xác thực, SSSD (cho máy khách) và LDAP (đối với cơ sở dữ liệu người dùng trên máy chủ).
Sau một số lần thử nghiệm, tôi đã đạt được một thiết lập có vẻ hoạt động tốt và bắt đầu xem xét việc tăng cường bảo mật nhưng có điều gì đó vẫn khiến tôi lảng tránh.
Hầu hết ở mọi nơi, các ACL tiêu chuẩn để truy vấn cơ sở dữ liệu LDAP nhằm xác thực người dùng đang đăng nhập thuộc loại này:
olcAccess: {0}to attrs=userPassword tự viết bởi auth nặc danh * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}đến * theo * đọc
và mọi thứ hoạt động mà không có vấn đề gì.
Vì tôi không muốn để người dùng xem trộm hồ sơ của nhau, nên tôi đã sửa đổi hồ sơ cuối cùng thành:
olcAccess: {2}tới * bởi * none
Sau đó, tôi đã tìm thấy 'olcRequires: authc' sẽ vô hiệu hóa các liên kết ẩn danh với LDAP (có vẻ như là một cải tiến về bảo mật, phải không?) Và kích hoạt nó, và mọi thứ dường như vẫn tiếp tục hoạt động.
Sau đó, một lần nữa, nhìn vào ACL đầu tiên, bạn thấy rằng xác thực ẩn danh đối với mật khẩu người dùng vẫn được phép (điều này có vẻ dư thừa nếu quy tắc trước đó có hiệu lực) và tôi đã thử xóa nó:
olcAccess: {0}to attrs=userPassword by self =wx by * none
và không có gì hoạt động nữa.
Tiếp tục đọc, tôi thấy rằng SSSD phải có khả năng truy vấn cơ sở dữ liệu ở mức tối thiểu để truy xuất đủ cấu trúc để chuyển đổi tên người dùng như 'foo' thành Tên phân biệt LDAP là 'uid=foo,ou=People,dc =example,dc=com' mà LDAP sau đó có thể xử lý.
Tôi hiểu rằng SSSD có thể sử dụng 'người dùng ủy quyền' để làm việc đó, vì vậy tôi đã thêm một người dùng như vậy vào cơ sở dữ liệu của mình, định cấu hình SSSD để sử dụng nó:
ldap_default_bind_dn = cn=autobind,dc=example,dc=com
ldap_default_authtok = mật khẩu rất bí mật
và, tôi nghĩ, tôi đã thêm các ACL cần thiết để nó thực hiện công việc của mình:
olcAccess: {0}to attrs=userPassword by self =wx by dn="cn=autobind,dc=example,dc=com" =x by * none
olcAccess: {1}to attrs=shadowLastChange do tự viết bởi dn="cn=autobind,dc=example,dc=com" đọc bởi * none
olcAccess: {2}tới * bởi dn="cn=autobind,dc=example,dc=com" đọc bởi * none
Không cần phải nói, nó không hoạt động - không chỉ để đăng nhập, rất có thể SSSD bị định cấu hình sai, mà bản thân cơ sở dữ liệu cũng trở nên không thể kiểm tra được khi trả về lỗi 49 (Thông tin xác thực không hợp lệ) ngay cả khi thông qua ldapsearch.
thêm lại bởi ủy quyền ẩn danh làm cho nó hoạt động trở lại; rõ ràng, có một cái gì đó tôi không nhận được một cách chính xác.
Tôi hiểu rằng đó dường như không phải là vấn đề lớn, ngoài việc 'ẩn danh' xuất hiện trong ACL của tôi khiến tôi rất khó chịu nhưng dường như không thể truy cập bất kỳ thứ gì quan trọng.
Vì vậy, câu hỏi của tôi là: đây có phải là cấu hình an toàn hơn khi quyền truy cập 'ẩn danh' bị xóa hoàn toàn trong ACL cho cơ sở dữ liệu người dùng LDAP của tôi, cuối cùng thay thế các chức năng cần thiết của nó bằng các chức năng của người dùng proxy cụ thể đối với việc sử dụng SSSD không? Nếu không, bạn sẽ làm gì để tăng cường bảo mật hơn nữa?
