Historisk set var sudo-tilladelser styret af indholdet af filer fra /etc/sudoers.d и visudo, og nøgleautorisation blev udført vha ~/.ssh/authorized_keys. Men i takt med at infrastrukturen vokser, er der et ønske om at administrere disse rettigheder centralt. I dag kan der være flere løsningsmuligheder:
- Konfigurationsstyringssystem - Kok, Marionet, Ansible, Salt
- Active Directory + ssd
- Forskellige perversioner i form af scripts og manuel filredigering
Efter min subjektive mening er den bedste mulighed for centraliseret ledelse stadig en kombination Active Directory + ssd. Fordelene ved denne tilgang er:
- Virkelig en enkelt centraliseret brugermappe.
- Fordeling af rettigheder sudo kommer ned til at tilføje en bruger til en bestemt sikkerhedsgruppe.
- I tilfælde af forskellige Linux-systemer bliver det nødvendigt at indføre yderligere kontroller for at bestemme OS, når der bruges konfigurationssystemer.
Dagens suite vil være dedikeret specifikt til forbindelsen Active Directory + ssd til rettighedsforvaltning sudo og opbevaring ssh nøgler i et enkelt lager.
Så salen frøs til i spændt stilhed, dirigenten løftede taktstokken, og orkestret gjorde sig klar.
Gå.
Givet:
— Active Directory-domæne testopf.lokal på Windows Server 2012 R2.
— Linux-vært, der kører Centos 7
— Konfigureret autorisation vha ssd
Begge løsninger foretager ændringer i skemaet Active Directory, så vi tjekker alt i et testmiljø og foretager først derefter ændringer i den fungerende infrastruktur. Jeg vil gerne bemærke, at alle ændringerne er målrettede og faktisk kun tilføjer de nødvendige attributter og klasser.
Handling 1: kontrol sudo roller igennem Active Directory.
For at udvide kredsløbet Active Directory du skal downloade den seneste udgivelse — 1.8.27 i dag. Pak ud og kopier filen schema.ActiveDirectory fra ./doc-biblioteket til domænecontrolleren. Fra kommandolinjen med administratorrettigheder fra den mappe, hvor filen blev kopieret, skal du køre:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Glem ikke at erstatte dine værdier)
åbne adsiedit.msc og opret forbindelse til standardkonteksten:
Opret en division ved roden af domænet sudoers. (Borgeoisiet hævder stædigt, at det er i denne enhed, at dæmonen ssd søger efter en vare sudoRole genstande. Efter at have slået detaljeret fejlfinding til og studeret logfilerne, blev det dog afsløret, at søgningen blev udført i hele mappetræet.)
Vi opretter det første objekt, der tilhører klassen i divisionen sudoRole. Navnet kan vælges helt vilkårligt, da det udelukkende tjener til bekvem identifikation.
Blandt de mulige tilgængelige attributter fra skemaudvidelsen er de vigtigste følgende:
- sudoCommand — bestemmer, hvilke kommandoer der må udføres på værten.
- sudoHost — bestemmer, hvilke værter denne rolle gælder for. Kan specificeres som ALLE, og for en individuel vært ved navn. Det er også muligt at bruge en maske.
- sudoBruger — angive hvilke brugere der har tilladelse til at udføre sudo.
Hvis du angiver en sikkerhedsgruppe, skal du tilføje et "%"-tegn i begyndelsen af navnet. Hvis der er mellemrum i gruppenavnet, er der intet at bekymre sig om. At dømme efter træstammerne overtages opgaven med at undslippe rum af mekanismen ssd.
Fig. 1. sudoRole-objekter i sudoers-underafdelingen i roden af mappen
Figur 2. Medlemskab af sikkerhedsgrupper angivet i sudoRole-objekter.
Følgende opsætning udføres på Linux-siden.
I fil /etc/nsswitch.conf tilføj linjen til slutningen af filen:
sudoers: files sssI fil /etc/sssd/sssd.conf i afsnit [sssd] tilføje til tjenester sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Efter alle operationer skal du rydde sssd daemon-cachen. Automatiske opdateringer sker hver 6. time, men hvorfor skulle vi vente så længe, når vi ønsker det nu?
sss_cache -EDet sker ofte, at det ikke hjælper at rydde cachen. Så stopper vi tjenesten, renser databasen og starter tjenesten.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Vi forbinder som den første bruger og tjekker, hvad der er tilgængeligt 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 gør det samme med vores anden bruger:
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 tilgang giver dig mulighed for centralt at definere sudo-roller for forskellige brugergrupper.
Lagring og brug af ssh-nøgler i Active Directory
Med en lille udvidelse af skemaet er det muligt at gemme ssh-nøgler i Active Directory-brugerattributter og bruge dem ved godkendelse på Linux-værter.
Autorisation via sssd skal konfigureres.
Tilføj den påkrævede attribut ved hjælp af et PowerShell-script.
AddsshPublicKeyAttribute.ps1Funktion 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
$attributter = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntaks = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Bruger offentlig nøgle til SSH login';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Sti $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'navn -eq "bruger"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Når du har tilføjet attributten, skal du genstarte Active Directory Domain Services.
Lad os gå videre til Active Directory-brugere. Vi genererer et nøglepar til ssh-forbindelse ved hjælp af enhver metode, der er praktisk for dig.
Vi starter PuttyGen, trykker på "Generer"-knappen og bevæger hektisk musen inden for det tomme område.
Når processen er afsluttet, kan vi gemme de offentlige og private nøgler, uploade den offentlige nøgle til Active Directory-brugerattributten og nyde processen. Den offentlige nøgle skal dog bruges fra "Offentlig nøgle til indsættelse i OpenSSH authorized_keys-fil:".
Tilføj nøglen til brugerattributten.
Mulighed 1 - GUI:
Mulighed 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Så vi har i øjeblikket: en bruger med sshPublicKey-attributten udfyldt, en konfigureret Putty-klient til godkendelse ved hjælp af nøgler. Der er et lille punkt tilbage: hvordan man tvinger sshd-dæmonen til at udtrække den offentlige nøgle, vi har brug for, fra brugerens attributter. Et lille script fundet på det borgerlige internet kan med succes klare 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 sætter tilladelserne på det til 0500 for root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
I dette eksempel bruges en administratorkonto til at binde til biblioteket. I kampforhold skal der være en separat konto med et minimumssæt af rettigheder.
Jeg var personligt meget forvirret over tidspunktet for adgangskoden i sin rene form i manuskriptet, på trods af de fastsatte rettigheder.
Opløsningsmulighed:
- Jeg gemmer adgangskoden i en separat fil:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Jeg indstillede filtilladelser til 0500 for root
chmod 0500 /usr/local/etc/secretpass - Ændring af ldapsearch startparametre: parameter -w superSecretPassword Jeg ændrer det til -y /usr/local/etc/secretpass
Den sidste akkord i dagens suite er redigering af 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øgleautorisation konfigureret i ssh-klienten:
- Brugeren opretter forbindelse til serveren ved at angive sit login.
- sshd-dæmonen, gennem et script, udtrækker den offentlige nøgleværdi fra en brugerattribut i Active Directory og udfører autorisation ved hjælp af nøglerne.
- sssd-dæmonen autentificerer brugeren yderligere baseret på gruppemedlemskab. Opmærksomhed! Hvis dette ikke er konfigureret, vil enhver domænebruger have adgang til værten.
- Når du prøver at sudo, søger sssd-dæmonen i Active Directory efter roller. Hvis roller er til stede, kontrolleres brugerens attributter og gruppemedlemskab (hvis sudoRoles er konfigureret til at bruge brugergrupper)
Oversigt.
Nøglerne er således gemt i Active Directory-brugerattributter, sudo-tilladelser - på samme måde udføres adgang til Linux-værter af domænekonti ved at kontrollere medlemskab i Active Directory-gruppen.
Den sidste bølge af dirigentstafetten - og salen fryser i ærbødig stilhed.
Ressourcer brugt skriftligt:
Kilde: www.habr.com