Historisk sett ble sudo-tillatelser styrt av innholdet i filer fra /etc/sudoers.d и visado, og nøkkelautorisasjon ble utført vha ~/.ssh/authorized_keys. Men etter hvert som infrastrukturen vokser, er det et ønske om å forvalte disse rettighetene sentralt. I dag kan det være flere løsningsalternativer:
- Konfigurasjonsstyringssystem - Chef, Puppet, Ansible, Salt
- Active Directory + ssd
- Ulike perversjoner i form av skript og manuell filredigering
Etter min subjektive mening er det beste alternativet for sentralisert ledelse fortsatt en kombinasjon Active Directory + ssd. Fordelene med denne tilnærmingen er:
- Virkelig en enkelt sentralisert brukerkatalog.
- Fordeling av rettigheter sudo kommer ned til å legge til en bruker i en bestemt sikkerhetsgruppe.
- Når det gjelder ulike Linux-systemer, blir det nødvendig å innføre ytterligere kontroller for å bestemme OS ved bruk av konfigurasjonssystemer.
Dagens suite vil være dedikert spesifikt til forbindelsen Active Directory + ssd for rettighetsforvaltning sudo og lagring ssh nøkler i et enkelt depot.
Så salen frøs i spent stillhet, dirigenten løftet stafettpinnen, og orkesteret gjorde seg klar.
Gå.
gitt:
— Active Directory-domene testopf.local på Windows Server 2012 R2.
- Linux-vert som kjører Centos 7
— Konfigurert autorisasjon ved hjelp av ssd
Begge løsningene gjør endringer i skjemaet Active Directory, så vi sjekker alt i et testmiljø og først da gjør vi endringer i den fungerende infrastrukturen. Jeg vil merke meg at alle endringene er målrettede og faktisk bare legge til de nødvendige attributtene og klassene.
Handling 1: kontroll sudo roller gjennom Active Directory.
For å utvide kretsen Active Directory du må laste ned den nyeste utgivelsen — 1.8.27 per i dag. Pakk ut og kopier filen schema.ActiveDirectory fra ./doc-katalogen til domenekontrolleren. Fra kommandolinjen med administratorrettigheter fra katalogen der filen ble kopiert, kjør:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Ikke glem å erstatte verdiene dine)
åpne adsiedit.msc og koble til standardkonteksten:
Lag en divisjon ved roten av domenet gensere. (Borgerskapet hevder hardnakket at det er i denne enheten demonen ssd søker etter en vare sudoRolle gjenstander. Etter å ha slått på detaljert feilsøking og studert loggene, ble det imidlertid avslørt at søket ble utført gjennom hele katalogtreet.)
Vi lager det første objektet som tilhører klassen i divisjonen sudoRolle. Navnet kan velges helt vilkårlig, da det utelukkende tjener til praktisk identifikasjon.
Blant de mulige tilgjengelige attributtene fra skjemautvidelsen er de viktigste følgende:
- sudoCommand — bestemmer hvilke kommandoer som er tillatt å bli utført på verten.
- sudoHost — bestemmer hvilke verter denne rollen gjelder for. Kan spesifiseres som ALLE, og for en individuell vert ved navn. Det er også mulig å bruke maske.
- sudoBruker — angi hvilke brukere som har lov til å utføre sudo.
Hvis du spesifiserer en sikkerhetsgruppe, legger du til et "%"-tegn i begynnelsen av navnet. Hvis det er mellomrom i gruppenavnet, er det ingenting å bekymre seg for. Etter tømmerstokkene å dømme, overtas oppgaven med å rømme rom av mekanismen ssd.
Fig 1. sudoRole-objekter i sudoers-underavdelingen i roten av katalogen
Figur 2. Medlemskap i sikkerhetsgrupper spesifisert i sudoRole-objekter.
Følgende oppsett gjøres på Linux-siden.
I fil /etc/nsswitch.conf legg til linjen på slutten av filen:
sudoers: files sssI fil /etc/sssd/sssd.conf i seksjon [sssd] legge til tjenester sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Etter alle operasjoner må du tømme sssd daemon-cachen. Automatiske oppdateringer skjer hver 6. time, men hvorfor skal vi vente så lenge når vi ønsker det nå?
sss_cache -EDet hender ofte at det ikke hjelper å tømme cachen. Deretter stopper vi tjenesten, renser databasen og starter tjenesten.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Vi kobler til som den første brukeren og sjekker hva som er tilgjengelig for ham under 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/catVi gjør det samme med vår andre bruker:
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
Denne tilnærmingen lar deg definere sudo-roller sentralt for forskjellige brukergrupper.
Lagre og bruke ssh-nøkler i Active Directory
Med en liten utvidelse av ordningen er det mulig å lagre ssh-nøkler i Active Directory-brukerattributter og bruke dem når du autoriserer på Linux-verter.
Autorisasjon via sssd må konfigureres.
Legg til det nødvendige attributtet ved hjelp av et PowerShell-skript.
AddsshPublicKeyAttribute.ps1Funksjon 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 = New-AttributeID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntaks = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Bruker offentlig nøkkel for SSH-pålogging';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'navn -eq "bruker"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Etter å ha lagt til attributtet, må du starte Active Directory Domain Services på nytt.
La oss gå videre til Active Directory-brukere. Vi vil generere et nøkkelpar for ssh-tilkobling ved å bruke hvilken som helst metode som er praktisk for deg.
Vi starter PuttyGen, trykker på "Generer"-knappen og beveger febrilsk musen innenfor det tomme området.
Når prosessen er fullført, kan vi lagre de offentlige og private nøklene, laste opp den offentlige nøkkelen til Active Directory-brukerattributtet og nyte prosessen. Den offentlige nøkkelen må imidlertid brukes fra "Offentlig nøkkel for å lime inn i OpenSSH authorized_keys-fil:".
Legg til nøkkelen til brukerattributtet.
Alternativ 1 - GUI:
Alternativ 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Så vi har for øyeblikket: en bruker med sshPublicKey-attributtet fylt ut, en konfigurert Putty-klient for autorisasjon ved hjelp av nøkler. Det gjenstår et lite poeng: hvordan tvinge sshd-demonen til å trekke ut den offentlige nøkkelen vi trenger fra brukerens attributter. Et lite manus funnet på det borgerlige Internett kan med hell takle dette.
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'Vi setter tillatelsene på den til 0500 for root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
I dette eksemplet brukes en administratorkonto for å binde seg til katalogen. I kampforhold må det være en egen konto med et minimumssett av rettigheter.
Jeg personlig var veldig forvirret av øyeblikket av passordet i sin rene form i manuset, til tross for rettighetene som er satt.
Løsningsalternativ:
- Jeg lagrer passordet i en egen fil:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Jeg satte filtillatelser til 0500 for root
chmod 0500 /usr/local/etc/secretpass - Endre ldapsearch-startparametere: parameter -w superSecretPassword Jeg endrer det til -y /usr/local/etc/secretpass
Den siste akkorden i dagens suite er redigering av sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Som et resultat får vi følgende sekvens med nøkkelautorisasjon konfigurert i ssh-klienten:
- Brukeren kobler seg til serveren ved å angi pålogging.
- sshd-demonen, gjennom et skript, trekker ut den offentlige nøkkelverdien fra et brukerattributt i Active Directory og utfører autorisasjon ved hjelp av nøklene.
- sssd-demonen autentiserer brukeren videre basert på gruppemedlemskap. Merk følgende! Hvis dette ikke er konfigurert, vil enhver domenebruker ha tilgang til verten.
- Når du prøver å sudo, søker sssd-demonen i Active Directory etter roller. Hvis roller er til stede, sjekkes brukerens attributter og gruppemedlemskap (hvis sudoRoles er konfigurert til å bruke brukergrupper)
Oppsummering.
Dermed lagres nøklene i Active Directory-brukerattributter, sudo-tillatelser - på samme måte utføres tilgang til Linux-verter etter domenekontoer ved å sjekke medlemskap i Active Directory-gruppen.
Den siste bølgen av dirigentens stafettpinnen – og salen fryser i ærbødig stillhet.
Ressurser brukt skriftlig:
Kilde: www.habr.com