Historikoki, sudo baimenak fitxategien edukiak arautzen zituen /etc/sudoers.d и visudo, eta gakoen baimena erabiliz egin da ~/.ssh/authorized_keys. Hala ere, azpiegiturak hazi ahala, eskubide horiek zentralki kudeatzeko nahia dago. Gaur egun, hainbat irtenbide aukera egon daitezke:
- Konfigurazioa Kudeatzeko Sistema - Chef, Txotxongilo, Ansible, Salt
- Active Directory + ssd
- Hainbat perbertsio script eta eskuzko fitxategien edizio moduan
Nire iritzi subjektiboan, kudeaketa zentralizaturako aukerarik onena konbinazioa da oraindik Active Directory + ssd. Ikuspegi honen abantailak hauek dira:
- Benetan zentralizatutako erabiltzaileen direktorio bakarra.
- Eskubideen banaketa sudo Erabiltzaile bat segurtasun talde zehatz batean gehitzearekin datza.
- Linux sistema ezberdinen kasuan, konfigurazio sistemak erabiltzean sistema eragilea zehazteko egiaztapen gehigarriak sartzea beharrezkoa da.
Gaurko suitea bereziki konexioari eskainiko zaio Active Directory + ssd eskubideak kudeatzeko sudo eta biltegiratzea ssh gakoak biltegi bakarrean.
Hala, aretoa izoztu egin zen tentsio isilunean, zuzendariak makila altxatu zuen eta orkestra prestatu zen.
Go.
Emana:
— Active Directory domeinua testopf.local Windows Server 2012 R2-n.
- Centos 7 exekutatzen duen Linux ostalaria
— Konfiguratutako baimena erabiliz ssd
Bi irtenbideek eskeman aldaketak egiten dituzte Active Directory, beraz, proba-ingurunean dena egiaztatzen dugu eta orduan bakarrik aldaketak egiten ditugu laneko azpiegituran. Kontuan izan nahiko nuke aldaketa guztiak zuzenduta daudela eta, hain zuzen ere, beharrezko atributuak eta klaseak soilik gehitzen dituztela.
1. ekintza: kontrola sudo rolak bidez Active Directory.
Zirkuitua zabaltzeko Active Directory azken bertsioa deskargatu behar duzu - 1.8.27 gaurtik aurrera. Despaketeatu eta kopiatu fitxategia eskema.ActiveDirectory ./doc direktoriotik domeinu-kontrolatzailera. Fitxategia kopiatu den direktoriotik administratzaile-eskubideak dituen komando-lerrotik, exekutatu:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Ez ahaztu zure balioak ordezkatzeaz)
ireki adsiedit.msc eta konektatu lehenetsitako testuingurura:
Sortu zatiketa domeinuaren erroan sudoers. (Burgesiak temati esaten du unitate honetan dagoela deabrua ssd elementu bat bilatzen du sudoRole objektuak. Hala ere, arazketa zehatza aktibatu eta erregistroak aztertu ondoren, bilaketa direktorioen zuhaitz osoan zehar egin zela agerian geratu zen.)
Dibisioan klaseari dagokion lehen objektua sortzen dugu sudoRole. Izena erabat arbitrarioki hauta daiteke, identifikazio erosoa egiteko soilik balio baitu.
Eskema luzapenaren erabilgarri dauden atributu posibleen artean, nagusiak hauek dira:
- sudoCommand — ostalarian zein komando exekutatu daitezkeen zehazten du.
- sudoHost — rol hau zein ostalariri aplikatzen zaion zehazten du. Honela zehaztu daiteke ALL, eta banakako ostalariaren izenaren arabera. Maskara bat ere erabil daiteke.
- sudoErabiltzailea — adierazi zein erabiltzailek exekutatzeko baimena duten sudo.
Segurtasun-talde bat zehazten baduzu, gehitu "%" ikurra izenaren hasieran. Taldearen izenan tarteak badaude, ez dago ezer kezkatu. Erregistroak ikusita, espazioetatik ihes egiteko zeregina mekanismoak hartzen du bere gain ssd.
1. irudia sudoRole objektuak direktorioaren erroan sudoers azpisailean
2. Irudia. SudoRole objektuetan zehaztutako segurtasun taldeetako kidetasuna.
Ondorengo konfigurazioa Linux aldean egiten da.
Fitxategian /etc/nsswitch.conf gehitu lerroa fitxategiaren amaieran:
sudoers: files sssFitxategian /etc/sssd/sssd.conf atalean [sssd] gehitu zerbitzuei sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Eragiketa guztien ondoren, sssd daemon cachea garbitu behar duzu. Eguneratze automatikoak 6 orduz behin gertatzen dira, baina zergatik itxaron behar dugu hainbeste denbora nahi dugunean?
sss_cache -EAskotan gertatzen da cachea garbitzeak ez duela laguntzen. Ondoren, zerbitzua gelditu, datu-basea garbitu eta zerbitzua abiarazten dugu.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Lehen erabiltzaile gisa konektatzen gara eta sudo azpian zer dagoen egiaztatzen dugu:
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/catGauza bera egiten dugu gure bigarren erabiltzailearekin:
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
Ikuspegi honek sudo rolak zentralki definitzeko aukera ematen du erabiltzaile talde desberdinetarako.
Active Directory-n ssh gakoak gordetzea eta erabiltzea
Eskemaren hedapen apur batekin, posible da ssh gakoak gordetzea Active Directory erabiltzaileen atributuetan eta Linux ostalarietan baimentzean erabiltzea.
Sssd bidezko baimena konfiguratu behar da.
Gehitu beharrezko atributua PowerShell script bat erabiliz.
GehituSshPublicKeyAttribute.ps1Funtzioa New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UInt64]::Analisi($guid.SubString(0,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Analisi($guid.SubString(4,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Analisi($guid.SubString(9,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Analisi($guid.SubString(14,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Analisi($guid.SubString(19,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Analisi($guid.SubString(24,6),“AllowHexSpecifier”)
$Parts+=[UInt64]::Analisi($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
$atributuak = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $egia;
adminDescription = 'Erabiltzailea SSH saioa hasteko gako publikoa';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'izena -eq "erabiltzailea"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Atributua gehitu ondoren, Active Directory Domain Services berrabiarazi behar duzu.
Joan gaitezen Active Directory erabiltzaileetara. Ssh konexiorako gako-pare bat sortuko dugu zuretzat komeni den edozein metodo erabiliz.
PuttyGen abiarazten dugu, "Sortu" botoia sakatu eta sagua izugarri mugitzen dugu hutsik dagoen eremuan.
Prozesua amaitutakoan, gako publikoak eta pribatuak gorde ditzakegu, gako publikoa Active Directory erabiltzaile-atributuan igo eta prozesuaz gozatu. Hala ere, gako publikoa "tik" erabili behar daOpenSSH authorized_keys fitxategian itsasteko gako publikoa:".
Gehitu gakoa erabiltzailearen atributuari.
1. aukera - GUI:
2. aukera - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Beraz, gaur egun honako hauek ditugu: sshPublicKey atributua beteta duen erabiltzailea, gakoak erabiliz baimentzeko Putty bezero konfiguratua. Puntu txiki bat geratzen da: nola behartu sshd deabrua erabiltzailearen atributuetatik behar dugun gako publikoa ateratzera. Internet burgesean aurkitutako gidoi txiki batek ongi aurre egin diezaioke horri.
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'Baimenak 0500 gisa ezarri ditugu rooterako.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Adibide honetan, administratzaile kontu bat erabiltzen da direktoriora lotzeko. Borroka baldintzetan aparteko kontu bat egon behar da gutxieneko eskubide multzo batekin.
Pertsonalki oso nahastu nintzen gidoian pasahitza hutsean dagoen momentuarekin, eskubideak ezarri arren.
Irtenbide aukera:
- Pasahitza beste fitxategi batean gordetzen dut:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Fitxategien baimenak 0500-n ezarri ditut root-erako
chmod 0500 /usr/local/etc/secretpass - ldapsearch abiarazteko parametroak aldatzea: parametroa -w SuperSecretPassword Aldatzen dut -y /usr/local/etc/secretpass
Gaurko suiteko azken akordea sshd_config editatzea da
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Ondorioz, ssh bezeroan konfiguratutako gako-baimenarekin sekuentzia hau lortuko dugu:
- Erabiltzailea zerbitzariarekin konektatzen da bere saioa adieraziz.
- Sshd deabruak, script baten bidez, Active Directory-ko erabiltzailearen atributu batetik gako publikoaren balioa ateratzen du eta gakoak erabiliz baimena egiten du.
- Sssd deabruak erabiltzailea gehiago autentifikatzen du taldekidetasunaren arabera. Kontuz! Hau konfiguratuta ez badago, domeinuko edozein erabiltzailek izango du ostalariaren sarbidea.
- Sudo egiten saiatzen zarenean, sssd daemonak Active Directory-n bilatzen ditu rolak. Rolak badaude, erabiltzailearen atributuak eta taldekidetasuna egiaztatzen dira (sudoRoles erabiltzaile-taldeak erabiltzeko konfiguratuta badago)
Laburpena.
Horrela, gakoak Active Directory erabiltzaileen atributuetan gordetzen dira, sudo baimenetan; era berean, Linux ostalarietarako sarbidea domeinu kontuen bidez egiten da Active Directory taldeko kide izatea egiaztatuz.
Zuzendariaren makilaren azken uhina - eta aretoa izoztu egiten da isiltasun begirunez.
Idatziz erabilitako baliabideak:
Iturria: www.habr.com