Secara historis, izin sudo diatur oleh konten file dari /etc/sudoers.d и visudo, dan otorisasi kunci dilakukan menggunakan ~/.ssh/authorized_keys. Namun, seiring dengan pertumbuhan infrastruktur, muncul keinginan untuk mengelola hak-hak tersebut secara terpusat. Saat ini mungkin ada beberapa opsi solusi:
- Sistem Manajemen Konfigurasi - Koki, Wayang, Mungkin, Garam
- Active Directory + ssd
- Berbagai penyimpangan berupa skrip dan pengeditan file manual
Menurut pendapat subjektif saya, pilihan terbaik untuk manajemen terpusat masih berupa kombinasi Active Directory + ssd. Keuntungan dari pendekatan ini adalah:
- Benar-benar satu direktori pengguna terpusat.
- Distribusi hak sudo turun untuk menambahkan pengguna ke grup keamanan tertentu.
- Dalam kasus berbagai sistem Linux, pemeriksaan tambahan perlu dilakukan untuk menentukan OS saat menggunakan sistem konfigurasi.
Suite hari ini akan didedikasikan khusus untuk koneksi Active Directory + ssd untuk manajemen hak sudo dan penyimpanan ssh kunci dalam satu repositori.
Jadi, aula membeku dalam keheningan yang mencekam, kondektur mengangkat tongkatnya, dan orkestra bersiap-siap.
Ayo pergi.
Diberikan:
— Domain Direktori Aktif testopf.local pada Windows Server 2012 R2.
— Host Linux yang menjalankan Centos 7
— Otorisasi yang dikonfigurasi menggunakan ssd
Kedua solusi tersebut membuat perubahan pada skema Active Directory, jadi kami memeriksa semuanya di lingkungan pengujian dan baru kemudian membuat perubahan pada infrastruktur yang berfungsi. Saya ingin mencatat bahwa semua perubahan ditargetkan dan, pada kenyataannya, hanya menambahkan atribut dan kelas yang diperlukan.
Tindakan 1: kontrol sudo peran melalui Active Directory.
Untuk memperluas sirkuit Active Directory Anda perlu mengunduh rilis terbaru — 1.8.27 pada hari ini. Buka paket dan salin file skema.ActiveDirectory dari direktori ./doc ke pengontrol domain. Dari baris perintah dengan hak administrator dari direktori tempat file disalin, jalankan:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Jangan lupa untuk mengganti nilai-nilai Anda)
Buka adsiedit.msc dan terhubung ke konteks default:
Buat divisi di root domain sudoers. (Kaum borjuasi dengan keras kepala mengklaim bahwa di unit inilah setan berada ssd mencari suatu barang sudoRole objek. Namun, setelah mengaktifkan debug mendetail dan mempelajari log, terungkap bahwa pencarian dilakukan di seluruh pohon direktori.)
Kami membuat objek pertama milik kelas di divisi tersebut sudoRole. Nama tersebut dapat dipilih secara sewenang-wenang, karena hanya berfungsi untuk memudahkan identifikasi.
Di antara kemungkinan atribut yang tersedia dari ekstensi skema, atribut utama adalah sebagai berikut:
- sudoCommand — menentukan perintah mana yang boleh dijalankan pada host.
- sudoHost — menentukan host mana yang akan menerapkan peran ini. Dapat ditentukan sebagai SEMUA, dan untuk host individual berdasarkan nama. Bisa juga menggunakan masker.
- sudoUser — menunjukkan pengguna mana yang diizinkan untuk mengeksekusi sudo.
Jika Anda menentukan grup keamanan, tambahkan tanda “%” di awal namanya. Jika terdapat spasi pada nama grup, tidak ada yang perlu dikhawatirkan. Dilihat dari lognya, tugas untuk keluar dari ruang diambil alih oleh mekanisme ssd.
Gambar 1. objek sudoRole di subdivisi sudoers di root direktori
Gambar 2. Keanggotaan dalam grup keamanan yang ditentukan dalam objek sudoRole.
Pengaturan berikut dilakukan di sisi Linux.
Dalam file /etc/nsswitch.conf tambahkan baris ke akhir file:
sudoers: files sssDalam file /etc/sssd/sssd.conf di bagian [sssd] tambahkan ke layanan sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Setelah semua operasi, Anda perlu menghapus cache daemon sssd. Pembaruan otomatis terjadi setiap 6 jam, tetapi mengapa kita harus menunggu begitu lama padahal kita menginginkannya sekarang?
sss_cache -ESering kali membersihkan cache tidak membantu. Kemudian kami menghentikan layanan, membersihkan database, dan memulai layanan.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Kami terhubung sebagai pengguna pertama dan memeriksa apa yang tersedia baginya 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 hal 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 memungkinkan Anda menentukan peran sudo secara terpusat untuk kelompok pengguna yang berbeda.
Menyimpan dan menggunakan kunci ssh di Direktori Aktif
Dengan sedikit perluasan skema, dimungkinkan untuk menyimpan kunci ssh di atribut pengguna Direktori Aktif dan menggunakannya saat mengotorisasi pada host Linux.
Otorisasi melalui SSD harus dikonfigurasi.
Tambahkan atribut yang diperlukan menggunakan skrip PowerShell.
TambahkanshPublicKeyAttribute.ps1Fungsi ID Atribut Baru {
$Awalan="1.2.840.113556.1.8000.2554"
$GUID=[Sistem.Guid]::NewGuid().ToString()
$Bagian=@()
$Bagian+=[UInt64]::Parse($guid.SubString(0,4),“AllowHexSpecifier”)
$Bagian+=[UInt64]::Parse($guid.SubString(4,4),“AllowHexSpecifier”)
$Bagian+=[UInt64]::Parse($guid.SubString(9,4),“AllowHexSpecifier”)
$Bagian+=[UInt64]::Parse($guid.SubString(14,4),“AllowHexSpecifier”)
$Bagian+=[UInt64]::Parse($guid.SubString(19,4),“AllowHexSpecifier”)
$Bagian+=[UInt64]::Parse($guid.SubString(24,6),“AllowHexSpecifier”)
$Bagian+=[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 = (Dapatkan-ADRootDSE).schemaNamingContext
$oid = ID Atribut Baru
$atribut = @{
lDAPDisplayName = 'sshPublicKey';
atributId = $oid;
oMSintaks = 22;
atributSintaks = "2.5.5.5";
isSingleValued = $benar;
adminDescription = 'Kunci Publik Pengguna untuk login SSH';
}
Baru-ADObject -Nama sshPublicKey -Jenis atributSchema -Jalur $schemapath -OtherAttributes $attributes
$userSchema = dapatkan-adobject -SearchBase $schemapath -Filter 'nama -eq "pengguna"'
$skema pengguna | Set-ADObject -Tambahkan @{mayContain = 'sshPublicKey'}
Setelah menambahkan atribut, Anda harus memulai ulang Layanan Domain Direktori Aktif.
Mari beralih ke pengguna Direktori Aktif. Kami akan membuat pasangan kunci untuk koneksi ssh menggunakan metode apa pun yang nyaman bagi Anda.
Kami meluncurkan PuttyGen, tekan tombol "Hasilkan" dan gerakkan mouse dengan panik ke dalam area kosong.
Setelah proses selesai, kita dapat menyimpan kunci publik dan pribadi, mengunggah kunci publik ke atribut pengguna Direktori Aktif dan menikmati prosesnya. Namun, kunci publik harus digunakan dari "Kunci publik untuk ditempelkan ke file Otorisasi OpenSSH:".
Tambahkan kunci ke atribut pengguna.
Opsi 1 - GUI:
Opsi 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Jadi, saat ini kami memiliki: pengguna dengan atribut sshPublicKey terisi, klien Putty yang dikonfigurasi untuk otorisasi menggunakan kunci. Masih ada satu hal kecil: bagaimana memaksa daemon sshd mengekstrak kunci publik yang kita perlukan dari atribut pengguna. Sebuah skrip kecil yang ditemukan di Internet borjuis dapat berhasil mengatasi hal ini.
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 izinnya ke 0500 untuk root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Dalam contoh ini, akun administrator digunakan untuk mengikat ke direktori. Dalam kondisi pertempuran harus ada akun terpisah dengan hak minimum.
Saya pribadi sangat bingung dengan momen kata sandi dalam bentuknya yang murni di skrip, meskipun haknya telah ditetapkan.
Opsi solusi:
- Saya menyimpan kata sandi dalam file terpisah:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Saya mengatur izin file ke 0500 untuk root
chmod 0500 /usr/local/etc/secretpass - Mengubah parameter peluncuran ldapsearch: parameter -w Kata Sandi SuperRahasia Saya mengubahnya menjadi -y /usr/local/etc/secretpass
Akord terakhir dalam rangkaian hari ini adalah mengedit sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Hasilnya, kami mendapatkan urutan berikut dengan otorisasi kunci yang dikonfigurasi di klien ssh:
- Pengguna terhubung ke server dengan menunjukkan loginnya.
- Daemon sshd, melalui skrip, mengekstrak nilai kunci publik dari atribut pengguna di Direktori Aktif dan melakukan otorisasi menggunakan kunci tersebut.
- Daemon SSD selanjutnya mengautentikasi pengguna berdasarkan keanggotaan grup. Perhatian! Jika ini tidak dikonfigurasi, maka setiap pengguna domain akan memiliki akses ke host.
- Saat Anda mencoba sudo, daemon sssd mencari peran di Direktori Aktif. Jika ada peran, atribut pengguna dan keanggotaan grup akan diperiksa (jika sudoRoles dikonfigurasi untuk menggunakan grup pengguna)
Ringkasan.
Dengan demikian, kunci disimpan dalam atribut pengguna Direktori Aktif, izin sudo - demikian pula, akses ke host Linux dengan akun domain dilakukan dengan memeriksa keanggotaan dalam grup Direktori Aktif.
Gelombang terakhir tongkat konduktor - dan aula membeku dalam keheningan.
Sumber daya yang digunakan secara tertulis:
Sumber: www.habr.com