Historiskt sett styrdes sudo-behörigheter av innehållet i filer från /etc/sudoers.d и visudo, och nyckelauktorisering utfördes med hjälp av ~/.ssh/authorized_keys. Men i takt med att infrastrukturen växer finns det en önskan att hantera dessa rättigheter centralt. Idag kan det finnas flera lösningsalternativ:
- Konfigurationshanteringssystem - Chef, Marionett, Ansible, Salt
- Active Directory + ssd
- Olika perversioner i form av skript och manuell filredigering
Enligt min subjektiva åsikt är det bästa alternativet för centraliserad förvaltning fortfarande en kombination Active Directory + ssd. Fördelarna med detta tillvägagångssätt är:
- Verkligen en enda centraliserad användarkatalog.
- Fördelning av rättigheter sudo handlar om att lägga till en användare i en specifik säkerhetsgrupp.
- När det gäller olika Linux-system blir det nödvändigt att införa ytterligare kontroller för att fastställa operativsystemet när man använder konfigurationssystem.
Dagens svit kommer att ägnas specifikt åt anslutningen Active Directory + ssd för rättighetsförvaltning sudo och förvaring ssh nycklar i ett enda arkiv.
Så, salen frös i spänd tystnad, dirigenten höjde taktpinnen och orkestern gjorde sig redo.
Gå.
Given:
— Active Directory-domän testopf.local på Windows Server 2012 R2.
— Linux-värd som kör Centos 7
— Konfigurerad auktorisering med ssd
Båda lösningarna gör ändringar i schemat Active Directory, så vi kontrollerar allt i en testmiljö och först därefter gör vi ändringar i den fungerande infrastrukturen. Jag skulle vilja notera att alla ändringar är riktade och faktiskt bara lägger till de nödvändiga attributen och klasserna.
Åtgärd 1: kontroll sudo roller igenom Active Directory.
För att utöka kretsen Active Directory du måste ladda ner den senaste versionen — 1.8.27 från och med idag. Packa upp och kopiera filen schema.ActiveDirectory från ./doc-katalogen till domänkontrollanten. Från kommandoraden med administratörsrättigheter från katalogen där filen kopierades, kör:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Glöm inte att ersätta dina värderingar)
öppna adsiedit.msc och anslut till standardkontexten:
Skapa en division vid roten av domänen sudoers. (Borgerligheten hävdar envist att det är i denna enhet som demonen ssd söker efter ett föremål sudoRole föremål. Men efter att ha aktiverat detaljerad felsökning och studerat loggarna, avslöjades det att sökningen utfördes i hela katalogträdet.)
Vi skapar det första objektet som tillhör klassen i divisionen sudoRole. Namnet kan väljas helt godtyckligt, eftersom det endast tjänar till bekväm identifiering.
Bland de möjliga tillgängliga attributen från schematillägget är de viktigaste följande:
- sudoCommand — bestämmer vilka kommandon som får köras på värden.
- sudoHost — bestämmer vilka värdar som denna roll gäller. Kan anges som ALLA, och för en enskild värd vid namn. Det är också möjligt att använda en mask.
- sudoAnvändare — ange vilka användare som får köra sudo.
Om du anger en säkerhetsgrupp, lägg till ett "%"-tecken i början av namnet. Om det finns mellanslag i gruppnamnet är det inget att oroa sig för. Av stockarna att döma tas uppgiften att fly utrymmen över av mekanismen ssd.
Fig 1. sudoRole-objekt i sudoers-underavdelningen i katalogens rot
Figur 2. Medlemskap i säkerhetsgrupper specificerade i sudoRole-objekt.
Följande inställningar görs på Linux-sidan.
I fil /etc/nsswitch.conf lägg till raden i slutet av filen:
sudoers: files sssI fil /etc/sssd/sssd.conf i avsnitt [sssd] lägga till tjänster sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Efter alla operationer måste du rensa sssd-demoncachen. Automatiska uppdateringar sker var 6:e timme, men varför ska vi vänta så länge när vi vill ha det nu?
sss_cache -EDet händer ofta att det inte hjälper att rensa cachen. Sedan stoppar vi tjänsten, rensar databasen och startar tjänsten.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Vi ansluter som första användare och kontrollerar vad som är tillgängligt för honom 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 samma sak med vår andra användare:
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
Detta tillvägagångssätt låter dig centralt definiera sudo-roller för olika användargrupper.
Lagra och använda ssh-nycklar i Active Directory
Med en liten utvidgning av schemat är det möjligt att lagra ssh-nycklar i Active Directory-användarattribut och använda dem vid auktorisering på Linux-värdar.
Auktorisering via sssd måste konfigureras.
Lägg till det nödvändiga attributet med ett PowerShell-skript.
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
$attribut = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Användarens offentliga nyckel för SSH-inloggning';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
När du har lagt till attributet måste du starta om Active Directory Domain Services.
Låt oss gå vidare till Active Directory-användare. Vi kommer att generera ett nyckelpar för ssh-anslutning med vilken metod som helst som passar dig.
Vi startar PuttyGen, trycker på "Generera"-knappen och flyttar frenetiskt musen inom det tomma området.
När processen är klar kan vi spara de offentliga och privata nycklarna, ladda upp den offentliga nyckeln till Active Directory-användarattributet och njuta av processen. Den publika nyckeln måste dock användas från "Offentlig nyckel för att klistra in i OpenSSH authorized_keys-fil:".
Lägg till nyckeln till användarattributet.
Alternativ 1 - GUI:
Alternativ 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Så vi har för närvarande: en användare med attributet sshPublicKey ifyllt, en konfigurerad Putty-klient för auktorisering med nycklar. Det återstår en liten punkt: hur man tvingar sshd-demonen att extrahera den publika nyckeln vi behöver från användarens attribut. Ett litet manus som finns på det borgerliga Internet kan framgångsrikt klara av detta.
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 ställer in behörigheterna på den till 0500 för root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
I det här exemplet används ett administratörskonto för att binda till katalogen. I stridsförhållanden måste det finnas ett separat konto med ett minimum av rättigheter.
Jag personligen var mycket förvirrad av ögonblicket för lösenordet i dess rena form i manuset, trots de uppsatta rättigheterna.
Lösning alternativ:
- Jag sparar lösenordet i en separat fil:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Jag ställer in filbehörigheter till 0500 för root
chmod 0500 /usr/local/etc/secretpass - Ändra ldapsearch startparametrar: parameter -w superSecretPassword Jag ändrar det till -y /usr/local/etc/secretpass
Det sista ackordet i dagens svit är 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 ett resultat får vi följande sekvens med nyckelbehörighet konfigurerad i ssh-klienten:
- Användaren ansluter till servern genom att ange sin inloggning.
- sshd-demonen, genom ett skript, extraherar det publika nyckelvärdet från ett användarattribut i Active Directory och utför auktorisering med hjälp av nycklarna.
- sssd-demonen autentiserar användaren ytterligare baserat på gruppmedlemskap. Uppmärksamhet! Om detta inte är konfigurerat kommer alla domänanvändare att ha tillgång till värden.
- När du försöker sudo, söker sssd-demonen i Active Directory efter roller. Om roller finns, kontrolleras användarens attribut och gruppmedlemskap (om sudoRoles är konfigurerad att använda användargrupper)
Sammanfattning.
Således lagras nycklarna i Active Directory-användarattribut, sudo-behörigheter - på samma sätt utförs åtkomst till Linux-värdar av domänkonton genom att kontrollera medlemskap i Active Directory-gruppen.
Den sista vågen av dirigentens batong - och salen fryser i vördnadsfull tystnad.
Resurser som används skriftligt:
Källa: will.com