Ajalooliselt reguleeris sudo õigusi pärit failide sisu /etc/sudoers.d и visadoja võtme autoriseerimine viidi läbi kasutades ~/.ssh/authorized_keys. Taristu kasvades tekib aga soov neid õigusi tsentraalselt hallata. Tänapäeval võib olla mitu lahendusvarianti:
- Konfiguratsioonihaldussüsteem – peakokk, Nukuteater, Võimalik, Sool
- Active Directory + ssd
- Erinevad perverssused skriptide ja failide käsitsi redigeerimise näol
Minu subjektiivse hinnangu kohaselt on tsentraliseeritud haldamise parim variant ikkagi kombinatsioon Active Directory + ssd. Selle lähenemisviisi eelised on järgmised:
- Tõeliselt üks tsentraliseeritud kasutajakataloog.
- Õiguste jagamine sudo taandub kasutaja lisamisele konkreetsesse turvarühma.
- Erinevate Linuxi süsteemide puhul on konfiguratsioonisüsteemide kasutamisel vaja OS-i määramiseks teha täiendavaid kontrolle.
Tänane sviit on pühendatud spetsiaalselt ühendusele Active Directory + ssd õiguste haldamiseks sudo ja ladustamine ssh võtmed ühes hoidlas.
Nii tardus saal pingelises vaikuses, dirigent tõstis teatepulga ja orkester sai valmis.
Mine.
Arvestades:
— Active Directory domeen testopf.local opsüsteemis Windows Server 2012 R2.
- Linuxi host, kus töötab Centos 7
— Konfigureeritud autoriseerimine kasutades ssd
Mõlemad lahendused muudavad skeemi Active Directory, seega kontrollime kõike testkeskkonnas ja alles seejärel teeme muudatusi töötavas infrastruktuuris. Tahaksin märkida, et kõik muudatused on suunatud ja tegelikult lisavad ainult vajalikud atribuudid ja klassid.
Toiming 1: kontroll sudo rollid läbi Active Directory.
Ringkonna laiendamiseks Active Directory peate alla laadima uusima versiooni — 1.8.27 tänase seisuga. Pakkige fail lahti ja kopeerige schema.ActiveDirectory ./doc kataloogist domeenikontrollerisse. Käivitage administraatoriõigustega käsurealt kataloogist, kuhu fail kopeeriti:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Ärge unustage oma väärtusi asendada)
Avatud adsiedit.msc ja ühendage vaikekontekstiga:
Looge jaotus domeeni juurtes higistab. (Kodanlus väidab kangekaelselt, et deemon on selles üksuses ssd otsib eset sudoRole objektid. Kuid pärast üksikasjaliku silumise sisselülitamist ja logide uurimist selgus, et otsing viidi läbi kogu kataloogipuu ulatuses.)
Loome jaotuses esimese klassi kuuluva objekti sudoRole. Nime saab valida täiesti meelevaldselt, kuna see on mõeldud ainult mugavaks tuvastamiseks.
Skeemilaiendi võimalike saadaolevate atribuutide hulgas on peamised järgmised:
- sudoCommand — määrab, milliseid käske on hostis lubatud täita.
- sudoHost — määrab, millistele hostidele see roll rakendub. Võib täpsustada kui ALLja üksiku hosti jaoks nime järgi. Võimalik on kasutada ka maski.
- sudoUser — näidata, millistel kasutajatel on lubatud käivitada sudo.
Kui määrate turvarühma, lisage nime algusesse märk "%". Kui rühma nimes on tühikuid, pole põhjust muretsemiseks. Palkide järgi otsustades võtab ruumidest pääsemise ülesande üle mehhanism ssd.
Joonis 1. SudoRole objektid sudoersi alamjaotises kataloogi juurtes
Joonis 2. Liikmelisus sudoRole objektides määratud turbegruppides.
Järgmine häälestus tehakse Linuxi poolel.
Failis /etc/nsswitch.conf lisage rida faili lõppu:
sudoers: files sssFailis /etc/sssd/sssd.conf jaotises [sssd] lisada teenustele sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Pärast kõiki toiminguid peate tühjendama sssd deemoni vahemälu. Automaatsed värskendused toimuvad iga 6 tunni järel, kuid miks peaksime nii kaua ootama, kui tahame seda praegu?
sss_cache -ETihti juhtub, et vahemälu tühjendamine ei aita. Seejärel peatame teenuse, puhastame andmebaasi ja käivitame teenuse.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Ühendame esimese kasutajana ja kontrollime, mis on talle sudo all saadaval:
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/catTeeme sama oma teise kasutajaga:
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
See lähenemisviis võimaldab teil keskselt määratleda erinevate kasutajarühmade jaoks sudo rollid.
Ssh-võtmete salvestamine ja kasutamine Active Directory'is
Skeemi vähesel laiendamisel on võimalik salvestada ssh-võtmeid Active Directory kasutajaatribuutides ja kasutada neid Linuxi hostides autoriseerimisel.
Sssd kaudu autoriseerimine peab olema konfigureeritud.
Lisage nõutav atribuut PowerShelli skripti abil.
AddsshPublicKeyAttribute.ps1Funktsioon 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 = uus atribuudi ID
$atribuudid = @{
lDAPDisplayName = 'sshPublicKey';
atribuutId = $oid;
oMSüntaks = 22;
atribuutSüntaks = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Kasutaja avalik võti SSH sisselogimiseks';
}
Uus-ADO-objekt -Nimi sshPublicKey -Tüübi atribuutSchema -Tee $schemapath -Muud atribuudid $atribuudid
$userSchema = get-adobject -SearchBase $schemapath -Filter 'nimi -eq "kasutaja"'
$userSchema | Set-ADOBject -Add @{mayContain = 'sshPublicKey'}
Pärast atribuudi lisamist peate taaskäivitama Active Directory domeeniteenused.
Liigume edasi Active Directory kasutajate juurde. Loome ssh-ühenduse jaoks võtmepaari, kasutades mis tahes teile sobivat meetodit.
Käivitame PuttyGeni, vajutame nuppu „Generate” ja liigutame meeletult hiirt tühjal alal.
Protsessi lõppedes saame salvestada avaliku ja privaatvõtme, laadida avaliku võtme Active Directory kasutajaatribuuti ja nautida protsessi. Kuid avalikku võtit tuleb kasutada alates "Avalik võti OpenSSH-i authorised_keys faili kleepimiseks:"
Lisage võti kasutaja atribuudile.
1. valik – GUI:
Valik 2 – PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Seega on meil praegu: kasutaja, kelle atribuut sshPublicKey on täidetud, konfigureeritud Putty klient võtmete abil autoriseerimiseks. Jääb alles üks väike punkt: kuidas sundida sshd-deemonit kasutaja atribuutidest meile vajalikku avalikku võtit ekstraheerima. Kodanlikust Internetist leitud väike skript saab sellega edukalt hakkama.
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'Seadsime selle õigusteks juure jaoks 0500.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Selles näites kasutatakse kataloogiga sidumiseks administraatori kontot. Lahingutingimustes peab olema eraldi konto minimaalse õiguste kogumiga.
Mind isiklikult ajas vaatamata seatud õigustele väga segadusse parooli hetk puhtal kujul skriptis.
Lahendusevõimalus:
- Salvestan parooli eraldi faili:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Seadsin juurfailiõigusteks 0500
chmod 0500 /usr/local/etc/secretpass - Ldapsearch käivitamise parameetrite muutmine: parameeter -w superSecretPassword Muudan selle vastu -y /usr/local/etc/secretpass
Tänase komplekti viimane akord on faili sshd_config redigeerimine
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Selle tulemusel saame ssh-kliendis konfigureeritud võtme autoriseerimisega järgmise jada:
- Kasutaja loob ühenduse serveriga, näidates oma sisselogimist.
- Sshd-deemon eraldab skripti kaudu avaliku võtme väärtuse Active Directory kasutaja atribuudist ja teostab võtmete abil autoriseerimise.
- Sssd deemon autentib kasutajat veelgi grupi liikmesuse alusel. Tähelepanu! Kui see pole konfigureeritud, on igal domeeni kasutajal juurdepääs hostile.
- Kui proovite sudo-d teha, otsib sssd deemon Active Directoryst rolle. Kui rollid on olemas, kontrollitakse kasutaja atribuute ja rühma kuulumist (kui sudoRoles on konfigureeritud kasutajagruppe kasutama)
Kokkuvõte.
Seega salvestatakse võtmed Active Directory kasutajaatribuutides, sudo õigustes - samamoodi toimub juurdepääs Linuxi hostidele domeenikontode kaudu, kontrollides Active Directory rühma liikmesust.
Dirigendikepi lõpulaine – ja saal tardub aupaklikus vaikuses.
Kirjalikult kasutatud ressursid:
Allikas: www.habr.com