Historisch gezien werden sudo-machtigingen bepaald door de inhoud van bestanden uit /etc/sudoers.d и visudo, en sleutelautorisatie werd uitgevoerd met behulp van ~/.ssh/geautoriseerde_sleutels. Naarmate de infrastructuur groeit, bestaat er echter een wens om deze rechten centraal te beheren. Tegenwoordig kunnen er verschillende oplossingsopties zijn:
- Configuratiebeheersysteem - Chef, Puppet, Ansible, Zout
- Active Directory + ssd
- Verschillende perversies in de vorm van scripts en handmatige bestandsbewerking
Naar mijn subjectieve mening is de beste optie voor gecentraliseerd beheer nog steeds een combinatie Active Directory + ssd. De voordelen van deze aanpak zijn:
- Werkelijk één gecentraliseerde gebruikersdirectory.
- Verdeling van rechten sudo komt neer op het toevoegen van een gebruiker aan een specifieke beveiligingsgroep.
- Bij verschillende Linux-systemen wordt het bij het gebruik van configuratiesystemen noodzakelijk om extra controles in te voeren om het besturingssysteem te bepalen.
De suite van vandaag zal specifiek gewijd zijn aan de verbinding Active Directory + ssd voor rechtenbeheer sudo en opslag ssh sleutels in één opslagplaats.
Dus verstijfde de zaal in gespannen stilte, de dirigent hief zijn stokje op en het orkest maakte zich klaar.
Gaan.
gegeven:
— Active Directory-domein testopf.local op Windows Server 2012 R2.
— Linux-host met Centos 7
— Autorisatie geconfigureerd met ssd
Beide oplossingen brengen wijzigingen aan in het schema Active Directory, dus we controleren alles in een testomgeving en brengen daarna pas wijzigingen aan in de werkende infrastructuur. Ik zou willen opmerken dat alle wijzigingen doelgericht zijn en in feite alleen de noodzakelijke attributen en klassen toevoegen.
Actie 1: controle sudo rollen door Active Directory.
Om het circuit uit te breiden Active Directory je moet de nieuwste release downloaden — 1.8.27 vanaf vandaag. Pak het bestand uit en kopieer het schema.ActiveDirectory van de map ./doc naar de domeincontroller. Voer vanaf de opdrachtregel met beheerdersrechten uit de map waar het bestand is gekopieerd het volgende uit:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Vergeet niet uw waarden te vervangen)
Open adsiedit.msc en maak verbinding met de standaardcontext:
Maak een scheiding in de hoofdmap van het domein sudoers. (De bourgeoisie beweert koppig dat het in deze eenheid is dat de demon ssd zoekt naar een artikel sudoRol voorwerpen. Na het inschakelen van gedetailleerde foutopsporing en het bestuderen van de logboeken werd echter onthuld dat de zoekopdracht in de hele directorystructuur werd uitgevoerd.)
We maken het eerste object dat tot de klasse in de divisie behoort sudoRol. De naam kan absoluut willekeurig worden gekozen, omdat deze uitsluitend dient voor gemakkelijke identificatie.
Van de mogelijk beschikbare kenmerken van de schema-extensie zijn de belangrijkste de volgende:
- sudoCommand — bepaalt welke opdrachten op de host mogen worden uitgevoerd.
- sudoHost — bepaalt op welke hosts deze rol van toepassing is. Kan worden gespecificeerd als ALLE en voor een individuele host op naam. Het is ook mogelijk om een masker te gebruiken.
- sudoGebruiker — geef aan welke gebruikers mogen uitvoeren sudo.
Als u een beveiligingsgroep opgeeft, voegt u een “%”-teken toe aan het begin van de naam. Als er spaties in de groepsnaam staan, hoeft u zich nergens zorgen over te maken. Afgaande op de logboeken wordt de taak van het ontsnappen uit ruimtes overgenomen door het mechanisme ssd.
Fig 1. sudoRole-objecten in de sudoers-onderverdeling in de hoofdmap van de map
Figuur 2. Lidmaatschap van beveiligingsgroepen gespecificeerd in sudoRole-objecten.
De volgende installatie wordt gedaan aan de Linux-kant.
In bestand /etc/nsswitch.conf voeg de regel toe aan het einde van het bestand:
sudoers: files sssIn bestand /etc/sssd/sssd.conf in sectie [ssd] toevoegen aan diensten sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Na alle bewerkingen moet u de cache van de sssd-daemon leegmaken. Automatische updates vinden elke 6 uur plaats, maar waarom zouden we zo lang wachten als we het nu willen?
sss_cache -EHet komt vaak voor dat het wissen van de cache niet helpt. Vervolgens stoppen we de service, maken we de database schoon en starten we de service.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
We maken verbinding als de eerste gebruiker en controleren wat voor hem beschikbaar is 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/catHetzelfde doen we met onze 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
Met deze aanpak kunt u sudo-rollen centraal definiëren voor verschillende gebruikersgroepen.
Ssh-sleutels opslaan en gebruiken in Active Directory
Met een kleine uitbreiding van het schema is het mogelijk om ssh-sleutels op te slaan in Active Directory-gebruikerskenmerken en deze te gebruiken bij autorisatie op Linux-hosts.
Autorisatie via sssd moet worden geconfigureerd.
Voeg het vereiste kenmerk toe met behulp van een PowerShell-script.
AddsshPublicKeyAttribute.ps1Functie Nieuw-kenmerkID {
$Voorvoegsel = "1.2.840.113556.1.8000.2554"
$GUID=[Systeem.Guid]::NewGuid().ToString()
$Onderdelen=@()
$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 = Nieuw kenmerkID
$attributen = @{
lDAPDisplayName = 'sshPublicKey';
attribuutId = $oid;
oMSyntaxis = 22;
attribuutSyntaxis = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Openbare gebruikersleutel voor SSH-aanmelding';
}
Nieuw-ADObject -Name sshPublicKey -Type attributeSchema -Pad $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'naam -eq 'gebruiker''
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Nadat u het kenmerk hebt toegevoegd, moet u Active Directory Domain Services opnieuw opstarten.
Laten we verder gaan met Active Directory-gebruikers. We zullen een sleutelpaar voor de ssh-verbinding genereren op elke voor u geschikte methode.
We starten PuttyGen, drukken op de knop "Genereren" en bewegen de muis verwoed binnen het lege gebied.
Na voltooiing van het proces kunnen we de openbare en privésleutels opslaan, de openbare sleutel uploaden naar het Active Directory-gebruikerskenmerk en genieten van het proces. De publieke sleutel moet echter worden gebruikt vanuit de "Openbare sleutel om in het OpenSSH geautoriseerde_keys-bestand te plakken:".
Voeg de sleutel toe aan het gebruikerskenmerk.
Optie 1 - GUI:
Optie 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
We hebben momenteel dus: een gebruiker met het sshPublicKey-attribuut ingevuld, een geconfigureerde Putty-client voor autorisatie met behulp van sleutels. Er blijft nog één klein punt over: hoe we de sshd-daemon kunnen dwingen de publieke sleutel die we nodig hebben uit de attributen van de gebruiker te halen. Een klein script dat op het burgerlijke internet te vinden is, kan hier met succes mee omgaan.
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'We hebben de machtigingen erop ingesteld op 0500 voor root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
In dit voorbeeld wordt een beheerdersaccount gebruikt om aan de directory te binden. In gevechtsomstandigheden moet er een apart account zijn met een minimum aan rechten.
Persoonlijk was ik erg in de war door het moment van het wachtwoord in zijn pure vorm in het script, ondanks de ingestelde rechten.
Oplossingsoptie:
- Ik bewaar het wachtwoord in een apart bestand:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Ik heb de bestandsrechten voor root ingesteld op 0500
chmod 0500 /usr/local/etc/secretpass - De startparameters van ldapsearch wijzigen: parameter -w supergeheim wachtwoord Ik verander het in -y /usr/local/etc/secretpass
Het slotakkoord in de suite van vandaag is het bewerken van sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Als resultaat krijgen we de volgende reeks met sleutelautorisatie geconfigureerd in de ssh-client:
- De gebruiker maakt verbinding met de server door zijn login aan te geven.
- De sshd-daemon haalt via een script de waarde van de openbare sleutel uit een gebruikerskenmerk in Active Directory en voert autorisatie uit met behulp van de sleutels.
- De sssd-daemon authenticeert de gebruiker verder op basis van groepslidmaatschap. Aandacht! Als dit niet is geconfigureerd, heeft elke domeingebruiker toegang tot de host.
- Wanneer u sudo probeert, doorzoekt de sssd-daemon de Active Directory naar rollen. Als er rollen aanwezig zijn, worden de kenmerken van de gebruiker en het groepslidmaatschap gecontroleerd (als sudoRoles is geconfigureerd om gebruikersgroepen te gebruiken)
Samenvatting.
De sleutels worden dus opgeslagen in Active Directory-gebruikerskenmerken, sudo-machtigingen - op dezelfde manier wordt toegang tot Linux-hosts door domeinaccounts uitgevoerd door het lidmaatschap van de Active Directory-groep te controleren.
De laatste golf van het dirigeerstokje - en de zaal bevriest in eerbiedige stilte.
Schriftelijk gebruikte bronnen:
Bron: www.habr.com