Dari segi sejarah, kebenaran sudo dikawal oleh kandungan fail daripada /etc/sudoers.d и visudo, dan kebenaran utama telah dijalankan menggunakan ~/.ssh/authorized_keys. Walau bagaimanapun, apabila infrastruktur berkembang, terdapat keinginan untuk mengurus hak ini secara berpusat. Hari ini mungkin terdapat beberapa pilihan penyelesaian:
- Sistem Pengurusan Konfigurasi - Chef, Boneka, Ansible, Garam
- Active Directory + ssd
- Pelbagai penyelewengan dalam bentuk skrip dan penyuntingan fail manual
Pada pendapat subjektif saya, pilihan terbaik untuk pengurusan berpusat masih merupakan gabungan Active Directory + ssd. Kelebihan pendekatan ini ialah:
- Benar-benar satu direktori pengguna terpusat.
- Pengagihan hak sudo turun untuk menambahkan pengguna pada kumpulan keselamatan tertentu.
- Dalam kes pelbagai sistem Linux, adalah perlu untuk memperkenalkan pemeriksaan tambahan untuk menentukan OS apabila menggunakan sistem konfigurasi.
Suite hari ini akan didedikasikan khusus untuk sambungan Active Directory + ssd untuk pengurusan hak sudo dan penyimpanan ssh kunci dalam satu repositori.
Jadi, dewan itu membeku dalam kesunyian yang tegang, konduktor mengangkat batonnya, dan orkestra bersiap sedia.
Pergi.
Diberi:
— Domain Direktori Aktif testtopf.local pada Windows Server 2012 R2.
— Hos Linux menjalankan Centos 7
— Konfigurasikan kebenaran menggunakan ssd
Kedua-dua penyelesaian membuat perubahan pada skema Active Directory, jadi kami menyemak segala-galanya dalam persekitaran ujian dan hanya kemudian membuat perubahan pada infrastruktur yang berfungsi. Saya ingin ambil perhatian bahawa semua perubahan disasarkan dan, sebenarnya, hanya menambah atribut dan kelas yang diperlukan.
Tindakan 1: kawalan sudo peranan melalui Active Directory.
Untuk mengembangkan litar Active Directory anda perlu memuat turun keluaran terkini — 1.8.27 setakat hari ini. Buka bungkusan dan salin fail skema.ActiveDirectory daripada direktori ./doc kepada pengawal domain. Dari baris arahan dengan hak pentadbir dari direktori tempat fail disalin, jalankan:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Jangan lupa untuk menggantikan nilai anda)
Buka adsiedit.msc dan sambung ke konteks lalai:
Buat pembahagian pada akar domain sudoers. (Kaum borjuasi berdegil mendakwa bahawa dalam unit inilah syaitan ssd mencari sesuatu barang sudoRole objek. Walau bagaimanapun, selepas menghidupkan penyahpepijatan terperinci dan mengkaji log, didapati bahawa carian telah dilakukan di seluruh pepohon direktori.)
Kami mencipta objek pertama kepunyaan kelas dalam bahagian sudoRole. Nama itu boleh dipilih dengan sewenang-wenangnya, kerana ia berfungsi semata-mata untuk pengenalan yang mudah.
Antara atribut yang mungkin tersedia daripada sambungan skema, yang utama adalah yang berikut:
- sudoCommand — menentukan arahan yang dibenarkan untuk dilaksanakan pada hos.
- sudoHost — menentukan hos yang mana peranan ini digunakan. Boleh dinyatakan sebagai SEMUA, dan untuk hos individu mengikut nama. Ia juga boleh menggunakan topeng.
- sudoUser — menunjukkan pengguna yang dibenarkan untuk melaksanakan sudo.
Jika anda menentukan kumpulan keselamatan, tambahkan tanda "%" pada permulaan nama. Jika terdapat ruang dalam nama kumpulan, tiada apa yang perlu dibimbangkan. Berdasarkan log, tugas melarikan diri dari ruang diambil alih oleh mekanisme ssd.
Rajah 1. objek sudoRole dalam subbahagian sudoers dalam akar direktori
Rajah 2. Keahlian dalam kumpulan keselamatan yang dinyatakan dalam objek sudoRole.
Persediaan berikut dilakukan pada bahagian Linux.
Dalam fail /etc/nsswitch.conf tambah baris ke hujung fail:
sudoers: files sssDalam fail /etc/sssd/sssd.conf dalam bahagian [sssd] menambah perkhidmatan sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Selepas semua operasi, anda perlu mengosongkan cache daemon sssd. Kemas kini automatik berlaku setiap 6 jam, tetapi mengapa kita perlu menunggu lama apabila kita mahukannya sekarang?
sss_cache -ESelalunya berlaku bahawa membersihkan cache tidak membantu. Kemudian kami menghentikan perkhidmatan, membersihkan pangkalan data, dan memulakan perkhidmatan.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Kami menyambung sebagai pengguna pertama dan menyemak apa yang tersedia untuknya di bawah 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/catKami melakukan perkara yang sama dengan pengguna kedua kami:
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
Pendekatan ini membolehkan anda menentukan secara berpusat peranan sudo untuk kumpulan pengguna yang berbeza.
Menyimpan dan menggunakan kekunci ssh dalam Active Directory
Dengan pengembangan sedikit skema, adalah mungkin untuk menyimpan kunci ssh dalam atribut pengguna Active Directory dan menggunakannya apabila memberi kebenaran pada hos Linux.
Keizinan melalui sssd mesti dikonfigurasikan.
Tambahkan atribut yang diperlukan menggunakan skrip PowerShell.
AddsshPublicKeyAttribute.ps1Fungsi New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$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 = New-AttributeID
$atribut = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Kunci Awam Pengguna untuk log masuk SSH';
}
New-ADObject -Nama sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Tapis 'nama -eq "pengguna"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Selepas menambah atribut, anda mesti memulakan semula Perkhidmatan Domain Direktori Aktif.
Mari beralih kepada pengguna Active Directory. Kami akan menjana pasangan kunci untuk sambungan ssh menggunakan sebarang kaedah yang sesuai untuk anda.
Kami melancarkan PuttyGen, tekan butang "Jana" dan gerakkan tetikus dengan panik di dalam kawasan kosong.
Setelah proses selesai, kami boleh menyimpan kunci awam dan peribadi, memuat naik kunci awam ke atribut pengguna Active Directory dan menikmati proses tersebut. Walau bagaimanapun, kunci awam mesti digunakan daripada "Kunci awam untuk menampal ke dalam fail OpenSSH authorized_keys:".
Tambahkan kunci pada atribut pengguna.
Pilihan 1 - GUI:
Pilihan 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Jadi, pada masa ini kami mempunyai: pengguna dengan atribut sshPublicKey diisi, pelanggan Putty yang dikonfigurasikan untuk kebenaran menggunakan kekunci. Terdapat satu perkara kecil: bagaimana untuk memaksa daemon sshd untuk mengekstrak kunci awam yang kami perlukan daripada atribut pengguna. Skrip kecil yang terdapat di Internet borjuasi boleh berjaya mengatasinya.
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'Kami menetapkan kebenaran padanya kepada 0500 untuk root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Dalam contoh ini, akaun pentadbir digunakan untuk mengikat direktori. Dalam keadaan pertempuran mesti ada akaun berasingan dengan set hak minimum.
Saya secara peribadi sangat keliru dengan saat kata laluan dalam bentuk tulen dalam skrip, walaupun hak ditetapkan.
Pilihan penyelesaian:
- Saya menyimpan kata laluan dalam fail berasingan:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Saya menetapkan kebenaran fail kepada 0500 untuk root
chmod 0500 /usr/local/etc/secretpass - Menukar parameter pelancaran ldapsearch: parameter -w superSecretPassword Saya tukar kepada -y /usr/local/etc/secretpass
Kord terakhir dalam suite hari ini ialah mengedit sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Akibatnya, kami mendapat urutan berikut dengan kebenaran utama yang dikonfigurasikan dalam klien ssh:
- Pengguna menyambung ke pelayan dengan menunjukkan log masuknya.
- Daemon sshd, melalui skrip, mengekstrak nilai kunci awam daripada atribut pengguna dalam Active Directory dan melaksanakan kebenaran menggunakan kekunci.
- Daemon sssd seterusnya mengesahkan pengguna berdasarkan keahlian kumpulan. Perhatian! Jika ini tidak dikonfigurasikan, maka mana-mana pengguna domain akan mempunyai akses kepada hos.
- Apabila anda cuba sudo, daemon sssd mencari peranan di Direktori Aktif. Jika peranan hadir, atribut pengguna dan keahlian kumpulan disemak (jika sudoRoles dikonfigurasikan untuk menggunakan kumpulan pengguna)
Ringkasan.
Oleh itu, kunci disimpan dalam atribut pengguna Active Directory, kebenaran sudo - begitu juga, akses kepada hos Linux oleh akaun domain dijalankan dengan menyemak keahlian dalam kumpulan Active Directory.
Gelombang terakhir baton konduktor - dan dewan membeku dalam kesunyian hormat.
Sumber yang digunakan secara bertulis:
Sumber: www.habr.com