Histories is sudo-regte beheer deur die inhoud van lêers van /etc/sudoers.d и visado, en magtiging deur sleutels is uitgevoer met behulp van ~/.ssh/authorized_keys. Met die groei van infrastruktuur is daar egter 'n begeerte om hierdie regte sentraal te bestuur. Op die oomblik is daar verskeie moontlike oplossings:
- Konfigurasiebestuurstelsel - Chef, Puppet, Ansible, Sout
- Active Directory + ssd
- Verskeie perversies in die vorm van skrifte en handmatige redigering van lêers
Na my subjektiewe mening is die beste opsie vir gesentraliseerde bestuur steeds 'n klomp Active Directory + ssd. Die voordele van hierdie benadering is:
- Regtig die Uniform gesentraliseerde gids van gebruikers.
- Verspreiding van regte sudo kom daarop neer om 'n gebruiker by 'n spesifieke sekuriteitsgroep te voeg.
- In die geval van verskeie Linux-stelsels, word dit nodig om bykomende kontrole in te stel om die bedryfstelsel te bepaal wanneer konfigurasiestelsels gebruik word.
Vandag se suite sal aan die bundel opgedra word Active Directory + ssd vir regtebestuur sudo en berging ssh sleutels in 'n enkele bewaarplek.
So, die saal verstar in gespanne stilte, die dirigent het sy stokkie gelig, die orkes het voorberei.
Laat ons gaan.
Gegee:
- Active Directory-domein testopf.local op Windows Server 2012 R2.
- Linux-gasheer met Centos 7
- Pasgemaakte magtiging met behulp van ssd
Beide oplossings maak skema veranderinge Active Directory, so ons gaan alles op 'n toetsomgewing na en maak dan eers veranderinge aan die werkende infrastruktuur. Ek wil daarop let dat al die veranderinge puntsgewys is en in werklikheid slegs die nodige eienskappe en klasse byvoeg.
Aksie 1: bestuur sudo rolle deur Active Directory.
Om die skema uit te brei Active Directory jy moet die nuutste weergawe aflaai - 1.8.27 vandag. Pak uit, kopieer die lêer schema.ActiveDirectory van die ./doc-gids na 'n domeinbeheerder. Begin vanaf die opdragreël met administrateurregte vanaf die gids waarheen die lêer gekopieer is:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Moenie vergeet om jou waardes te vervang nie)
Maak oop adsiedit.msc en koppel aan die verstekkonteks:
Skep 'n onderafdeling aan die wortel van die domein truie. (Die bourgeois beweer hardnekkig dat dit in hierdie eenheid is dat die demoon ssd soek na 'n item sudoRol voorwerpe. Nadat u egter gedetailleerde ontfouting aangeskakel het en die logboeke ondersoek het, is gevind dat die soektog deur die hele gidsboom uitgevoer word.)
Skep die eerste voorwerp in die afdeling wat aan die klas behoort sudoRol. Die naam kan absoluut arbitrêr gekies word, aangesien dit uitsluitlik dien vir gerieflike identifikasie.
Onder die moontlike eienskappe wat beskikbaar is vanaf 'n skema-uitbreiding, is die belangrikste:
- sudoCommand - bepaal watter opdragte toegelaat word om op die gasheer uitgevoer te word.
- sudoHost - bepaal vir watter gashere hierdie rol toegepas word. Kan gegee word as ALMAL, en vir 'n aparte gasheer by naam. Dit is ook moontlik om 'n masker te gebruik.
- sudoGebruiker - spesifiseer watter gebruikers toegelaat word om uit te voer sudo.
As 'n sekuriteitsgroep gespesifiseer is, voeg 'n "%"-teken aan die begin van die naam by. As daar spasies in die groepnaam is, is daar niks om oor bekommerd te wees nie. Te oordeel aan die stompe word die taak om ruimtes te ontsnap deur die meganisme oorgeneem ssd.
Figuur 1 sudoRole-voorwerpe in die sudoers-onderafdeling aan die wortel van die gids
Fig 2. Lidmaatskap in sekuriteitsgroepe gespesifiseer in sudoRole-objekte.
Die volgende opstelling word aan die Linux-kant gedoen.
In lêer /etc/nsswitch. conf voeg die volgende reël by die einde van die lêer:
sudoers: files sssIn lêer /etc/sssd/sssd.conf in afdeling [sssd] by dienste voeg sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Na alle bewerkings moet u die kas van die sssd-demoon skoonmaak. Outomatiese opdaterings word elke 6 uur gemaak, maar hoekom moet ons so lank wag as ons nou wil.
sss_cache -EDit gebeur dikwels dat die skoonmaak van die kas nie help nie. Dan stop ons die diens, maak die databasis skoon, begin die diens.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Ons koppel as die eerste gebruiker en kyk wat vir hom beskikbaar is van onder 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/catOns doen dieselfde met ons tweede gebruiker:
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
Hierdie benadering laat jou toe om sudo-rolle vir verskillende gebruikersgroepe sentraal te definieer.
Berging en gebruik van ssh-sleutels in Active Directory
Met 'n effense uitbreiding van die skema, is dit moontlik om ssh-sleutels in Active Directory-gebruikerskenmerke te stoor en dit te gebruik wanneer dit op Linux-gashere gemagtig word.
Magtiging via sssd moet gekonfigureer word.
Ons voeg die vereiste kenmerk by met behulp van die PowerShell-skrip.
AddsshPublicKeyAttribute.ps1Funksie Nuwe-kenmerk-ID {
$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 = Nuwe kenmerk-ID
$attribute = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $id;
oMSintaksis = 22;
kenmerkSyntaksis="2.5.5.5";
isSingleValued = $true;
adminDescription = 'Gebruiker publieke sleutel vir SSH-aanmelding';
}
New-ADObject -Name sshPublicKey -Type attributeSkema -Pad $schemapath -AnderKenmerke $attribute
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Nadat u die kenmerk bygevoeg het, moet u Active Directory Domain Services herbegin.
Kom ons gaan aan na Active Directory-gebruikers. Op enige manier wat vir jou gerieflik is, genereer ons 'n paar sleutels vir ssh-verbinding.
Ons begin PuttyGen, druk die "Generate"-knoppie en kruip woes die muis binne die leë area.
Na voltooiing van die proses, kan ons die publieke en private sleutels stoor, die publieke sleutel oplaai na die Active Directory-gebruikerskenmerk en die proses geniet. Die publieke sleutel moet egter gebruik word vanaf die "Publieke sleutel om in OpenSSH authorized_keys-lêer te plak:«.
Voeg die sleutel by die gebruikerkenmerk.
Opsie 1 - GUI:
Opsie 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Dus, op die oomblik het ons: 'n gebruiker met die sshPublicKey-kenmerk ingevul, 'n gekonfigureerde Putty-kliënt vir magtiging deur sleutels. Daar bly nog een klein puntjie oor, hoe om die sshd-demoon te dwing om die publieke sleutel wat ons nodig het uit die gebruiker se eienskappe te trek. 'n Klein skrif wat op die oop ruimtes van die bourgeois Internet gevind word, hanteer dit suksesvol.
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'Ons stel die regte daarop 0500 vir root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
In hierdie voorbeeld word die administrateurrekening gebruik om aan die gids te bind. In gevegstoestande moet daar 'n aparte rekening met 'n minimum stel regte wees.
Persoonlik was ek baie skaam oor die oomblik van die wagwoord in sy suiwer vorm in die skrif, ten spyte van die vasgestelde regte.
Oplossingsopsie:
- Ek stoor die wagwoord in 'n aparte lêer:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Ek stel die regte op die lêer 0500 vir root
chmod 0500 /usr/local/etc/secretpass - Verander ldapsearch-opstartopsies: parameter -w superSecretPassword verander na -y /usr/local/etc/secretpass
Die finale akkoord in vandag se suite is redigering sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
As gevolg hiervan kry ons die volgende volgorde met gekonfigureerde magtiging deur sleutels in die ssh-kliënt:
- Die gebruiker koppel aan die bediener deur sy aanmelding te spesifiseer.
- Die sshd-demon trek die waarde van die publieke sleutel uit die gebruikerskenmerk in Active Directory deur 'n skrip en voer magtiging deur sleutels uit.
- Die sssd-demoon voer verdere gebruikersverifikasie uit op grond van groeplidmaatskap. Aandag! As dit nie opgestel is nie, sal enige domeingebruiker toegang tot die gasheer hê.
- Wanneer jy probeer sudo, soek die sssd-demoon in die Active Directory vir rolle. As daar rolle is, word die kenmerke en groeplidmaatskap van die gebruiker nagegaan (as sudoRoles opgestel is om gebruikersgroepe te gebruik)
Die resultaat.
Sleutels word dus gestoor in Active Directory-gebruikerskenmerke, sudo-toestemmings - op soortgelyke wyse word toegang tot Linux-gashere met domeinrekeninge uitgevoer deur lidmaatskap in 'n Active Directory-groep na te gaan.
Die laaste golf van die dirigent se stokkie - en die saal vries in eerbiedige stilte.
Hulpbronne wat skriftelik gebruik word:
Bron: will.com