Quyền Sudo bởi các nhóm ldap thông qua nslcd


7

Tôi gặp vấn đề với quyền sudo của mình trong thiết lập ủy quyền / xác thực LDAP của Debian ActiveDirectory.

Những gì tôi có cho đến nay
tôi đã cấu hình nslcd với libpam-ldap thông qua ldaps và đăng nhập ssh đang hoạt động rất tốt.

getent passwd myuser
myuser:*:10001:10015:myuser:/home/myuser:/bin/bash

Trên Máy chủ ActiveDirectory của tôi, Gói Unix được cài đặt để thêm các thuộc tính cần thiết như posixgroup, posixAccount, gid, gidNumber, uid, uidNumber, v.v.

Người dùng ví dụ của tôi trông như thế này:
(Tôi chọn 10000+ để ở bên an toàn)

cn: myuser
uid: myuser
uidNumber: 10015
gidNumber: 10000

Tôi có thể hạn chế đăng nhập SSH bằng cách thêm thông tin sau vào /etc/nslcd.conf

filter passwd (&(objectClass=posixAccount)(|(memberOf=CN=group1,OU=groups,DC=domain,DC=com)(memberOf=CN=group2,OU=groups,DC=domain,DC=com)))

Điều này xác định rằng chỉ những người dùng có objecClass = posixAccount và nhóm hoặc nhóm1 hoặc nhóm2 mới có thể đăng nhập.

Càng xa càng tốt. Tuy nhiên, tôi không thể bảo sudo sử dụng các nhóm đó.

Đây là những gì tôi đã thử
trong / etc / sudoers

// This one works, but only because the user has gidNumber=10000 set. 
// It doesn't matter if a group with this ID actually exist or not. 
// So it's not really permission by LDAP group.
%#10000 ALL=(root) ALL


// This is what I want, but it doesn't work.
%group1 ALL=(root) ALL

Vấn đề
Bằng cách nào đó tôi cần nói với sudo để lấy tên người dùng yêu cầu, kiểm tra xem nhóm ldap đó thuộc về nhóm nào và sau đó xem liệu các quyền cho nhóm đó có đủ để thực hiện lệnh hay không.

Đáng tiếc tôi không biết bắt đầu từ đâu. Mọi thứ khác hoạt động cho đến nay và tôi chỉ bị mắc kẹt với quyền sudo. Tôi đã nghĩ về việc ánh xạ trường gidNumber của người dùng sang trường gidNumber của nhóm nhưng tôi không biết nếu ánh xạ trường người dùng vào trường nhóm thậm chí có thể.

Tôi không nghĩ vậy, vì ánh xạ trong nslcd được chỉ định như thế này

map passwd field1 field2

và passwd nói với nslcd rằng nó phải ánh xạ các trường người dùng. Thay vì passwd tôi có thể sử dụng các nhóm, nhưng không phải cả hai.

Câu trả lời:


7

Xin lỗi về bài viết dài, nhưng nó dường như làm việc. Tôi chỉ có một lỗi đánh máy trong tập tin sudoers. Mất một lúc lâu để tìm thấy nó, vì cú pháp vẫn đúng nhưng tôi không thể thực hiện bất kỳ lệnh nào.

Tuy nhiên, nó đang hoạt động.

 // Problem was that one ALL was missing, allowing me to execute no root cmds.
 %group1 ALL=(root) !/bin/su

 // Fixed it
 %group1 ALL=(root) ALL, !/bin/su

Cập nhật: Tôi nhận ra hơi muộn nhưng tôi cũng đã thay đổi như sau trong /etc/nsswitch.conf

sudoers:        ldap files

Tôi chỉ không nghĩ rằng đó là bản sửa lỗi vì tôi vẫn còn mắc lỗi đánh máy sudoers đã đề cập ở trên.

Vấn đề đã được giải quyết :)


Ngẫu nhiên, tại sao bạn phủ nhận / bin / su? Nếu bạn muốn ngăn người dùng lấy shell gốc, thì! / Bin / su của bạn là không đủ. sudo bash hoặc cp / bin / su / tmp / su && sudo / tmp / su chỉ là hai trong số nhiều cách để vẫn có được một vỏ gốc trên hầu hết các hệ thống. (bỏ qua các chính sách grsec, systrace, v.v.)
etherfish

Cảm ơn vì tiền boa, cũng vậy! / Usr / sbin / visudo bị thiếu. về cơ bản nó chỉ là một thử nghiệm để xem nếu một lệnh thực sự bị chặn.
mohrphium

@etherfish chính xác của bạn về điều đó nhưng một người thực sự nên gắn tmp, var, / dev / shm, / home và tương tự như noexec, do đó chỉ để lại / {, usr, usr / local} / [s] bin là những điểm duy nhất được gắn với perm perm.
Dwight Spencer

1

Tôi đã đi với việc gán các nhóm cục bộ cho người dùng thông qua pam_group để có được chức năng tương tự. Trong /etc/security/groups.conftôi đã thêm dòng sau

*;*;%administrators;Al0000-2400;adm,sudo,lpadmin

Vì vậy, bất kỳ người dùng LDAP thuộc nhóm LDAP administratorsđược ánh xạ tới các địa phương adm, sudolpadmincác nhóm trên hộp. Có vẻ đơn giản hơn là phải cài đặt sudo-ldap, trừ khi tôi thiếu một cái gì đó?


Tôi thích ý tưởng này, nhưng nó không hiệu quả với tôi, bạn có thể cải thiện câu trả lời của mình không? Câu trả lời đầy đủ sẽ liên kết đến một trang khác
FreeSoftwareServers
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.