Historycznie rzecz biorąc, uprawnienia sudo były regulowane przez zawartość plików z /etc/sudoers.d и visudo, a autoryzacja klucza została przeprowadzona przy użyciu ~/.ssh/authorized_keys. Jednakże w miarę rozwoju infrastruktury istnieje potrzeba centralnego zarządzania tymi prawami. Dzisiaj może być kilka opcji rozwiązania:
- System zarządzania konfiguracją - Szef kuchni, Marionetka, Wiarygodne, Sól
- Active Directory + SSD
- Różne perwersje w postaci skryptów i ręcznej edycji plików
Moim subiektywnym zdaniem najlepszą opcją zarządzania scentralizowanego jest nadal kombinacja Active Directory + SSD. Zalety tego podejścia to:
- Prawdziwie pojedynczy scentralizowany katalog użytkowników.
- Podział praw sudo sprowadza się do dodania użytkownika do określonej grupy zabezpieczeń.
- W przypadku różnych systemów Linux konieczne staje się wprowadzenie dodatkowych kontroli w celu ustalenia systemu operacyjnego podczas korzystania z systemów konfiguracyjnych.
Dzisiejszy pakiet będzie poświęcony specjalnie łączu Active Directory + SSD do zarządzania prawami sudo i przechowywanie ssh klucze w jednym repozytorium.
Tak więc sala zamarła w napiętej ciszy, dyrygent podniósł pałeczkę, a orkiestra była gotowa.
Iść.
Biorąc pod uwagę:
— Domena Active Directory testopf.lokalny w systemie Windows Server 2012 R2.
— Host Linux z systemem Centos 7
— Skonfigurowana autoryzacja przy użyciu SSD
Obydwa rozwiązania wprowadzają zmiany w schemacie Active Directory, więc wszystko sprawdzamy na środowisku testowym i dopiero potem wprowadzamy zmiany w działającej infrastrukturze. Chciałbym zauważyć, że wszystkie zmiany są ukierunkowane i tak naprawdę dodają tylko niezbędne atrybuty i klasy.
Działanie 1: kontrola sudo role przez Active Directory.
Aby rozszerzyć obwód Active Directory musisz pobrać najnowszą wersję — 1.8.27 na dzień dzisiejszy. Rozpakuj i skopiuj plik schemat.ActiveDirectory z katalogu ./doc do kontrolera domeny. Z wiersza poleceń z uprawnieniami administratora z katalogu, do którego skopiowano plik, uruchom:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Nie zapomnij zastąpić swoich wartości)
Otwarte adsiedit.msc i połącz się z domyślnym kontekstem:
Utwórz podział w katalogu głównym domeny sudoers. (Burżuazja uparcie twierdzi, że w tej jednostce tkwi demon SSD szuka przedmiotu sudoRola obiekty. Jednak po włączeniu szczegółowego debugowania i przestudiowaniu logów okazało się, że przeszukiwanie przeprowadzono w całym drzewie katalogów.)
Tworzymy pierwszy obiekt należący do klasy w podziale sudoRola. Nazwę można wybrać całkowicie dowolnie, służy ona wyłącznie do wygodnej identyfikacji.
Wśród możliwych dostępnych atrybutów z rozszerzenia schematu najważniejsze to:
- polecenie sudo — określa, które polecenia mogą być wykonywane na hoście.
- sudoHost — określa, których hostów dotyczy ta rola. Można określić jako WSZYSTKOi dla pojedynczego hosta według nazwy. Możliwe jest również zastosowanie maski.
- Użytkownik sudo — wskazać, którzy użytkownicy mogą wykonywać operacje sudo.
Jeśli określisz grupę zabezpieczeń, dodaj znak „%” na początku nazwy. Jeśli w nazwie grupy znajdują się spacje, nie ma się czym martwić. Sądząc po logach, zadanie ucieczki z przestrzeni przejmuje mechanizm SSD.
Rys. 1. Obiekty sudoRole w poddziale sudoers w katalogu głównym
Rysunek 2. Członkostwo w grupach bezpieczeństwa określonych w obiektach sudoRole.
Następująca konfiguracja jest wykonywana po stronie systemu Linux.
W pliku /etc/nsswitch.conf dodaj linię na końcu pliku:
sudoers: files sssW pliku /etc/sssd/sssd.conf w sekcji [sssd] dodać do usług sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Po wszystkich operacjach należy wyczyścić pamięć podręczną demona sssd. Automatyczne aktualizacje następują co 6 godzin, ale po co mamy czekać tak długo, skoro chcemy tego teraz?
sss_cache -ECzęsto zdarza się, że wyczyszczenie pamięci podręcznej nie pomaga. Następnie zatrzymujemy usługę, czyścimy bazę danych i uruchamiamy usługę.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Łączymy się jako pierwszy użytkownik i sprawdzamy co jest dla niego dostępne 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/catTo samo robimy z naszym drugim użytkownikiem:
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
Takie podejście umożliwia centralne definiowanie ról sudo dla różnych grup użytkowników.
Przechowywanie i używanie kluczy ssh w Active Directory
Po niewielkim rozszerzeniu schematu możliwe jest przechowywanie kluczy ssh w atrybutach użytkownika Active Directory i używanie ich podczas autoryzacji na hostach Linux.
Należy skonfigurować autoryzację poprzez sssd.
Dodaj wymagany atrybut za pomocą skryptu PowerShell.
DodajesshPublicKeyAttribute.ps1Funkcja New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Części=@()
$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 = ID nowego atrybutu
$atrybuty = @{
lDAPDDisplayName = 'sshPublicKey';
atrybutId = $oid;
oMSkładnia = 22;
atrybutSkładnia = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Klucz publiczny użytkownika do logowania SSH';
}
New-ADObject -Name sshPublicKey -Type atrybutSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "użytkownik"'
$Schemat użytkownika | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Po dodaniu atrybutu należy ponownie uruchomić Usługi domenowe Active Directory.
Przejdźmy do użytkowników Active Directory. Wygenerujemy parę kluczy do połączenia ssh dowolną dogodną dla Ciebie metodą.
Uruchamiamy PuttyGen, wciskamy przycisk „Generuj” i gorączkowo poruszamy myszą po pustym obszarze.
Po zakończeniu procesu możemy zapisać klucze publiczny i prywatny, przesłać klucz publiczny do atrybutu użytkownika Active Directory i cieszyć się procesem. Jednakże klucz publiczny musi być używany z „Klucz publiczny do wklejenia do pliku autoryzowanych_kluczy OpenSSH:".
Dodaj klucz do atrybutu użytkownika.
Opcja 1 – GUI:
Opcja 2 — PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Zatem aktualnie mamy: użytkownika z wypełnionym atrybutem sshPublicKey, skonfigurowanego klienta Putty do autoryzacji za pomocą kluczy. Pozostaje jeszcze jeden mały punkt: jak zmusić demona sshd do wydobycia potrzebnego nam klucza publicznego z atrybutów użytkownika. Mały skrypt znaleziony w burżuazyjnym Internecie z powodzeniem może sobie z tym poradzić.
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'Ustawiamy uprawnienia na 0500 dla roota.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
W tym przykładzie konto administratora jest używane do powiązania z katalogiem. W warunkach bojowych musi istnieć osobne konto z minimalnym zestawem uprawnień.
Osobiście byłem bardzo zdezorientowany momentem hasła w czystej postaci w skrypcie, pomimo ustawionych praw.
Opcja rozwiązania:
- Hasło zapisuję w osobnym pliku:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Ustawiłem uprawnienia do plików na 0500 dla roota
chmod 0500 /usr/local/etc/secretpass - Zmiana parametrów uruchamiania ldapsearch: parametr -w supertajne hasło Zmieniam to na -y /usr/local/etc/secretpass
Ostatnim akordem dzisiejszego zestawu jest edycja sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
W rezultacie otrzymujemy następującą sekwencję ze skonfigurowaną autoryzacją klucza w kliencie ssh:
- Użytkownik łączy się z serwerem podając swój login.
- Demon sshd za pomocą skryptu wyodrębnia wartość klucza publicznego z atrybutu użytkownika w Active Directory i przeprowadza autoryzację przy użyciu kluczy.
- Demon sssd dodatkowo uwierzytelnia użytkownika na podstawie członkostwa w grupie. Uwaga! Jeśli nie zostanie to skonfigurowane, dostęp do hosta będzie miał każdy użytkownik domeny.
- Kiedy próbujesz wykonać sudo, demon sssd przeszukuje Active Directory w poszukiwaniu ról. Jeśli role są obecne, sprawdzane są atrybuty użytkownika i członkostwo w grupach (jeśli sudoRoles jest skonfigurowane do korzystania z grup użytkowników)
Podsumowanie.
Tym samym klucze przechowywane są w atrybutach użytkownika Active Directory, uprawnieniach sudo - podobnie dostęp do hostów Linux przez konta domenowe odbywa się poprzez sprawdzenie członkostwa w grupie Active Directory.
Ostatnie falowanie batuty dyrygenta – i sala zastyga w pełnej czci ciszy.
Źródła wykorzystane w piśmie:
Źródło: www.habr.com