Về mặt lịch sử, quyền sudo bị chi phối bởi nội dung của các tệp từ /etc/sudoers.d и thị thựcvà việc ủy quyền khóa được thực hiện bằng cách sử dụng ~ / .ssh / allow_keys. Tuy nhiên, khi cơ sở hạ tầng phát triển, người ta mong muốn quản lý các quyền này một cách tập trung. Ngày nay có thể có một số lựa chọn giải pháp:
- Hệ thống quản lý cấu hình - Đầu bếp, Múa rối, Có khả năng, Salt
- active Directory + ssd
- Nhiều biến thái khác nhau dưới dạng tập lệnh và chỉnh sửa tệp thủ công
Theo ý kiến chủ quan của tôi, phương án tốt nhất để quản lý tập trung vẫn là kết hợp active Directory + ssd. Ưu điểm của phương pháp này là:
- Thực sự là một thư mục người dùng tập trung duy nhất.
- Phân phối quyền sudo bắt nguồn từ việc thêm người dùng vào một nhóm bảo mật cụ thể.
- Trong trường hợp các hệ thống Linux khác nhau, cần phải đưa ra các biện pháp kiểm tra bổ sung để xác định hệ điều hành khi sử dụng hệ thống cấu hình.
Bộ phần mềm hôm nay sẽ được dành riêng cho kết nối active Directory + ssd để quản lý quyền sudo và lưu trữ ssh các khóa trong một kho lưu trữ duy nhất.
Vì vậy, hội trường chìm trong sự im lặng căng thẳng, người chỉ huy giơ dùi cui lên và dàn nhạc đã sẵn sàng.
Đi.
Được:
- Tên miền Active Directory testopf.local trên Windows Server 2012 R2.
— Máy chủ Linux chạy Centos 7
- Cấu hình ủy quyền bằng cách sử dụng ssd
Cả hai giải pháp đều thực hiện thay đổi đối với lược đồ active Directory, vì vậy chúng tôi kiểm tra mọi thứ trong môi trường thử nghiệm và chỉ sau đó mới thực hiện các thay đổi đối với cơ sở hạ tầng đang hoạt động. Tôi muốn lưu ý rằng tất cả các thay đổi đều có mục tiêu và trên thực tế, chỉ thêm các thuộc tính và lớp cần thiết.
Hành động 1: kiểm soát sudo vai trò thông qua active Directory.
Để mở rộng mạch active Directory bạn cần tải xuống bản phát hành mới nhất - 1.8.27 kể từ hôm nay. Giải nén và sao chép tập tin lược đồ.ActiveDirectory từ thư mục ./doc tới bộ điều khiển miền. Từ dòng lệnh có quyền quản trị viên từ thư mục nơi tệp được sao chép, hãy chạy:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Đừng quên thay thế giá trị của bạn)
Chúng tôi mở quảng cáo.msc và kết nối với bối cảnh mặc định:
Tạo sự phân chia ở gốc của tên miền áo len. (Giai cấp tư sản ngoan cố cho rằng chính ở đơn vị này mà con quỷ ssd tìm kiếm một mục sudoRole các đối tượng. Tuy nhiên, sau khi bật tính năng gỡ lỗi chi tiết và nghiên cứu nhật ký, người ta phát hiện ra rằng việc tìm kiếm đã được thực hiện trên toàn bộ cây thư mục.)
Chúng ta tạo đối tượng đầu tiên thuộc lớp trong phép chia sudoRole. Tên có thể được chọn hoàn toàn tùy ý, vì nó chỉ phục vụ cho việc nhận dạng thuận tiện.
Trong số các thuộc tính có sẵn từ phần mở rộng lược đồ, những thuộc tính chính sau đây:
- sudoCommand — xác định những lệnh nào được phép thực thi trên máy chủ.
- sudohost — xác định máy chủ nào áp dụng vai trò này. Có thể được chỉ định là TẤT CẢ CÁCvà cho một máy chủ riêng lẻ theo tên. Cũng có thể sử dụng mặt nạ.
- người dùng sudo - cho biết người dùng nào được phép thực thi sudo.
Nếu bạn chỉ định một nhóm bảo mật, hãy thêm dấu “%” vào đầu tên. Nếu có khoảng trắng trong tên nhóm thì không có gì phải lo lắng. Đánh giá theo nhật ký, nhiệm vụ thoát khoảng trống được đảm nhận bởi cơ chế ssd.
Hình 1. Các đối tượng sudoRole trong phân khu sudoers trong thư mục gốc
Hình 2. Tư cách thành viên trong nhóm bảo mật được chỉ định trong đối tượng sudoRole.
Việc thiết lập sau đây được thực hiện ở phía Linux.
Trong tập tin /etc/nsswitch.conf thêm dòng vào cuối tập tin:
sudoers: files sssTrong tập tin /etc/sssd/sssd.conf trong phần [sssd] thêm vào dịch vụ sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Sau tất cả các thao tác, bạn cần xóa bộ đệm daemon sssd. Cập nhật tự động diễn ra cứ sau 6 giờ, nhưng tại sao chúng ta phải đợi lâu như vậy khi chúng ta muốn nó ngay bây giờ?
sss_cache -ENó thường xảy ra rằng việc xóa bộ nhớ cache không giúp ích gì. Sau đó, chúng tôi dừng dịch vụ, làm sạch cơ sở dữ liệu và khởi động dịch vụ.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Chúng tôi kết nối với tư cách là người dùng đầu tiên và kiểm tra những gì có sẵn cho anh ấy trong sudo:
su user1
[user1@testsshad log]$ id
uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_)
[user1@testsshad log]$ sudo -l
[sudo] password for user1:
Matching Defaults entries for user1 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user1 may run the following commands on testsshad:
(root) /usr/bin/ls, /usr/bin/catChúng tôi làm tương tự với người dùng thứ hai:
su user2
[user2@testsshad log]$ id
uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root)
[user2@testsshad log]$ sudo -l
Matching Defaults entries for user2 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user2 may run the following commands on testsshad:
(root) ALL
Cách tiếp cận này cho phép bạn xác định tập trung vai trò sudo cho các nhóm người dùng khác nhau.
Lưu trữ và sử dụng khóa ssh trong Active Directory
Với việc mở rộng sơ đồ một chút, có thể lưu trữ các khóa ssh trong thuộc tính người dùng Active Directory và sử dụng chúng khi cấp quyền trên máy chủ Linux.
Việc ủy quyền qua sssd phải được cấu hình.
Thêm thuộc tính bắt buộc bằng tập lệnh PowerShell.
AddsshPublicKeyAttribution.ps1Chức năng ID thuộc tính mới {
$Tiền tố="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Bộ phận=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(4,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(9,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(14,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(19,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(24,6),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(30,6),“AllowHexSpecifier”)
$oid=[String]::Format(«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = ID thuộc tính mới
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
thuộc tínhId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Khóa công khai của người dùng để đăng nhập SSH';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttribut $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Thêm @{mayContain = 'sshPublicKey'}
Sau khi thêm thuộc tính, bạn phải khởi động lại Dịch vụ miền Active Directory.
Hãy chuyển sang người dùng Active Directory. Chúng tôi sẽ tạo một cặp khóa cho kết nối ssh bằng bất kỳ phương pháp nào thuận tiện cho bạn.
Chúng tôi khởi chạy PuttyGen, nhấn nút “Tạo” và di chuyển chuột một cách điên cuồng trong vùng trống.
Sau khi hoàn tất quá trình, chúng ta có thể lưu khóa chung và khóa riêng, tải khóa chung lên thuộc tính người dùng Active Directory và tận hưởng quy trình. Tuy nhiên, khóa chung phải được sử dụng từ "Khóa chung để dán vào tệp OpenSSH ủy quyền:".
Thêm khóa vào thuộc tính người dùng.
Tùy chọn 1 - GUI:
Tùy chọn 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Vì vậy, chúng tôi hiện có: một người dùng có thuộc tính sshPublicKey được điền, một ứng dụng khách PuTTY được định cấu hình để ủy quyền bằng các khóa. Vẫn còn một điểm nhỏ: làm thế nào để buộc daemon sshd trích xuất khóa chung mà chúng ta cần từ thuộc tính của người dùng. Một tập lệnh nhỏ được tìm thấy trên Internet tư sản có thể đối phó thành công với điều này.
cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'Chúng tôi đặt quyền trên nó thành 0500 cho root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Trong ví dụ này, tài khoản quản trị viên được sử dụng để liên kết với thư mục. Trong điều kiện chiến đấu, phải có một tài khoản riêng với các quyền tối thiểu.
Cá nhân tôi rất bối rối trước thời điểm mật khẩu ở dạng thuần túy trong kịch bản, mặc dù đã đặt quyền.
Tùy chọn giải pháp:
- Tôi lưu mật khẩu vào một tệp riêng:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Tôi đặt quyền truy cập tệp thành 0500 cho root
chmod 0500 /usr/local/etc/secretpass - Thay đổi tham số khởi chạy ldapsearch: tham số -w superSecretPassword Tôi đổi nó thành -y /usr/local/etc/secretpass
Hợp âm cuối cùng trong phần hôm nay là chỉnh sửa sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Kết quả là chúng ta nhận được trình tự sau với ủy quyền khóa được định cấu hình trong ứng dụng khách ssh:
- Người dùng kết nối với máy chủ bằng cách chỉ ra thông tin đăng nhập của mình.
- Daemon sshd, thông qua một tập lệnh, trích xuất giá trị khóa chung từ thuộc tính người dùng trong Active Directory và thực hiện ủy quyền bằng các khóa.
- Daemon sssd xác thực thêm người dùng dựa trên tư cách thành viên nhóm. Chú ý! Nếu điều này không được định cấu hình thì bất kỳ người dùng miền nào cũng sẽ có quyền truy cập vào máy chủ.
- Khi bạn cố gắng sudo, daemon sssd sẽ tìm kiếm các vai trò trong Active Directory. Nếu có vai trò, thuộc tính của người dùng và thành viên nhóm sẽ được kiểm tra (nếu sudoRoles được định cấu hình để sử dụng nhóm người dùng)
Tóm tắt.
Do đó, các khóa được lưu trữ trong thuộc tính người dùng Active Directory, quyền sudo - tương tự, việc truy cập vào máy chủ Linux bằng tài khoản miền được thực hiện bằng cách kiểm tra tư cách thành viên trong nhóm Active Directory.
Làn sóng dùi cui cuối cùng của người soát vé - và hội trường đóng băng trong sự im lặng tôn kính.
Nguồn tài liệu được sử dụng trong văn bản:
Nguồn: www.habr.com