Historicky byla oprávnění sudo řízena obsahem souborů z /etc/sudoers.d и visudoa autorizace klíče byla provedena pomocí ~/.ssh/authorized_keys. S rostoucí infrastrukturou však existuje potřeba spravovat tato práva centrálně. Dnes může být několik možností řešení:
- Systém správy konfigurace - Šéfkuchař, Loutka, Možná, Sůl
- Active Directory + ssd
- Různé zvrhlosti v podobě skriptů a ruční úpravy souborů
Podle mého subjektivního názoru je stále nejlepší variantou centralizovaného řízení kombinace Active Directory + ssd. Výhody tohoto přístupu jsou:
- Skutečně jeden centralizovaný uživatelský adresář.
- Rozdělení práv sudo se týká přidání uživatele do konkrétní skupiny zabezpečení.
- V případě různých linuxových systémů je při použití konfiguračních systémů nutné zavést dodatečné kontroly k určení OS.
Dnešní sada bude věnována konkrétně připojení Active Directory + ssd pro správu práv sudo a skladování ssh klíče v jednom úložišti.
Sál tedy strnul v napjatém tichu, dirigent zvedl taktovku a orchestr se připravil.
Jít.
Vzhledem k:
— doména Active Directory testopf.místní na Windows Server 2012 R2.
— Linuxový hostitel se systémem Centos 7
— Nakonfigurovaná autorizace pomocí ssd
Obě řešení provádějí změny schématu Active Directory, takže vše zkontrolujeme v testovacím prostředí a teprve poté provedeme změny v fungující infrastruktuře. Chtěl bych poznamenat, že všechny změny jsou cílené a ve skutečnosti přidávají pouze potřebné atributy a třídy.
Akce 1: kontrola sudo přes role Active Directory.
Pro rozšíření okruhu Active Directory musíte si stáhnout nejnovější verzi — 1.8.27 k dnešnímu dni. Rozbalte a zkopírujte soubor schema.ActiveDirectory z adresáře ./doc do řadiče domény. Z příkazového řádku s právy správce z adresáře, kam byl soubor zkopírován, spusťte:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Nezapomeňte nahradit své hodnoty)
Otevřít adsiedit.msc a připojte se k výchozímu kontextu:
Vytvořte rozdělení v kořenovém adresáři domény sudoery. (Buržoazie tvrdošíjně tvrdí, že démon je v této jednotce ssd hledá položku sudoRole objektů. Po zapnutí podrobného ladění a prostudování protokolů se však ukázalo, že vyhledávání bylo prováděno v celém stromu adresářů.)
Vytvoříme první objekt patřící do třídy v dělení sudoRole. Jméno lze zvolit naprosto libovolně, slouží pouze k pohodlné identifikaci.
Mezi možnými dostupnými atributy z rozšíření schématu jsou hlavní tyto:
- sudoCommand — určuje, které příkazy mohou být na hostiteli vykonávány.
- sudoHost — určuje, na které hostitele se tato role vztahuje. Lze specifikovat jako VŠECHNOa pro jednotlivého hostitele jménem. Je možné použít i masku.
- sudoUser — uveďte, kteří uživatelé mohou spouštět sudo.
Pokud zadáte skupinu zabezpečení, přidejte na začátek názvu znak „%“. Pokud jsou v názvu skupiny mezery, není se čeho obávat. Soudě podle protokolů, úkol uniknout z prostorů přebírá mechanismus ssd.
Obr 1. Objekty sudoRole v pododdělení sudoers v kořenovém adresáři adresáře
Obrázek 2. Členství v bezpečnostních skupinách specifikovaných v objektech sudoRole.
Následující nastavení se provádí na straně Linuxu.
V souboru /etc/nsswitch.conf přidejte řádek na konec souboru:
sudoers: files sssV souboru /etc/sssd/sssd.conf v sekci [sssd] přidat ke službám sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Po všech operacích musíte vymazat mezipaměť démona sssd. Automatické aktualizace probíhají každých 6 hodin, ale proč bychom měli čekat tak dlouho, když to chceme hned?
sss_cache -EČasto se stává, že vymazání mezipaměti nepomůže. Poté službu zastavíme, vyčistíme databázi a spustíme službu.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Připojíme se jako první uživatel a zkontrolujeme, co má k dispozici pod 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/catTotéž děláme s naším druhým uživatelem:
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
Tento přístup umožňuje centrálně definovat sudo role pro různé skupiny uživatelů.
Ukládání a používání ssh klíčů v Active Directory
S mírným rozšířením schématu je možné ukládat ssh klíče do uživatelských atributů Active Directory a používat je při autorizaci na hostitelích Linux.
Musí být nakonfigurována autorizace přes sssd.
Přidejte požadovaný atribut pomocí skriptu PowerShell.
AddsshPublicKeyAttribute.ps1Funkce New-AtributeID {
$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';
atributId = $oid;
oMSyntaxe = 22;
atributSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Veřejný klíč uživatele pro přihlášení SSH';
}
Nový-ADObject -Název sshPublicKey -Typ atributSchema -Cesta $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Po přidání atributu musíte restartovat službu Active Directory Domain Services.
Přejděme k uživatelům služby Active Directory. Vygenerujeme klíčový pár pro ssh připojení jakýmkoliv způsobem, který vám vyhovuje.
Spustíme PuttyGen, stiskneme tlačítko „Generovat“ a zběsile pohybujeme myší v prázdné oblasti.
Po dokončení procesu můžeme uložit veřejný a soukromý klíč, nahrát veřejný klíč do uživatelského atributu Active Directory a užít si proces. Veřejný klíč však musí být použit z "Veřejný klíč pro vložení do souboru OpenSSH author_keys:".
Přidejte klíč do uživatelského atributu.
Možnost 1 – GUI:
Možnost 2 – PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Aktuálně tedy máme: uživatele s vyplněným atributem sshPublicKey, nakonfigurovaného klienta Putty pro autorizaci pomocí klíčů. Zbývá jeden malý bod: jak donutit démona sshd, aby extrahoval veřejný klíč, který potřebujeme, z atributů uživatele. Malý scénář nalezený na buržoazním internetu si s tím dokáže úspěšně poradit.
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'Nastavili jsme oprávnění na 0500 pro root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
V tomto příkladu je k navázání na adresář použit účet správce. V bojových podmínkách musí existovat samostatný účet s minimální sadou práv.
Mě osobně velmi zmátl moment hesla v čisté podobě ve scénáři, navzdory nastaveným právům.
Možnost řešení:
- Heslo ukládám do samostatného souboru:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Nastavil jsem oprávnění k souboru na 0500 pro root
chmod 0500 /usr/local/etc/secretpass - Změna parametrů spouštění ldapsearch: parametr -w superSecretPassword Měním to na -y /usr/local/etc/secretpass
Posledním akordem v dnešní sadě je úprava sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Výsledkem je následující sekvence s autorizací klíče nakonfigurovanou v klientovi ssh:
- Uživatel se připojí k serveru uvedením svého přihlášení.
- Démon sshd prostřednictvím skriptu extrahuje hodnotu veřejného klíče z uživatelského atributu v Active Directory a provede autorizaci pomocí klíčů.
- Démon sssd dále ověřuje uživatele na základě členství ve skupině. Pozornost! Pokud toto není nakonfigurováno, bude mít k hostiteli přístup jakýkoli uživatel domény.
- Když se pokusíte o sudo, démon sssd hledá role v Active Directory. Pokud jsou přítomny role, zkontrolují se atributy uživatele a členství ve skupinách (pokud je sudoRoles nakonfigurován pro použití skupin uživatelů)
Shrnutí.
Klíče jsou tedy uloženy v uživatelských atributech Active Directory, oprávnění sudo - obdobně se přístup k linuxovým hostitelům podle doménových účtů provádí kontrolou členství ve skupině Active Directory.
Poslední mávnutí dirigentské taktovky – a sál zamrzne v pietním tichu.
Zdroje použité při psaní:
Zdroj: www.habr.com