Historikisht, lejet sudo drejtoheshin nga përmbajtja e skedarëve nga /etc/sudoers.d и vizë, dhe autorizimi kyç është kryer duke përdorur ~/.ssh/authorized_keys. Megjithatë, ndërsa infrastruktura rritet, ekziston një dëshirë për të menaxhuar këto të drejta në mënyrë qendrore. Sot mund të ketë disa opsione zgjidhjeje:
- Sistemi i menaxhimit të konfigurimit - Shef, kukull, Ansible, Kripë
- Active Directory + ssd
- Perversione të ndryshme në formën e skripteve dhe redaktimit manual të skedarëve
Sipas mendimit tim subjektiv, opsioni më i mirë për menaxhimin e centralizuar është ende një kombinim Active Directory + ssd. Përparësitë e kësaj qasjeje janë:
- Vërtet një direktori e vetme e centralizuar e përdoruesit.
- Shpërndarja e të drejtave sudo zbret në shtimin e një përdoruesi në një grup të caktuar sigurie.
- Në rastin e sistemeve të ndryshme Linux, bëhet e nevojshme të futen kontrolle shtesë për të përcaktuar sistemin operativ kur përdoren sistemet e konfigurimit.
Suita e sotme do t'i kushtohet posaçërisht lidhjes Active Directory + ssd për menaxhimin e të drejtave sudo dhe magazinimit ssh çelësat në një depo të vetme.
Kështu, salla ngriu në heshtje të tensionuar, dirigjenti ngriti stafetën e tij dhe orkestra u bë gati.
Shko
duke pasur parasysh:
— Domeni Active Directory testopf.lokal në Windows Server 2012 R2.
- Pritësi Linux që ekzekuton Centos 7
— Autorizimi i konfiguruar duke përdorur ssd
Të dyja zgjidhjet bëjnë ndryshime në skemë Active Directory, kështu që ne kontrollojmë gjithçka në një mjedis testimi dhe vetëm atëherë bëjmë ndryshime në infrastrukturën e punës. Dua të vërej se të gjitha ndryshimet janë të synuara dhe, në fakt, shtojnë vetëm atributet dhe klasat e nevojshme.
Veprimi 1: kontrolli sudo rolet përmes Active Directory.
Për të zgjeruar qarkun Active Directory ju duhet të shkarkoni versionin më të fundit — 1.8.27 nga sot. Shpaketoni dhe kopjoni skedarin skema.ActiveDirectory nga direktoria ./doc te kontrolluesi i domenit. Nga linja e komandës me të drejtat e administratorit nga drejtoria ku është kopjuar skedari, ekzekutoni:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Mos harroni të zëvendësoni vlerat tuaja)
Hapni adsiedit.msc dhe lidheni me kontekstin e paracaktuar:
Krijoni një ndarje në rrënjë të domenit xhupat. (Borgjezia pretendon me kokëfortësi se është në këtë njësi që demoni ssd kërkon për një artikull sudoRoli objektet. Megjithatë, pas aktivizimit të korrigjimit të detajuar dhe studimit të regjistrave, u zbulua se kërkimi u krye në të gjithë pemën e drejtorisë.)
Ne krijojmë objektin e parë që i përket klasës në ndarje sudoRoli. Emri mund të zgjidhet absolutisht në mënyrë arbitrare, pasi shërben vetëm për identifikim të përshtatshëm.
Ndër atributet e mundshme të disponueshme nga shtrirja e skemës, ato kryesore janë si më poshtë:
- sudoCommand — përcakton se cilat komanda lejohen të ekzekutohen në host.
- sudoHost — përcakton se për cilët host zbatohet ky rol. Mund të specifikohet si ALL, dhe për një host individual me emër. Është gjithashtu e mundur të përdoret një maskë.
- sudoPërdorues — tregoni se cilët përdorues lejohen të ekzekutojnë sudo.
Nëse specifikoni një grup sigurie, shtoni një shenjë "%" në fillim të emrit. Nëse ka hapësira në emrin e grupit, nuk ka asgjë për t'u shqetësuar. Duke gjykuar nga trungjet, detyrën e ikjes së hapësirave e merr përsipër mekanizmi ssd.
Fig 1. objektet sudoRole në nënndarjen sudoers në rrënjën e drejtorisë
Figura 2. Anëtarësimi në grupet e sigurisë të specifikuara në objektet sudoRole.
Konfigurimi i mëposhtëm bëhet në anën e Linux.
Në dosje /etj/nsswitch.conf shtoni rreshtin në fund të skedarit:
sudoers: files sssNë dosje /etc/sssd/sssd.conf në seksion [sssd] shtoni në shërbime sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Pas të gjitha operacioneve, duhet të pastroni cache-in e demonit sssd. Përditësimet automatike ndodhin çdo 6 orë, por pse duhet të presim kaq gjatë kur e duam tani?
sss_cache -EShpesh ndodh që pastrimi i cache nuk ndihmon. Më pas ndalojmë shërbimin, pastrojmë bazën e të dhënave dhe nisim shërbimin.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Ne lidhemi si përdoruesi i parë dhe kontrollojmë se çfarë është e disponueshme për të nën 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/catNe bëjmë të njëjtën gjë me përdoruesin tonë të dytë:
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
Kjo qasje ju lejon të përcaktoni në mënyrë qendrore rolet sudo për grupe të ndryshme përdoruesish.
Ruajtja dhe përdorimi i çelësave ssh në Active Directory
Me një zgjerim të lehtë të skemës, është e mundur të ruhen çelësat ssh në atributet e përdoruesve të Active Directory dhe t'i përdorin ato kur autorizohen në hostet Linux.
Autorizimi nëpërmjet sssd duhet të konfigurohet.
Shtoni atributin e kërkuar duke përdorur një skript PowerShell.
AddsshPublicKeyAttribute.ps1Funksioni New-AtributeID {
$Prefiks="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Pjese=@()
$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-AtributeID
$atribute = @{
lDAPDisplayName = 'sshPublicKey';
atributiId = $oid;
oMSyntaksa = 22;
atributSyntaksa = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Çelësi publik i përdoruesit për hyrje në SSH';
}
New-ADObject -Name sshPublicKey -Type atributSchema -Rruga $schemapath -OtherAttributes $atribute
$userSchema = get-adobject -SearchBase $schemapath -Filtri 'emri -eq "user"'
$userSchema | Set-ADObject -Shto @{mayContain = 'sshPublicKey'}
Pas shtimit të atributit, duhet të rinisni Shërbimet e Domainit të Active Directory.
Le të kalojmë te përdoruesit e Active Directory. Ne do të gjenerojmë një çift çelësash për lidhjen ssh duke përdorur çdo metodë të përshtatshme për ju.
Ne lëshojmë PuttyGen, shtypim butonin "Generate" dhe lëvizim furishëm miun brenda zonës së zbrazët.
Pas përfundimit të procesit, ne mund të ruajmë çelësat publikë dhe privatë, të ngarkojmë çelësin publik në atributin e përdoruesit Active Directory dhe të shijojmë procesin. Megjithatë, çelësi publik duhet të përdoret nga "Çelësi publik për ngjitjen në skedarin OpenSSH autorized_keys:".
Shtoni çelësin në atributin e përdoruesit.
Opsioni 1 - GUI:
Opsioni 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Pra, aktualisht kemi: një përdorues me atributin sshPublicKey të plotësuar, një klient Putty të konfiguruar për autorizim duke përdorur çelësat. Mbetet një pikë e vogël: si ta detyrojmë daemonin sshd të nxjerrë çelësin publik që na nevojitet nga atributet e përdoruesit. Një skenar i vogël i gjetur në internetin borgjez mund ta përballojë me sukses këtë.
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'Ne i vendosëm lejet për të në 0500 për rrënjë.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Në këtë shembull, një llogari administratori përdoret për t'u lidhur me drejtorinë. Në kushte luftarake duhet të ketë një llogari të veçantë me një grup minimal të të drejtave.
Unë personalisht u hutova shumë nga momenti i fjalëkalimit në formën e tij të pastër në skenar, pavarësisht të drejtave të përcaktuara.
Opsioni i zgjidhjes:
- Unë ruaj fjalëkalimin në një skedar të veçantë:
echo -n Supersecretpassword > /usr/local/etc/secretpass - I vendosa lejet e skedarëve në 0500 për rrënjë
chmod 0500 /usr/local/etc/secretpass - Ndryshimi i parametrave të nisjes së ldapsearch: parametri -W superSecretPassword Unë e ndryshoj atë në -y /usr/local/etc/secretpass
Akordi i fundit në suitën e sotme është redaktimi i sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Si rezultat, marrim sekuencën e mëposhtme me autorizimin kyç të konfiguruar në klientin ssh:
- Përdoruesi lidhet me serverin duke treguar hyrjen e tij.
- Daemon sshd, përmes një skripti, nxjerr vlerën e çelësit publik nga një atribut i përdoruesit në Active Directory dhe kryen autorizimin duke përdorur çelësat.
- Daemon sssd vërteton më tej përdoruesin bazuar në anëtarësimin në grup. Kujdes! Nëse kjo nuk është konfiguruar, atëherë çdo përdorues i domenit do të ketë qasje në host.
- Kur përpiqeni të bëni sudo, daemon sssd kërkon role në Active Directory. Nëse rolet janë të pranishme, atributet e përdoruesit dhe anëtarësimi në grup kontrollohen (nëse sudoRoles është konfiguruar për të përdorur grupet e përdoruesve)
Rezultati.
Kështu, çelësat ruhen në atributet e përdoruesve të Active Directory, lejet sudo - në mënyrë të ngjashme, qasja në hostet Linux nga llogaritë e domenit kryhet duke kontrolluar anëtarësimin në grupin Active Directory.
Vala e fundit e stafetës së dirigjentit - dhe salla ngrin në heshtje nderuese.
Burimet e përdorura në shkrim:
Burimi: www.habr.com