Skzi zdalne uwierzytelnianie użytkowników linux. CryptoPro JCP w systemie Linux

W tym poście postanowiliśmy porozmawiać o uwierzytelnianiu domeny w systemie Linux przy użyciu kart inteligentnych i tokenów JaCarta PKI USB jako drugiego czynnika uwierzytelniania. Jeśli informacji o uwierzytelnianiu lokalnym poprzez moduł PAM jest całkiem sporo, to kwestia infrastruktury domeny i uwierzytelniania za pomocą biletów Kerberos w Linuksie jest słabo uwzględniona, zwłaszcza w języku rosyjskim. Jak system operacyjny Weźmy Astra Linux i użyjmy przykładu Astra Linux Directory (ALD), aby to pokazać.

Korzyść z takiego rozwiązania jest oczywista - pozwala odmówić autoryzacji hasłem użytkownika, co pozwoli drastycznie zmniejszyć wpływ „czynnika ludzkiego” na bezpieczeństwo systemu. Ponadto zapewni to szereg korzyści wynikających z używania kluczy elektronicznych w systemie operacyjnym po uwierzytelnieniu w domenie.

Małe wprowadzenie do katalogu Astra Linux Directory (ALD) i JaCarta PKI

Domena Katalog Astra Linux (ALD) przeznaczony dla organizacji wspólna przestrzeń użytkowników (domena sieci lokalnej) w systemach zautomatyzowanych.

ALD wykorzystuje technologie LDAP, Kerberos5, Samba/CIFS i zapewnia:

• scentralizowane przechowywanie i zarządzanie kontami użytkowników i grup;
• uwierzytelnianie end-to-end użytkowników w domenie przy użyciu protokołu Kerberos5;
• funkcjonowanie globalnego repozytorium katalogów domowych dostępnych przez Samba/CIFS;
• automatyczne pliki konfiguracyjne UNIX, LDAP, Kerberos, Samba, PAM;
• obsługa zgodności z bazami danych LDAP i Kerberos;
• tworzenie kopii zapasowych baz danych LDAP i Kerberos z możliwością odtwarzania;
• integracja z domeną wchodzącą w skład SZBD dystrybucji, serwery E-mail, serwery WWW, serwery wydruku i nie tylko.

W otoczeniu Katalog Astra Linux (ALD) klucze elektroniczne JaCarta PKI może służyć do dwuetapowego uwierzytelniania użytkownika w domenie ALD i bez haseł. Co więcej, z tym samym klucze elektroniczne możesz wykonywać różne skrypty wewnątrz systemu operacyjnego, po uwierzytelnieniu, takie jak: podpis elektroniczny, przechowywanie kontenerów kluczy, dostęp do zasobów WWW, przekazywanie kluczy w sesji MS Windows. Dostęp do usług VDI, takich jak VmWare czy Citrix.

Proces ustawiania

Przykład strefy demonstracyjnej

• Serwer — Astra Linux Smoleńsk
  • JaCarta IDProtect 6.37;
  • libccid;
  • sztcd;
  • libpcsclite1;
  • krb5-pkinit;
  • libengine-pkcs11-openssl;
  • otwierac.
• Klient - Astra Linux Smoleńsk SE 1.5 4.2.0-23-generic, x86_64, z zainstalowanymi pakietami:
  • JaCarta IDProtect 6.37;
  • libccid;
  • sztcd;
  • libpcsclite1;
  • krb5-pkinit.

Zakłada się, że ALD został już wdrożony, jest co najmniej jeden użytkownik domeny, który może uwierzytelniać się hasłem, czasy klienta i serwera są takie same.

Instalowanie sterowników na serwerze i kliencie

Aby zapewnić pracę z kartą inteligentną JaCarta PKI Zainstaluj następujące pakiety na kliencie i serwerze: libccid, pcscd, libpcsclite1. Po zainstalowaniu tych obowiązkowych pakietów zainstaluj , który można pobrać z oficjalnej strony internetowej „Aladdin R.D.”.

Aby zapewnić pracę z kartą inteligentną podsystemu Kerberos oprócz preinstalowanych pakietów ald/kerberos zainstaluj pakiet krb5-pkinit na kliencie i serwerze.

Aby umożliwić wydawanie kluczy i certyfikatów dla JaCarta PKI na serwerze zainstaluj też pakiety libengine-pkcs11-openssl oraz otwiera.

Instalowanie i konfigurowanie urzędu certyfikacji na serwerze

Jako CA (Kalifornia) będzie użyty OpenSSL.

OpenSSL to pakiet kryptograficzny typu open source do obsługi SSL/TLS. Umożliwia tworzenie kluczy RSA, DH, DSA oraz certyfikatów X.509, podpisywanie ich, generowanie CSR i CRT.

Wszystkie ustawienia w przewodniku dotyczą domeny testowej EXAMPLE.RU. Załóżmy, że serwer i klient należą do domeny PRZYKŁAD.RU, nazwa serwera to kdc, a klient to klient. Podczas konfiguracji użyj nazwy domeny, serwera i klienta. Wykonaj następujące czynności.

1. Utwórz katalog CA za pomocą mkdir /etc/ssl/CA i przejdź do niego. Ten katalog będzie zawierał wygenerowane klucze i certyfikaty.
2. Utwórz klucz i certyfikat CA:
   $ openssl genrsa -out cakey.pem 2048
   $ openssl req -key cakey.pem -new -x509 –dni 365 -out cacert.pem
   W oknie dialogowym podaj wymagane informacje o swoim urzędzie certyfikacji. Wpisz PRZYKŁAD.RU w nazwie Wspólnej.
3. Utwórz klucz i certyfikat KDC:
   $ openssl genrsa -out kdckey.pem 2048
   $ openssl req -new -out kdc.req -key kdckey.pem
   Podaj wymagane informacje o serwerze w oknie dialogowym. Określ kdc w nazwie pospolitej.
4. Ustaw zmienne środowiskowe. Zmienne środowiskowe są ustawiane w ramach sesji i nie są ustawiane dla innych sesji i nie są utrwalane po zamknięciu sesji.
   export REALM=EXAMPLE.RU - Twoja domena
   export CLIENT=kdc - twój serwer
5. Pobierz plik pkinit_extensions -

Zawartość pliku pkinit_extensions(powinien być umieszczony w katalogu, z którego wykonujesz polecenia):

[kdc_cert]
basicConstraints=CA:FALSE
# Oto kilka przykładów użycia nsCertType. Jeśli to jest popełnione
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
#Pkinit EKU
rozszerzone KeyUsage = 1.3.6.1.5.2.3.5
subjectKeyIdentifier=hasz

# Skopiuj szczegóły tematu
issuerAltName=wydawca:kopia
# Dodaj id-pkinit-san (pkinit subjectAlternativeName)
subjectAltName=otherName:1.3.6.1.5.2.2;SEKWENCJA:kdc_princ_name

nazwa_główna = EXP:1, SEKWENCJA:kdc_principal_seq
nazwa_typ = EXP:0, INTEGER:1
nazwa_ciąg = EXP:1, SEKWENCJA:kdc_principals
princ1 = Ciąg ogólny: krbtgt
princ2 = Ciąg Ogólny:$(ENV::REALM)
[certyfikat_klienta]
# Te rozszerzenia są dodawane, gdy "ca" podpisuje żądanie.
basicConstraints=CA:FALSE
keyUsage = digitalSignature, keyEncipherment, keyAgreement
rozszerzone KeyUsage = 1.3.6.1.5.2.3.4
subjectKeyIdentifier=hasz
AuthorityKeyIdentifier=identyfikator klucza,wydawca
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name
# Skopiuj szczegóły tematu
issuerAltName=wydawca:kopia
dziedzina = EXP:0, Ciąg ogólny:$(ENV::REALM)
nazwa_główna = EXP:1, SEKWENCJA: sekwencja_główna
nazwa_typ = EXP:0, INTEGER:1
nazwa_ciąg = EXP:1, SEKWENCJA:główne
princ1 = Ciąg ogólny:$(ENV::KLIENT)

1. Wydaj certyfikat KDC: $ openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert –CAcreateserial –days 365
2. Pliki kdc.pem, kdckey.pem, cacert.pem przenieść do /var/lib/krb5kdc/
3. Utwórz kopię zapasową pliku /etc/krb5kdc/kdc.conf. Edytuj /etc/krb5kdc/kdc.conf dodając następujące wpisy do sekcji: pkinit_identity = PLIK:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem pkinit_anchors = PLIK:/var/lib /krb5kdc /cacert.pem Pierwszy wpis określa klucze i certyfikat serwera, a drugi wpis wskazuje na główny certyfikat urzędu certyfikacji.
4. Aby zaakceptować zmiany, uruchom: /etc/init.d/krb5-admin-server restart /etc/init.d/krb5-kdc restart

Przygotowanie karty inteligentnej. Wydawanie kluczy i certyfikatu użytkownika

Upewnij się, że pakiety są zainstalowane libengine-pkcs11-openssl oraz otwiera. Podłącz urządzenie, które ma być przygotowane.

Zainicjuj urządzenie, ustaw kod PIN użytkownika. Należy pamiętać, że zainicjowanie urządzenia spowoduje usunięcie wszystkich danych z JaCarta PKI poza możliwością odzyskania.

Do inicjalizacji musisz użyć narzędzia PKCS11-narzędzie.

Pkcs11-tool --slot 0 --init-token --so-pin 00000000 --label "JaCarta PKI" --moduł /lib64/libASEP11.so, --slot 0
--init-token– polecenie inicjalizacji tokena;
--tak-pin 00000000
--etykieta "JaCarta PKI"– identyfikator urządzenia;
--moduł /lib64/libASEP11.so

Aby ustawić PIN użytkownika, użyj polecenia: /

Pkcs11-tool --slot 0 --init-pin --so-pin 00000000 --login --pin 11111111 --moduł /lib64/libASEP11.so,

Wygeneruj klucze na urządzeniu, wprowadzając następujące polecenie:

Pkcs11-tool --slot 0 --login --pin 11111111 --keypairgen --key-type rsa:2048 --id 42 --etykieta „klucz test1” --moduł /lib64/libASEP11.so, --slot 0- wskazuje, do którego wirtualnego gniazda jest podłączone urządzenie. Z reguły jest to slot 0, ale możliwe są inne wartości - 1,2 itd .;
--logowanie --pin 11111111
--keypairgen --key-type rsa:2048- wskazuje, że należy wygenerować klucze o długości 2048 bitów;
--id 42- ustawia atrybut CKA_ID klucza. CKA_ID może być dowolnym;
Zapamiętaj tę wartość! Niezbędne są dalsze etapy przygotowania urządzenia do pracy.
--etykieta „klucz test1”- ustawia atrybut CKA_LABEL klucza. Atrybut może być dowolny;
--moduł /lib64/libASEP11.so- określa ścieżkę do biblioteki libASEP11.so. Zainstalowany jako część pakietu idprotectclient, zobacz „Instalowanie sterowników na serwerze i kliencie”.

Wygeneruj żądanie certyfikatu za pomocą narzędzia openssl. Aby to zrobić, wprowadź następujące polecenia:

Musisz ustawić zmienne środowiskowe

$ export REALM=EXAMPLE.RU #Twoja domena
$ export KLIENT=test1 #Twój użytkownik
i wydać użytkownikowi certyfikat.
$ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem –dni 365
Następnie przekoduj otrzymany certyfikat z PEM na DER.
# openssl x509 -in client.pem -out client.cer -inform PEM -outform DER
Zapisz otrzymany certyfikat do tokena.
pkcs11-tool --slot 0 --login --pin 11111111 --write-object client.cer --type "cert" --label "Certyfikat" --id 42 --module /lib/libASEP11.so,
gdzie:
--slot 0- wskazuje, do którego wirtualnego gniazda jest podłączone urządzenie. Z reguły jest to slot 0, ale możliwe są inne wartości - 1,2 itd .;
--logowanie --pin 11111111- wskazuje, że należy zalogować się jako użytkownik z kodem PIN „11111111”. Jeśli Twoja karta ma inny kod PIN użytkownika, wprowadź go;
--write-object ./client.cer- wskazuje, że konieczne jest zarejestrowanie obiektu i drogi do niego;
--wpisz „certyfikat”- wskazuje, że typem pisanego obiektu jest certyfikat;
"cert" --etykieta "Certyfikat"- ustawia atrybut CKA_LABEL certyfikatu. Atrybut może być dowolny;
--identyfikator 42- ustawia atrybut CKA_ID certyfikatu. Należy podać ten sam CKA_ID, co dla kluczy;
--moduł /lib64/libASEP11.so- określa ścieżkę do biblioteki libASEP11.so.

Ustawienie klienta. Kontrola zdrowia

Utwórz katalog na kliencie /etc/krb5/. Kopiuj do /etc/krb5/ Certyfikat CA (cacert.pem) z serwera.

Skonfiguruj kerberos w /etc/krb5.conf. Uzupełnij sekcję następującymi wierszami.

Gdy pojawi się wiersz żądania kodu PIN dla karty, wprowadź go.

Aby sprawdzić, czy bilet Kerberos został pomyślnie pobrany dla użytkownika, wydaj komendę klist. Aby usunąć bilet - kdestroy.

Aby zalogować się do domeny przy użyciu karty inteligentnej, na ekranie logowania systemu operacyjnego, zamiast wprowadzać hasło, wprowadź kod PIN z karty inteligentnej.

To kończy konfigurację. Tak, niestety, sam system nie zmieni ani nie dostosuje okna logowania, aby pasowało do karty inteligentnej, a będzie to standard, ale przy odrobinie tajnego wysiłku można osiągnąć piękny wynik.

Od dłuższego czasu system Windows jest wyposażony w zintegrowane uwierzytelnianie sieciowe i jednokrotne logowanie. Przed Windows 2000 kontrolery domeny Windows NT zapewniały klientom Usługi Windows uwierzytelnianie przy użyciu protokołu NTLM. Chociaż NTLM nie był tak bezpieczny, jak się początkowo wydawało, był bardzo przydatny, ponieważ zapewniał wygodne rozwiązanie problemu konieczności utrzymywania zduplikowanych kont użytkowników na różnych serwerach w sieci.

Począwszy od Windows 2000, Microsoft przeniósł się z NTLM do Active Directory i jego zintegrowanych usług uwierzytelniania Kerberos. Kerberos był znacznie bezpieczniejszy niż NTLM, a także lepiej skalowany. Ponadto Kerberos był już używanym standardem branżowym Systemy Linux i UNIX, który otworzył drzwi do integracji tych platform z Windows.

Uwierzytelnianie Linuksa

Początkowo Linux (oraz działające na nim narzędzia i biblioteki GNU) nie liczył na pojedynczy mechanizm uwierzytelniania. W konsekwencji twórcy aplikacji na Linuksa zwykle opracowują własne schematy uwierzytelniania. Udało im się to osiągnąć albo przez wyszukanie skrótów nazwy użytkownika i hasła w /etc/passwd (plik tekstowy tradycyjnie zawierający dane uwierzytelniające użytkownika Linuksa) albo przez dostarczenie zupełnie innego (i oddzielnego) mechanizmu.

Powstały asortyment mechanizmów uwierzytelniania był niezarządzany. W 1995 roku firma Sun wprowadziła mechanizm zwany Pluggable Authentication Modules (PAM). PAM dostarczył wspólny zestaw uwierzytelniania API, który mógł być używany przez wszystkich programistów aplikacji, a także konfigurowalny przez administratora element serwera, który umożliwiał różne „podłączone” schematy uwierzytelniania. Wykorzystanie interfejsów API PAM do uwierzytelniania oraz interfejsów API Name Server Switch (NSS) do wyszukiwania informacji o użytkownikach pozwoliło twórcom aplikacji na Linuksa pisać mniej kodu, a administratorom Linuksa na zarządzanie i konfigurowanie procesu uwierzytelniania z jednego miejsca.

Większość wydań Linuksa zawierała kilka modułów uwierzytelniania PAM, w tym moduły obsługujące zarówno uwierzytelnianie katalogów LDAP, jak i uwierzytelnianie Kerberos. Moduły te mogą być używane do uwierzytelniania w Active Directory, ale istnieją w tym znaczne ograniczenia, które omówię w dalszej części tego artykułu.

Samba i Winbind

Samba to projekt open source, którego celem jest integracja między środowiskami Windows i Linux. Samba zawiera składniki, które zapewniają komputerom z systemem Linux dostęp do usług plików i drukowania systemu Windows oraz zapewniają usługi oparte na systemie Linux, które naśladują kontrolery domeny systemu Windows NT 4.0. Korzystanie z komponentów klienta Samba, Komputery z systemem Linux może korzystać z usług uwierzytelniania Windows dostarczanych przez kontrolery domeny Windows NT i Active Directory.

Szczególnie interesująca nas jest część Samby zwana Winbind. Winbind to demon ("usługa" w terminologii Windows), który działa na klientach Samby i działa jako proxy do komunikacji między PAM i NSS działającym na komputerze z systemem Linux z jednej strony, a Active Directory działającym na kontrolerze domeny z drugiej. W szczególności Winbind używa protokołu Kerberos do uwierzytelniania w Active Directory i LDAP w celu uzyskania informacji o użytkownikach i grupach. Winbind zapewnia również Dodatkowe usługi, takie jak możliwość wykrywania kontrolera domeny przy użyciu algorytmu podobnego do DCLOCATOR w usłudze Active Directory oraz możliwość resetowania haseł usługi Active Directory przez skontaktowanie się z kontrolerem domeny za pomocą RPC.

Winbind rozwiązuje szereg problemów, które pozostają przy użyciu protokołu Kerberos z PAM. W szczególności, zamiast na stałe kodować kontroler domeny do uwierzytelniania PAM, Winbind wybiera kontroler domeny, wyszukując rekordy lokalizatora DNS, podobnie do modułu Microsoft DC LOCATOR.

Trzy strategie uwierzytelniania

Biorąc pod uwagę dostępność LDAP, Kerberos i Winbind na komputerach z systemem Linux, istnieją trzy różne strategie implementacji, które można zastosować, aby umożliwić komputerowi z systemem Linux korzystanie z usługi Active Directory do uwierzytelniania.

Korzystanie z uwierzytelniania LDAP Najprostszym, ale najmniej zadowalającym sposobem wykorzystania Active Directory do uwierzytelniania jest skonfigurowanie PAM do korzystania z uwierzytelniania LDAP, jak pokazano w Ryż. jeden. Chociaż Active Directory jest usługą LDAPv3, Klienci Windows użyj protokołu Kerberos do uwierzytelniania (z NTLM jako rezerwy) zamiast LDAP.

W przypadku uwierzytelniania LDAP (nazywanego powiązaniem LDAP) nazwa użytkownika i hasło są przesyłane przez sieć w postaci zwykłego tekstu. Jest to niebezpieczne i niedopuszczalne w większości celów.

Ryc. 1. Uwierzytelnianie Active Directory przy użyciu LDAP

Jedynym sposobem na złagodzenie tego ryzyka związanego z przekazywaniem otwartych poświadczeń jest zaszyfrowanie kanału komunikacji klient-Active Directory przy użyciu czegoś takiego jak SSL. Jest to zdecydowanie możliwe, ale nakłada dodatkowe obciążenie związane z zarządzaniem certyfikatami SSL zarówno na maszynę kontrolera domeny, jak i maszynę z systemem Linux. Ponadto korzystanie z modułu LDAP PAM nie obsługuje zmiany haseł resetowania lub wygasłych haseł.

Korzystanie z LDAP i Kerberos Inną strategią korzystania z uwierzytelniania Active Directory dla systemu Linux jest skonfigurowanie PAM do korzystania z uwierzytelniania Kerberos i NSS do korzystania z protokołu LDAP do wyszukiwania informacji o użytkownikach i grupach, jak pokazano w Ryż. 2. Ten schemat ma tę zaletę, że jest stosunkowo bezpieczny i wykorzystuje „wbudowane” funkcje systemu Linux. Jednak nie używa rekordów lokalizacji usługi DNS (SRV) opublikowanych przez kontrolery domeny usługi Active Directory, co wymusza sprawdzanie określonego zestawu kontrolerów domeny w celu uwierzytelnienia względem nich. Nie zapewnia również szczególnie intuicyjnego sposobu zarządzania wygasającymi hasłami Active Directory ani, do niedawna, odpowiednich wyszukiwań członków grupy.

Ryc. 2. Uwierzytelnianie Active Directory przy użyciu LDAP i Kerberos

Korzystanie z Winbind Trzecim sposobem wykorzystania uwierzytelniania Active Directory dla systemu Linux jest skonfigurowanie PAM i NSS do wykonywania wywołań demona Winbind. Winbind przetłumaczy różne zapytania PAM i NSS na odpowiednie wywołania Active Directory za pomocą LDAP, Kerberos lub RPC, w zależności od tego, co jest najbardziej odpowiednie. Na Ryż. 3 podano dobry przykład tej strategii.

Rys 3. Uwierzytelnianie Active Directory przy użyciu Winbind

Nasz plan wdrożenia

Ulepszona integracja z Active Directory sprawiła, że ​​wybrałem Winbind na Red Hat Enterprise Linux 5 (RHEL5) do mojego projektu integracji Linux-Active Directory. RHEL5 to aktualna wersja komercyjnego wydania systemu Red Hat Linux, która jest dość popularna w centrach danych przedsiębiorstw.

Aby RHEL5 mógł uwierzytelnić się za pośrednictwem Active Directory, zasadniczo wymagane jest wykonanie następujących pięciu oddzielnych kroków:

1. Znajdź i pobierz odpowiedni pakiet Samba i inne zależne komponenty.
2. Zbuduj Sambę.
3. Zainstaluj i skonfiguruj Sambę.
4. Skonfiguruj Linuksa, w szczególności PAM i NSS.
5. Skonfiguruj Active Directory.

W następnych kilku sekcjach tego artykułu opisano te kroki bardziej szczegółowo.

Znalezienie odpowiednich programów

Jedną z największych różnic między Linuksem a Windowsem jest to, że Linux składa się z małego jądra systemu operacyjnego i ogromnej kolekcji oddzielnie pobieranych i instalowanych komponentów. Umożliwia to tworzenie bardzo starannie dobranych dystrybucji Linuksa, które są optymalne do określonych zadań, ale również bardzo utrudnia konfigurację i zarządzanie serwerem. Różne dystrybucje radzą sobie z tym na różne sposoby. Red Hat (i jego niekomercyjna siostra Fedora) używają Menedżera pakietów Red Hat (RPM) do instalowania i zarządzania tymi komponentami.

Komponenty Linuksa dla Red Hata występują w dwóch formach. Pliki RPM zawierają pliki binarne, które zostały wstępnie skompilowane i zbudowane dla określonej kombinacji wersji komponentów, wydania systemu Linux i architektury procesora. Możesz więc pobrać i zainstalować na przykład wersję 1.3.8-5 Common UNIX Printing System (CUPS) zbudowanego dla Fedory w wersji 10 działającej na procesorze o architekturze Intel x86. Biorąc pod uwagę obecność kilkunastu różne architektury Procesor, ponad 100 wydań Linuksa oraz tysiące pakietów i wersji, widać, że jest niesamowita ilość binarnych pakietów RPM do wyboru.

Z drugiej strony pliki źródłowe RPM zawierają prawdziwe źródło dla tego pakietu. Oczekuje się, że użytkownik pobierze i zainstaluje pliki źródłowe, skonfiguruje opcje kompilacji, a następnie sam skompiluje i zlinkuje pliki binarne. Pomysł zbudowania własnego systemu operacyjnego jest onieśmielający dla profesjonalisty Windows przyzwyczajonego do instalowania tego, co Microsoft udostępnia na płycie CD. Instalacja systemu Windows, ale menedżer pakietów sprawia, że ​​proces jest stosunkowo bezbolesny i zaskakująco niezawodny. Grupa Samba w szaleńczym tempie publikuje aktualizacje i łatki bezpieczeństwa; tylko w lipcu i sierpniu 2008 roku pojawiły się cztery wydania Samby 3.2, zawierające łącznie ponad 100 poprawek błędów i poprawek bezpieczeństwa. Do tego projektu pobrałem pliki źródłowe najnowszej stabilnej wersji Samby w wersji 3.0.31.

Dlaczego pobrałem kod źródłowy Samby zamiast wstępnie skompilowanego zestawu plików binarnych? Na początku oczywiście próbowałem zrobić pierwszy. Ale po wielu godzinach pracy z debuggerem odkryłem, że pobrane przeze mnie pliki binarne nie zostały zbudowane we właściwy sposób, aby obsługiwać uwierzytelnianie Active Directory. W szczególności kod obsługujący mapowanie identyfikatorów Linux w Active Directory był wyłączony w domyślnych kompilacjach, więc musiałem przebudować Sambę z odpowiednimi opcjami kompilacji. Poniżej szczegółowo omówię kwestię dopasowania identyfikatorów.

Mimo że sam Linux jest małym jądrem, wersja Red Hat Enterprise jest preinstalowana z wieloma pakietami. Zwykle znacznie ułatwia to życie, umożliwiając rozpoczęcie pracy z kompletnym i działającym systemem operacyjnym, ale preinstalowane pakiety czasami powodują konflikt z programami, które mają zostać zainstalowane później.

Nie włączyłem Samby do mojej instalacji Red Hata (Samba jest zwykle instalowana domyślnie), ponieważ musiałem użyć nowszej wersji. Jednak więcej nowa wersja Samba wymaga nowych wersji kilku innych bibliotek i narzędzi, które zostały już zainstalowane. Problemy związane z tym uzależnieniem są irytujące, ale można je łatwo rozwiązać za pomocą RPM.

Istnieje wiele stron internetowych, które udostępniają binarne pakiety RPM. Ten, którego użyłem (po prostu dlatego, że znalazłem go pierwszy) nazywa się PBONE i znajduje się pod adresem rpm.pbone.net. Ma wygodny sposób znajdowania pakietów i zawiera wszystkie pliki binarne, które były wymagane dla mojej architektury procesora (i386) i edycji systemu operacyjnego (Red Hat Enterprise Linux 5/Fedora 7 i 8).

Musiałem pobrać i zaktualizować pakiety wymienione na Ryż. 4 budować i instalować Ostatnia wersja Samba 3.0 (istnieje jeszcze nowsze drzewo wersji 3.2, którego nie próbowałem). Zauważ, że wszystkie te pakiety są przeznaczone dla wydania Fedora Core (fc). Dystrybucja Red Hat jest oparta na tym samym kodzie źródłowym co Fedora i jest z nią w pełni kompatybilna. Pakiety zbudowane dla Fedory Core 7 i nowszych będą działać bez zmian w RHEL5. Umieść pobrane pliki RPM w katalogu /usr/src/redhat/RPMS.

Ryż. 4. Pakiety wymagane do zbudowania i zainstalowania Samby 3.0.31

Budowanie Samby

Pierwszym krokiem do zbudowania Samby jest pobranie odpowiedniego pakietu źródłowego RPM. Pobrałem źródłowy pakiet RPM Samby 3.0.31 ze strony PBONE. Następnie umieść pobrany plik źródłowy RPM w /usr/src/redhat/SRPMS; jest to standardowy katalog dla źródłowych pakietów RPM podczas procesu budowania.

Otwórz sesję terminala ("okno wiersza polecenia" w terminologii Windows) i przejdź do folderu SRPMS. Gdy to zrobisz, zainstaluj pakiet źródłowy za pomocą polecenia, jak pokazano w Ryż. 5.

Ryż. 5. Instalowanie pakietu RPM źródła Samba

Jeśli pojawi się ostrzeżenie o błędzie „user mockbuild nie istnieje-korzystający z roota", nie martw się. Ten błąd wskazuje, że nie są zainstalowane narzędzia do pozorowanego montażu. Proces kompilacji będzie działał bez nich.

Następnie przejdź do katalogu /usr/src/redhat/SPECS i edytuj plik samba.spec zawierający opcje budowania Samby. Znajdź wiersz zaczynający się od „CFLAGS=” i upewnij się, że istnieje opcja „--with-shared-modules=idmap_ad,idmap_rid”. Ta opcja zapewnia, że ​​proces kompilacji zawiera kod, który poprawnie konwertuje unikalne identyfikatory systemu Linux (UID) do usługi Active Directory. Na Ryż. 6 biorąc pod uwagę tę opcję.

Ryż. 6. Opcja budowania ze współdzielonymi modułami

Następnie może być konieczne zaktualizowanie niektórych bibliotek na komputerze, aby poprawnie zbudować i zainstalować Sambę; zależy to od tego, które wersje bibliotek są już zainstalowane. W moim przypadku musiałem zainstalować pakiety wymienione na Ryż. 4 za pomocą polecenia rpm -install; jednak w niektórych przypadkach musiałem użyć opcji --force, aby przezwyciężyć niektóre problemy z zależnościami.

Aby zbudować Sambę, przejdź do katalogu /usr/src/redhat i uruchom rpmbuild -bb SPECS/samba.spec, jak pokazano w Ryż. 7. Ta procedura pozostawi nowy plik RPM samba-3.0.31-0.i386 w katalogu /usr/src/redhat/RPMS. Zainstalujemy ten plik RPM później w projekcie.

Ryż. 7. Tworzenie pliku binarnego Samba RPM

Konfiguracja sieci w Linuksie

Aby uwierzytelnić się w usłudze Active Directory, komputer z systemem Linux musi mieć możliwość skontaktowania się z kontrolerem domeny. Aby tak się stało, należy skonfigurować trzy ustawienia sieciowe.

Po pierwsze, ważne jest, aby upewnić się, że interfejs sieciowy na komputerze z Linuksem jest poprawnie skonfigurowany, albo za pomocą DHCP, albo przypisując mu odpowiedni adres IP i maskę sieci za pomocą polecenia ifconfig. W przypadku RHEL5 możesz skonfigurować sieć, wybierając ją (Sieć) z System | Administracja (System | Administracja), jak pokazano w Ryż. osiem.

Ryc. 8. Konfiguracja sieci

Następnie upewnij się, że usługa rozpoznawania nazw DNS dla komputera z systemem Linux jest ustawiona na używanie tego samego serwera nazw DNS, którego używają kontrolery domeny; w większości przypadków jest to kontroler domeny w domenie, do której chcesz dołączyć komputer z systemem Linux, zakładając, że używasz zintegrowanego DNS z usługą Active Directory. Przelicznik DNS jest konfigurowany na karcie DNS tego samego narzędzia do konfiguracji sieci, które zostało użyte do skonfigurowania sieci, jak pokazano na Ryż. 9.

Ryc. 9. Instalowanie podstawowego resolwera DNS

Na koniec, po wykonaniu tych kroków, musisz ustawić nazwę komputera z systemem Linux, aby odzwierciedlała jego nazwę w domenie. Chociaż tę nazwę można ustawić za pomocą aplikacji do konfiguracji sieci, nie zawsze działa to poprawnie.

Zamiast tego zmodyfikuj plik /etc/hosts i dodaj wpis pod wpisem localhost.localdomain w formularzu <полное доменное имя> <имя компьютера>. (Przykład: "10.7.5.2 rhel5.linuxauth.local linuxauth".) Należy zauważyć, że jeśli nie zostanie to zrobione, po dołączeniu maszyny z systemem Linux do domeny w katalogu zostanie utworzony niewłaściwy obiekt maszyny.

Konfiguracja synchronizacji czasu w systemie Linux

Protokół Kerberos opiera się na systemach uwierzytelniania wyposażonych w zegary o wystarczająco wysokiej dokładności taktowania. Domyślnie usługa Active Directory dopuszcza maksymalną rozbieżność czasu wynoszącą pięć minut. Aby zapewnić, że systemy Linux i zegary systemowe DC pozostaną w tej wartości, systemy Linux muszą być skonfigurowane do korzystania z usługi protokołu DC NTP.

Następnie na serwerze Linux uruchom narzędzie Data i godzina z System | Administracja i wybierz zakładkę Protokół NTP. Zaznacz pole wyboru Włącz protokół czasu sieciowego i dodaj adres IP kontrolera domeny, którego chcesz używać jako źródła czasu sieciowego. Należy zauważyć, że zazwyczaj powinien to być kontroler domeny w domenie, która pełni rolę FSMO personifikującego podstawowego kontrolera domeny (PDC). Na Ryż. 10 Oto przykład konfigurowania sieciowego źródła czasu dla systemu Linux.

Rysunek 10. Ustawianie protokołu NTP

Konfiguracja PAM i NSS

PAM i NSS umożliwiają połączenie aplikacji linuksowej, takiej jak desktop i Winbind. Podobnie jak wiele usług linuksowych, PAM i NSS są konfigurowane za pomocą plików tekstowych. Najpierw przyjrzymy się konfiguracji PAM.

PAM udostępnia cztery funkcje związane z uwierzytelnianiem aplikacjom, które z niego korzystają. Uwierzytelniający umożliwia aplikacji określenie, kto z niej korzysta. Narzędzie Konta zapewnia funkcje zarządzania kontem, które nie są bezpośrednio związane z uwierzytelnianiem, takie jak ograniczanie czasu logowania. Narzędzie do zarządzania hasłami zapewnia mechanizmy żądania i zarządzania hasłami. Narzędzie sesji wykonuje specyficzne dla użytkownika zadania instalacji i dezinstalacji aplikacji, takie jak rejestrowanie lub tworzenie plików w określonej kategorii użytkownika.

Pliki konfiguracyjne PAM Red Hata są przechowywane w katalogu /etc/pam.d, który będzie zawierał plik tekstowy dla każdej aplikacji, która używa PAM do uwierzytelniania. Na przykład plik /etc/pam.d/gdm zawiera informacje o konfiguracji PAM dla Gnome Desktop Manager (GDM), domyślnego środowiska okienkowego Red Hata. Każdy plik konfiguracyjny PAM zawiera kilka wierszy, z których każdy definiuje pewien aspekt procesu uwierzytelniania PAM. Na Ryż. jedenaście pokazuje zawartość pliku konfiguracyjnego PAM dla GDM.

Ryż. jedenaście. Plik konfiguracyjny pamięci RAM dla Gnome Desktop Manager

Każdy wpis w pliku konfiguracyjnym PAM ma postać<группа управления> <элемент управления> <модуль> <параметры>, gdzie<группа управления>odpowiada obiektowi, którego dotyczy wpis ustawienia: uwierzytelnianie, konta, hasła lub sesje. Kontroluj słowa kluczowe opisane na Ryż. 12 poinformuj PAM, jak przetworzyć wpis konfiguracyjny. Trzecia kolumna pliku zawiera nazwę współdzielonej biblioteki PAM w katalogu /lib/ security. Biblioteki współdzielone zawierają dynamicznie ładowany kod wykonywalny, podobny do biblioteki DLL w systemie Windows. Dodatkowe terminy po nazwie modułu to parametry przekazywane przez moduł PAM do biblioteki współdzielonej.

Ryż. 12. Słowa kluczowe kontrolne PAM

Możesz zauważyć, że każda grupa zarządzania ma wiele wpisów. PAM przetwarza wpisy w kolejności, wywołując nazwany moduł. Następnie moduł zwraca sukces lub niepowodzenie, a PAM podejmuje działanie w oparciu o słowo kluczowe control.

Możesz zauważyć, że plik konfiguracyjny PAM dla GDM posiada autoryzację systemową dla wszystkich grup zarządzania. W ten sposób PAM ustawia domyślne zachowanie uwierzytelniania dla GDM. Modyfikując autoryzację systemową, możesz zmodyfikować to zachowanie dla wszystkich aplikacji, które mają plik autoryzacji systemowej w swoich ustawieniach PAM. Domyślny plik uwierzytelniania systemowego jest pokazany w Ryż. trzynaście.

Ryż. trzynaście. Plik systemowy modułu PAM-auth

Moduł Name Resolution Block Switch (NSS) ukrywa przed twórcą aplikacji określone informacje o magazynie danych systemu, podobnie jak PAM ukrywa szczegóły uwierzytelniania. NSS umożliwia administratorowi określenie sposobu przechowywania baz danych systemu. W szczególności administrator może określić sposób przechowywania informacji o nazwie użytkownika i haśle. Ponieważ chcemy, aby aplikacje wyszukiwały informacje o użytkownikach w Active Directory przy użyciu Winbind, musimy zmienić ustawienie NSS, aby to pokazać.

Red Hat zawiera małe narzędzie graficzne do konfigurowania PAM i NSS o nazwie system-config-authentication. Zajmuje się większością (ale nie wszystkimi) zmianami, które należy wprowadzić w plikach system-auth i nss.conf.

Uruchom aplikację system-config-authentication i powinieneś zobaczyć okno dialogowe podobne do pokazanego w Ryż. 14. Zaznacz pole Winbind zarówno na karcie Informacje o użytkowniku, konfiguruje plik nss.conf, jak i na karcie Uwierzytelnianie, modyfikuje plik system-auth.

Ryż. 14. okno dialogowe konfiguracji systemu-uwierzytelniania

Kliknij przycisk Konfiguruj Winbind i okno dialogowe pokazane w Ryż. 15. Wprowadź nazwę domeny, w której chcesz uwierzytelniać użytkowników w polu Domena Winbind i wybierz „deklaracje” jako model zabezpieczeń. Wprowadź nazwę domeny DNS domeny Active Directory w polu Winbind ADS Realm. W polu Kontrolery domeny Winbind wprowadź nazwę kontrolera domeny, z którym chcesz się uwierzytelniać w tym systemie Linux, lub gwiazdkę wskazującą, że Winbind powinien wybrać kontroler domeny podczas wysyłania zapytań do rekordów DNS SRV.

Ryż. 15. Dostosowywanie okna dialogowego Winbind

Wybierz odpowiedni domyślny interpreter poleceń, który powinni mieć użytkownicy usługi Active Directory; w tym przypadku wybrałem bash (Bourne-again Shell). Na tym etapie nie próbuj używać przycisku „Dołącz do domeny”. Komputer zostanie później dołączony do domeny.

Jeszcze jedna dodatkowa zmiana musi zostać dokonana w /etc/pam.d/system-auth po jego zmodyfikowaniu do obsługi Winbind. Gdy użytkownik systemu Linux loguje się, system wymaga, aby użytkownik miał katalog domowy. Katalog domowy zawiera wiele ustawień specyficznych dla użytkownika i elementów dostosowywania, podobnie jak rejestr systemu Windows. Problem polega na tym, że ponieważ użytkownicy są tworzeni w Active Directory, Linux nie utworzy automatycznie katalogu domowego użytkownika. Na szczęście PAM można skonfigurować tak, aby robił to w ramach konfiguracji sesji.

Otwórz plik /etc/pam.d/system-auth, a następnie przewiń w dół i wklej wiersz „session Optional map_mkhomedir.so skel=/etc/skel umask=0644” przed ostatnią linią w sekcji sesji (patrz poniżej). Ryż. szesnaście). Ta linia nakazuje PAM utworzenie katalogu domowego dla użytkownika, jeśli jeszcze taki nie istnieje. Użyje /etc/skel jako szablonu szkieletu i przypisze maskę uprawnień 0644 (odczyt/zapis dla właściciela, odczyt dla grupy podstawowej i odczyt dla wszystkich innych) do nowego folderu.

Ryż. szesnaście. Tworzenie katalogu domowego dla użytkowników

Instalowanie i konfigurowanie Samba

Aby zainstalować nowo utworzone binaria Samby, przejdź do katalogu /usr/src/redhat/RPMS. Wszystkie pliki RPM utworzone przez polecenie rpmbuild pojawią się w tym katalogu. Pamiętaj, że Samba zawiera pliki binarne, które umożliwiają Klient Linux dostęp do udziału plików Windows (lub Samby), a także do kodu, który pozwala systemowi Linux działać jako serwer plików Windows, serwer wydruku Windows i kontroler domeny w stylu Windows NT 4.0.

Aby umożliwić Linuksowi uwierzytelnianie w Active Directory, wszystko to nie jest potrzebne; wystarczą zwykłe pliki Samby i pliki binarne klienta Samby. Dla naszej wygody pliki te są podzielone na dwa pliki RPM: samba-client-3.0.31-0.i386.rpm i samba-common-3.0.31-0.i386.rpm. Zainstaluj pliki RPM za pomocą polecenia rpm --install. Oto przykład: rpm --install samba-common-3.0.31-0.i386.rpm. (Zauważ, że przed wykonaniem tej czynności musisz zainstalować plik RPM -common).

Po zainstalowaniu plików binarnych klienta Samby należy zmodyfikować domyślną konfigurację Samby, aby upewnić się, że Winbind prawidłowo obsługuje uwierzytelnianie Active Directory. Wszystkie informacje dotyczące konfiguracji Samby (zarówno klienta, jak i serwera) można znaleźć w pliku tekstowym smb.conf, który domyślnie znajduje się w katalogu /etc/samba. Smb.conf może zawierać ogromną liczbę opcji konfiguracyjnych, a pełne zestawienie jego zawartości wykracza poza zakres tego artykułu. Więcej informacji na temat smb.conf można znaleźć na stronie samba.org oraz w pomocy systemu Linux.

Pierwszym krokiem w konfiguracji Winbind jest użycie Active Directory do uwierzytelniania. Model bezpieczeństwa w smb.conf musi być ustawiony na "deklaracje". Narzędzie system-config-authentication powinno już to ustawić samo, ale nigdy nie zaszkodzi sprawdzić. Edytuj plik smb.conf i znajdź sekcję o nazwie Opcje członka domeny. Znajdź wiersz zaczynający się od „security” i upewnij się, że brzmi „security=ads”. Następny krok konfiguracji określa, w jaki sposób Winbind mapuje zasady zabezpieczeń systemu Windows, takie jak użytkownicy i grupy, na tożsamości w systemie Linux, a to wymaga nieco więcej wyjaśnień.

Problem z dopasowaniem identyfikatora

Jest jeden duży problem z uwierzytelnianiem użytkowników Active Directory Linux, o którym do tej pory nie wspomniałem - problem unikalnych identyfikatorów (UID) dla użytkowników i grup. Wewnętrznie ani Linux, ani Windows nie odnoszą się do użytkowników ich prawdziwymi imionami, używając zamiast tego unikalnego identyfikatora wewnętrznego. System Windows używa identyfikatorów zabezpieczeń (SID), które są strukturą o zmiennej długości, która jednoznacznie identyfikuje każdego użytkownika w domenie systemu Windows. Identyfikator SID zawiera również unikalny identyfikator domeny, dzięki czemu system Windows może rozróżniać użytkowników w różnych domenach.

Schemat Linuksa jest znacznie prostszy. Każdy użytkownik komputera z systemem Linux ma identyfikator UID, który jest po prostu 32-bitową liczbą całkowitą. Ale zakres UID jest ograniczony do samego komputera. Nie ma gwarancji, że użytkownik z UID 436 na jednym komputerze z systemem Linux jest identyczny z użytkownikiem z UID 436 na innym komputerze z systemem Linux. W konsekwencji użytkownik musi łączyć się z każdym komputerem, do którego chce uzyskać dostęp, co jest sytuacją niepożądaną.

Administratorzy sieci w systemie Linux zwykle rozwiązują ten problem, zapewniając uwierzytelnianie sieciowe przy użyciu systemu informacji sieciowej (NIS) lub udostępnionego katalogu LDAP. System uwierzytelniania sieciowego zapewnia użytkownikowi identyfikator UID, a wszystkie komputery z systemem Linux korzystające z tego systemu będą używać tych samych identyfikatorów użytkowników i grup. W tej sytuacji korzystam z Active Directory, aby zapewnić unikalne identyfikatory użytkowników i grup.

Aby rozwiązać ten problem, używam dwóch strategii. Pierwszą (i najbardziej oczywistą) strategią jest stworzenie UID dla każdego użytkownika i grupy oraz przechowywanie tego UID z odpowiednim obiektem w Active Directory. Kiedy jest używany, kiedy Winbind uwierzytelnia użytkownika, mogę spojrzeć na UID użytkownika i dostarczyć go do Linuksa jako wewnętrzny ID użytkownika. Winbind odnosi się do tego schematu jako do mapowania identyfikatorów Active Directory (lub idmap_ad). Na Ryż. 17 przedstawia proces mapowania tożsamości usługi Active Directory.

Rysunek 17. Proces mapowania identyfikatora Active Directory

Jedyną wadą mapowania tożsamości usługi Active Directory jest to, że musi zapewniać mechanizm, aby każdy użytkownik i grupa posiadały tożsamość i były unikatowe w lesie. Więcej informacji można znaleźć na pasku bocznym „Konfigurowanie usługi Active Directory dla mapowania identyfikatorów usługi Active Directory”.

Na szczęście istnieje inna strategia dopasowywania identyfikatorów, która wiąże się ze znacznie mniejszymi kosztami administracyjnymi. Przypomnij sobie, że identyfikator SID systemu Windows jednoznacznie identyfikuje użytkownika w domenie, a także samą domenę. Część identyfikatora SID, która jednoznacznie identyfikuje użytkownika w domenie, nazywana jest identyfikatorem względnym (RID) i jest w rzeczywistości 32-bitową liczbą całkowitą. Tak więc Winbind może po prostu wyodrębnić identyfikator RID z identyfikatora SID, gdy użytkownik się loguje, a następnie użyć identyfikatora RID jako unikalnego wewnętrznego UID. Winbind odnosi się do tej strategii jako mapowania identyfikatora RID lub idmap_rid. Na Ryż. osiemnaście pokazuje, jak faktycznie działa mapowanie RID.

Ryż. osiemnaście. Mapowanie RID

Mapowanie RID ma tę zaletę, że nie stanowi narzutu administracyjnego, ale nie można go używać w środowisku wielodomenowym ze względu na możliwość, że użytkownicy w wielu domenach mają tę samą wartość RID. Ale jeśli masz jedną domenę Active Directory, mapowanie RID jest właściwym wyborem.

Aby skonfigurować zasady mapowania identyfikatorów w Winbind, ponownie edytuj plik /etc/samba/smb.conf i dodaj wiersz „idmap backend = ad”, aby użyć strategii mapowania Active Directory, lub „idmap backend = rid”, aby użyć identyfikatora RID strategia mapowania. Upewnij się, że w pliku nie ma innych wierszy wskazujących na pasującą strategię.

Istnieje wiele innych opcji konfiguracyjnych, które należy dodać do pliku smb.conf dla Winbind. Nawet jeśli PAM jest ustawiony na tworzenie katalogu domowego dla każdego użytkownika podczas logowania, Winbind musi zostać poinformowany, jaka to nazwa. Robimy to, dodając wiersz "template homedir = /home/%U" do smb.conf (patrz poniżej). Ryż. dziewiętnaście). To mówi Winbindowi, że katalogiem domowym każdego użytkownika uwierzytelnionego w Active Directory będzie /home/<имя пользователя>. Nie zapomnij najpierw utworzyć katalogu /home.

Ryż. dziewiętnaście. Określanie nazwy katalogu domowego

Dołącz do domeny i zaloguj się

Teraz, gdy sieć, PAM, NSS i Samba Winbind są skonfigurowane poprawnie, nadszedł czas, aby dołączyć maszynę z Linuksem do domeny. Można to zrobić za pomocą polecenia sieciowe Programy Samby. W wierszu interpretera poleceń uruchom „net ads join -U<имя администратора>". Zastępować<имя администратора>nazwa konta, która ma wystarczające uprawnienia do przyłączania komputerów do domeny.

Polecenie net poprosi o hasło użytkownika. Jeśli wszystko pójdzie dobrze, dołączy do właściwego komputera w domenie. Do zlokalizowania utworzonego konta komputera można użyć przystawki Użytkownicy i komputery usługi Active Directory.

Stan powiązania można przetestować za pomocą narzędzia testowego Winbind, wbinfo. Jeśli uruchomisz wbinfo -t, zostanie przetestowana relacja zaufania między komputerem a domeną. wbinfo -u wyświetli listę wszystkich użytkowników w domenie, a wbinfo -g wyświetli wszystkie grupy.

Jeśli komputer z systemem Linux zostanie pomyślnie dołączony do domeny, następnym krokiem jest próba zalogowania się przy użyciu konta użytkownika i hasła Active Directory. Wyloguj się z komputera z systemem Linux i zaloguj się przy użyciu nazwy użytkownika Active Directory. Jeśli wszystko działa poprawnie, to powinna być możliwość zalogowania.

Konfigurowanie Active Directory dla procesu mapowania ID Active Directory

Te informacje dotyczą tylko osób korzystających z mapowania tożsamości usługi Active Directory. Ci, którzy zdecydują się na użycie mapowania RID, mogą bezpiecznie zignorować ten panel.

Zanim będziesz mógł zalogować się do serwera Red Hat przy użyciu konta Active Directory, musisz wprowadzić pewne zmiany w samej Active Directory. Po pierwsze, schemat Active Directory musi zostać zaktualizowany o atrybuty, których Winbind używa do przechowywania informacji o użytkownikach. W przypadku uruchomienia w systemie Windows Server 2003 R2 schemat jest gotowy do użycia. W przypadku, gdy jest ich więcej wczesna wersja schemat Active Directory, będzie musiał zostać rozszerzony za pomocą pakietu Microsoft Services for UNIX (SFU).

Więcej informacji można znaleźć na stronie Usługi dla systemu UNIX w witrynie TechNet. SFU zawiera również dodatkową stronę właściwości dla użytkowników usługi Active Directory oraz przystawkę Microsoft Computers Management Console (MMC) do zarządzania informacjami o modyfikatorach indywidualnych i grupowych wymaganych przez system Linux.

Po prawidłowym skonfigurowaniu schematu należy podać identyfikatory systemu Linux dla wszystkich użytkowników (i grup, których są członkami), którzy mogą logować się do komputera z systemem Linux. Oznacza to, że musisz zdefiniować wartości atrybutów uidNumber i gidNumber dla użytkowników i grup, które mogą logować się na maszynę z Linuksem. Należy jednak pamiętać o kilku wymaganiach dotyczących tych atrybutów:

1. Linux wymaga UID dla każdego użytkownika, który się uwierzytelnia. Ponieważ musimy zarządzać informacjami o użytkownikach w Active Directory, każde konto użytkownika, które będzie logować się do komputera z systemem Linux, musi mieć unikalny atrybut uidNumber. Konkretna wartość użyta dla uidNumber nie jest istotna, ale musi być unikalna dla wszystkich użytkowników, którzy mogą zalogować się do komputera z systemem Linux.
2. Każdy użytkownik Linuksa musi również mieć domyślny identyfikator grupy, więc każdy użytkownik Active Directory, który loguje się do komputera z Linuksem, wymaga również wartości atrybutu gidNumber. Ta wartość nie musi być unikalna wśród użytkowników, ale musi jednoznacznie identyfikować grupę.
3. Każda grupa w Active Directory musi mieć unikalną wartość atrybutu gidNumber. Ściśle mówiąc, grupy mogą nie mieć wartości atrybutu gidNumber, ale podczas uwierzytelniania użytkownika Winbind oczekuje, że każda grupa, do której należy użytkownik, będzie miała unikalną wartość gidNumber. Prawdopodobnie dużo łatwiej jest po prostu upewnić się, że każda grupa ma unikalna wartość numer gid.
4. Winbind oczekuje, że każdy użytkownik znaleziony w Active Directory będzie członkiem grupy Użytkownicy domeny, więc oczekuje również, że grupa Użytkownicy domeny będzie miała wartości dla swojego atrybutu gidNumber.

A jeśli to nie zadziała?

Skonfigurowanie komputera z systemem Linux do uwierzytelniania w Active Directory i przez Winbind nie jest prostym projektem. Jest wiele rzeczy do poprawienia i wiele rzeczy, które mogą pójść nie tak. Fakt, że każda wersja Linuksa czy Samby ma nieco inne możliwości, nie ułatwia tego zadania. Istnieje jednak wiele źródeł zawierających informacje o tym, co się dzieje.

Pierwszym z nich jest plik dziennika systemu Linux, znajdujący się w /var/log/messages. Samba będzie rejestrować w tym pliku istotne zdarzenia, takie jak brakujące pliki lub zła konfiguracja. Oprócz pliku dziennika systemowego Samba i Winbind mają własne pliki dziennika. Można je znaleźć w /var/log/samba i dostarczą użytkownikowi dodatkowych informacji.

Możesz zwiększyć szczegółowość (i długość) komunikatów dziennika generowanych przez Winbind, modyfikując jego skrypt startowy, aby ustawić poziom debugowania. Edytuj skrypt powłoki poleceń /etc/init.d/winbind i dodaj "-d 5" do polecenia winbind. Zwiększy to poziom debugowania do 5 (prawidłowe wartości to od 1 do 10), co spowoduje, że winbind będzie generował więcej pełnych komunikatów o błędach.

Jeśli Winbind zdoła komunikować się z kontrolerem domeny, możesz przechwytywać pakiety sieciowe za pomocą narzędzia takiego jak Netmon 3.1. Pozwala to dokładnie przeanalizować, co Winbind próbuje zrobić. Możesz także sprawdzić dziennik zabezpieczeń systemu Windows na kontrolerze domeny, który będzie rejestrował próby uwierzytelnienia.

Teraz, kiedy już działa, co mamy?

Jeśli wszystko działa sprawnie, możliwe jest logowanie się do systemów Linux przy użyciu poświadczeń obsługiwanych przez Active Directory. Jest to ogromny postęp w stosunku do lokalnego zarządzania tożsamością na komputerze z systemem Linux lub korzystania z niezabezpieczonego systemu, takiego jak NIS. Pozwala to na scentralizowanie zarządzania użytkownikami w jednym magazynie tożsamości: Active Directory.

Ale brakuje tu kilku rzeczy, które mogą sprawić, że to rozwiązanie będzie naprawdę przydatne. Po pierwsze, uzyskanie pomoc techniczna tutaj jest to kwestia szczęścia. Wiele organizacji zajmujących się Linuksem nie wie zbyt wiele o Active Directory, a wsparcie, jakie możesz uzyskać od społeczności Linuksa, zależy wyłącznie od tego, kto przeczytał Twój post i jakie są jego dzisiejsze odczucia.

Ponadto pakiet Samba nie zapewnia narzędzi do przenoszenia ani wdrażania. Jeśli masz istniejące konta systemu Linux, które mają powiązane identyfikatory użytkowników i uprawnienia, musisz ręcznie upewnić się, że zachowują one swoje identyfikatory UID podczas migracji do Active Directory.

Wreszcie jedna z najważniejszych aplikacji Active Directory, Group Policy, nie jest dostępna w Sambie, chociaż prace są w toku. Chociaż system Linux można dołączyć do usługi Active Directory za pomocą Samby, nie można nim sterować za pomocą zasad grupy.

Rozwiązania innych firm

Uwierzytelnianie komputerów z systemem Linux za pomocą Active Directory jest oczywiście dobrą rzeczą, ale tworzenie własnego rozwiązania za pomocą Samby Winbind jest żmudne, jeśli nie tylko koszmarem. Czytelnicy mogą pomyśleć, że jakiś pomysłowy dostawca oprogramowania powinien wymyślić łatwiejsze w użyciu rozwiązanie i mieliby rację.

Czterech komercyjnych dostawców oprogramowania opracowało łatwe w instalacji i użytkowaniu wersje tego, co przedstawiłem w tym artykule. Zapewniają kod i narzędzia do przenoszenia dla prawie wszystkich popularnych wersji systemów Linux, UNIX i Apple Macintosh, a także obsługę zarządzania komputerami z systemem Linux przy użyciu zasad grupy.

Te cztery firmy to: Centrify, Likewise Software, Quest Software i Symark. Wszyscy czterej dostawcy oferują podobne funkcje, w tym zarządzanie zasadami grupy w wielu różnych wersjach systemu Linux. Likewise Software niedawno udostępniło swoją implementację o nazwie Likewise Open, chociaż jej komponent zasad grupy pozostaje produktem komercyjnym. Podobnie Open będzie dostępny dla kilku głównych wydań Linuksa. (Pozwól, że zdradzę ci sekret: kiedy pisałem ten artykuł, moja firma, NetPro, została przejęta przez Quest Software.)

Czy ma sens budowanie własnego systemu uwierzytelniania przy użyciu Samby i Winbind, gdy dostępne są opcje komercyjne? Jeśli budżet nie obejmuje pieniędzy na programy integracyjne, korzystanie z Samby z jej otwartym oprogramowaniem ma tę zaletę, że jest bezpłatne. Dostajesz również cały kod źródłowy, co może być kuszącą korzyścią. Ale przenoszenie istniejących maszyn z systemem Linux i ich istniejących identyfikatorów UID to drażliwy problem.

Z drugiej strony, jeśli chcesz zaoszczędzić czas na implementacji i instalacji, lub jeśli masz istniejące maszyny z systemem Linux, które wymagają migracji, lub jeśli potrzebujesz fachowej odpowiedzi na swoje pytanie, warto przyjrzeć się rozwiązaniom komercyjnym. Jeśli potrzebujesz zarządzać zasadami grupy, nie ma dla nich alternatywy.

Jednak każde rozwiązanie, które integruje uwierzytelnianie systemu Linux z usługą Active Directory, zmniejsza nakład pracy związany z zarządzaniem wieloma kontami użytkowników, poprawia bezpieczeństwo systemu i zapewnia pojedynczy magazyn tożsamości do zarządzania i inspekcji. I to są wystarczająco dobre powody, aby spróbować.

Uwierzytelnianie dwuskładnikowe (2FA) to metoda uwierzytelniania, która wymaga kilku informacji, aby zalogować się na konto lub urządzenie. Oprócz kombinacji nazwy użytkownika/hasła funkcja 2FA wymaga od użytkownika wprowadzenia dodatkowych informacji, takich jak hasło jednorazowe (OTP, takie jak sześciocyfrowy kod weryfikacyjny).

Ogólnie 2FA wymaga od użytkownika wprowadzenia różnych rodzajów informacji:

• Coś, co użytkownik wie (np. hasło)
• Coś, co posiada użytkownik (na przykład kod potwierdzający wygenerowany przez specjalną aplikację - uwierzytelniacz).

2FA to podzbiór uwierzytelniania wieloskładnikowego (MFA). Metoda MFA oprócz tego, co użytkownik wie i posiada, wymaga czegoś, czym jest. Są to dane biometryczne: odcisk palca lub rozpoznawanie głosu itp.

2FA pomaga zabezpieczyć proces uwierzytelniania dla określonej usługi lub urządzenia: nawet jeśli hasło zostało złamane, atakujący będzie potrzebował również kodu zabezpieczającego, a to wymaga dostępu do urządzenia użytkownika, na którym znajduje się aplikacja uwierzytelniająca. Z tego powodu wiele usług online oferuje opcję włączenia 2FA dla kont użytkowników w celu zwiększenia bezpieczeństwa kont na poziomie uwierzytelniania.

W tym samouczku dowiesz się, jak skonfigurować 2FA za pomocą modułu Google PAM dla użytkownika innego niż root na Ubuntu 18.04. Ponieważ konfigurujesz 2FA dla użytkownika innego niż root, w przypadku blokady nadal będziesz mógł uzyskać dostęp do komputera z konta root. Instrukcje zawarte w podręczniku są na tyle ogólne, że można je zastosować zarówno do serwerów, jak i instalacji stacjonarnych, zarówno lokalnych, jak i zdalnych.

Wymagania

• Serwer lub środowisko graficzne Ubuntu 18.04. Serwer Ubuntu 18.04 musi być skonfigurowany z .
• Uwierzytelniacz zainstalowany na urządzeniu mobilnym (na przykład Google Authenticator lub Authy). Dzięki niemu zeskanujesz kody QR bezpieczeństwa.

Krok 1: Instalacja modułu Google PAM

Aby skonfigurować 2FA na Ubuntu 18.04, musisz zainstalować moduł Google PAM dla systemu Linux. Pluggable Authentication Module (PAM) to mechanizm uwierzytelniania używany przez system Linux. Moduł Google PAM umożliwi użytkownikowi przeprowadzanie uwierzytelniania 2FA przy użyciu wygenerowanych przez Google kodów OTP.

Pierwsze logowanie jako użytkownik sudo, który utworzyłeś podczas ustawienie początkowe serwery:

cisza [e-mail chroniony] _IP serwera

Zaktualizuj indeks pakietów Ubuntu, aby uzyskać najnowszy token uwierzytelniający:

aktualizacja sudo apt-get

Po aktualizacji repozytoriów zainstaluj najnowszą wersję modułu PAM:

sudo apt-get install libpam-google-authenticator

Jest to bardzo mały pakiet bez żadnych zależności, więc instalacja zajmie kilka sekund. W następnej sekcji ustawimy 2FA dla użytkownika sudo.

Krok 2: Konfigurowanie uwierzytelniania dwuskładnikowego

Po zainstalowaniu modułu PAM uruchom go, aby wygenerować kod QR dla zalogowanego użytkownika. Spowoduje to wygenerowanie kodu, ale środowisko Ubuntu nie będzie wymagało 2FA, dopóki go nie włączysz.

Uruchom polecenie google-authenticator, aby uruchomić i skonfigurować moduł PAM:

google-uwierzytelniający

Polecenie zada ci kilka pytań konfiguracyjnych. Najpierw zapyta, czy chcesz, aby tokeny były ograniczone czasowo. Tokeny uwierzytelniania czasowego wygasają po określonym czasie (domyślnie 30 sekund w większości systemów). Tokeny czasowe są bezpieczniejsze niż tokeny czasowe, a większość implementacji 2FA ich używa. Tutaj możesz wybrać dowolną opcję, ale zalecamy wybranie Tak i używanie ograniczonych czasowo tokenów uwierzytelniających:

Czy chcesz, aby tokeny uwierzytelniające były oparte na czasie (t/n) y

Odpowiadając y na to pytanie, zobaczysz w konsoli kilka linii danych wyjściowych:

• QR Code: jest to kod, który należy zeskanować za pomocą aplikacji uwierzytelniającej. Po zeskanowaniu aplikacja utworzy nowy OTP co 30 sekund.
• Klucz tajny: Jest to alternatywny sposób konfigurowania aplikacji uwierzytelniającej. Jeśli używasz aplikacji, która nie obsługuje skanowania kodów QR, możesz wprowadzić tajny klucz, aby skonfigurować uwierzytelnianie.
• Kod weryfikacyjny: jest to pierwszy sześciocyfrowy kod generowany przez ten konkretny kod QR.
• Awaryjne kody zdrapki. są to tokeny jednorazowe (zwane również kodami rezerwowymi), umożliwiają przejście uwierzytelniania 2FA w przypadku utraty urządzenia uwierzytelniającego. Przechowuj te kody w bezpiecznym miejscu, aby uniknąć zawieszenia konta.

Po skonfigurowaniu aplikacji uwierzytelniającej i zapisaniu kody zapasowe w bezpiecznym miejscu program zapyta, czy chcesz zaktualizować plik konfiguracyjny. Jeśli wybierzesz n, będziesz musiał ponownie uruchomić program instalacyjny. Wpisz y, aby zapisać zmiany i kontynuować:

Czy chcesz, żebym zaktualizował Twój plik „~/.google_authenticator” (t/n) y

Następnie program zapyta, czy chcesz uniemożliwić użycie kodów uwierzytelniających więcej niż jeden raz. Domyślnie każdego kodu można użyć tylko raz, nawet jeśli nie minęło 30 sekund od jego utworzenia. Jest to najbezpieczniejszy wybór, ponieważ zapobiega atakom polegającym na powtórce ze strony atakującego, któremu w jakiś sposób udało się uzyskać używany kod weryfikacyjny. Z tego powodu lepiej jest zabronić używania kodów więcej niż jeden raz. Odpowiedz y, aby zapobiec wielokrotnemu użyciu tego samego tokena:

Czy chcesz uniemożliwić wielokrotne użycie tego samego uwierzytelnienia?
znak? Ogranicza to do jednego logowania co 30 sekund, ale wzrasta
Twoje szanse na zauważenie lub nawet zapobieżenie atakom typu man-in-the-middle (t/n) y

Następnie musisz określić, czy chcesz, aby tokeny uwierzytelniania zostały zaakceptowane jakiś czas po ich wygaśnięciu normalny termin działania. Kody są bardzo czasochłonne i dlatego mogą nie działać, jeśli Twoje urządzenia nie są zsynchronizowane. Ta opcja pozwala obejść ten problem, wydłużając domyślny czas ważności kodów weryfikacyjnych, dzięki czemu kody uwierzytelniające i tak są akceptowane (nawet jeśli Twoje urządzenia są chwilowo niezsynchronizowane). Najlepiej upewnić się, że czas na wszystkich urządzeniach jest zsynchronizowany, ponieważ odpowiedź „tak” nieznacznie obniży bezpieczeństwo systemu. Odpowiedz n na to pytanie, aby uchronić token przed wygaśnięciem:

Domyślnie tokeny działają przez 30 sekund i w celu zrekompensowania
możliwe przesunięcie czasowe między klientem a serwerem, dopuszczamy dodatkowe
token przed i po bieżącej godzinie. Jeśli masz problemy z biednymi
synchronizacja czasu, możesz zwiększyć okno z domyślnego
rozmiar od 1:30min do około 4min. Czy chcesz to zrobić (t/n) n

Ostatnie pytanie dotyczy tego, czy chcesz włączyć limit liczby prób logowania. Uniemożliwi to użytkownikowi wykonanie więcej niż trzech nieudanych prób logowania w ciągu 30 sekund, co zwiększy bezpieczeństwo systemu. Włącz to ograniczenie, odpowiadając na y:

Jeśli komputer, do którego się logujesz, nie jest odporny na brute-force
prób logowania, możesz włączyć ograniczanie szybkości dla modułu uwierzytelniania.
Domyślnie ogranicza to atakujących do nie więcej niż 3 prób logowania co 30 sekund.
Czy chcesz włączyć ograniczanie szybkości (t/n) y

Skonfigurowałeś i wygenerowałeś kody 2FA za pomocą modułu PAM. Teraz musisz włączyć 2FA w swoim środowisku.

Krok 3: Aktywacja 2FA w Ubuntu

Moduł Google PAM generuje teraz kody 2FA dla Twojego użytkownika, ale Ubuntu jeszcze nie wie, że musi używać kodów w procesie uwierzytelniania. W tym momencie musisz zaktualizować konfigurację Ubuntu, aby oprócz podstawowego uwierzytelniania włączyć obsługę tokenów 2FA.

Są tu dwa sposoby:

1. Możesz wymagać uwierzytelniania dwuskładnikowego za każdym razem, gdy użytkownik się loguje i za każdym razem, gdy użytkownik żąda praw sudo.
2. Możesz wymagać tylko 2FA podczas logowania, wtedy tylko hasło użytkownika będzie wymagane przy pytaniu o prawa sudo.

Pierwsza opcja byłaby idealna dla ogólnego środowiska, w którym pożądane jest zabezpieczenie wszelkich działań wymagających uprawnień sudo. Drugie podejście jest bardziej praktyczne w przypadku lokalnego środowiska graficznego, w którym jesteś jedynym użytkownikiem systemu.

Notatka Odp.: Jeśli włączysz 2FA na zdalnym komputerze, do którego uzyskujesz dostęp przez SSH, przed kontynuowaniem będziesz musiał wykonać kroki 2 i 3 instrukcji. Pozostałe kroki w tym samouczku dotyczą wszystkich instalacji Ubuntu, ale środowiska zdalne wymagają dodatkowej konfiguracji, aby usługa SSH była świadoma 2FA.

Jeśli nie używasz SSH, aby uzyskać dostęp do instalacji Ubuntu, możesz przejść do pozostałych kroków w tym samouczku.

Monit 2FA przy logowaniu i podniesieniu sudo

Aby system używał funkcji 2FA podczas logowania i kolejnych żądań eskalacji uprawnień, musisz edytować plik /etc/pam.d/common-auth, dodając linię na końcu istniejącego pliku.

Plik common-auth dotyczy wszystkich mechanizmów uwierzytelniania w systemie, niezależnie od używanego środowiska. Dotyczy to również żądań uwierzytelnienia, które pojawiają się po zalogowaniu użytkownika, na przykład w przypadku monitu o uprawnienia sudo podczas instalowania nowego pakietu z terminala.

Otwórz plik:

sudo nano /etc/pam.d/common-auth

Dodaj na końcu pliku:

...
# a oto więcej modułów na pakiet (blok "Dodatkowe")
sesja wymagana pam_unix.so

Ta linia umożliwia systemowi uwierzytelniania Ubuntu obsługę 2FA podczas logowania za pomocą modułu Google PAM. Opcja nullok pozwala istniejącym użytkownikom na zalogowanie się, nawet jeśli nie skonfigurowali uwierzytelniania 2FA dla swojego konta. Innymi słowy, użytkownicy, którzy skonfigurowali 2FA, będą musieli wprowadzić kod uwierzytelniający przy następnym logowaniu, podczas gdy użytkownicy, którzy nie uruchomili polecenia google-authenticator, będą mogli logować się za pomocą swoich standardowych danych uwierzytelniających, dopóki nie skonfigurują 2FA.

Zapisz i zamknij plik.

Monit 2FA tylko po zalogowaniu

Jeśli chcesz, aby żądanie 2FA było wymagane tylko podczas logowania do środowiska graficznego, musisz edytować plik konfiguracyjny używanego menedżera pulpitu. Nazwa pliku konfiguracyjnego jest zwykle taka sama jak nazwa środowiska graficznego. Na przykład plik konfiguracyjny dla gdm (domyślne środowisko Ubuntu od Ubuntu 16.04) to /etc/pam.d/gdm.

W przypadku serwera bezgłowego (który jest wirtualny serwer), zamiast tego musisz edytować plik /etc/pam.d/common-session. Otwórz odpowiedni plik w zależności od środowiska:

sudo nano /etc/pam.d/common-session

Dodaj podświetlone linie na końcu pliku:

#
# /etc/pam.d/common-session - moduły związane z sesją wspólne dla wszystkich usług
#
...
# # a tu więcej modułów na pakiet (blok "Dodatkowe")
sesja wymagana pam_unix.so
sesja opcjonalna pam_systemd.so
# koniec konfiguracji pam-auth-update
wymagane uwierzytelnienie pam_google_authenticator.so nullok

Ubuntu będzie teraz wymagało 2FA, gdy użytkownik łączy się z systemem za pomocą wiersza poleceń (lokalnie lub zdalnie przez SSH), ale nie dotyczy to uruchamiania poleceń za pomocą sudo.

Skonfigurowałeś Ubuntu do obsługi 2FA. Teraz nadszedł czas na przetestowanie konfiguracji i upewnienie się, że po zalogowaniu się do systemu Ubuntu zostaniesz poproszony o podanie kodu zabezpieczającego.

Krok 4: Testowanie uwierzytelniania dwuskładnikowego

Wcześniej skonfigurowałeś 2FA do generowania kodów co 30 sekund. Teraz spróbuj zalogować się do swojego środowiska Ubuntu.

Najpierw wyloguj się i zaloguj ponownie do swojego środowiska Ubuntu:

cisza [e-mail chroniony] _IP serwera

Jeśli korzystasz z uwierzytelniania opartego na hasłach, zostaniesz poproszony o podanie hasła użytkownika:

Notatka: Jeśli używasz uwierzytelniania za pomocą certyfikatu na zdalnym serwerze, nie zostaniesz poproszony o podanie hasła. Klucz zostanie automatycznie przekazany i zaakceptowany. Wystarczy wpisać kod potwierdzający.

Wprowadź hasło, po czym zostaniesz poproszony o wprowadzenie kodu 2FA:

Kod weryfikacyjny:

Następnie zostaniesz zalogowany:

[e-mail chroniony] _ip_serwera: ~#

Jeśli funkcja 2FA była włączona tylko do logowania, nie będziesz już musiał wprowadzać kodów weryfikacyjnych 2FA do czasu zakończenia sesji lub ręcznego wylogowania.

Jeśli włączyłeś 2FA za pomocą pliku common-auth, zostaniesz poproszony o podanie go również przy każdym żądaniu uprawnień sudo:

[e-mail chroniony] _ip_serwera: ~# sudo -s
hasło sudo dla 8host:
Kod weryfikacyjny:
[e-mail chroniony] _IP serwera:

Upewniłeś się, że konfiguracja funkcji 2FA działa prawidłowo. Jeśli coś poszło nie tak i system nie wyświetlił monitu o kody weryfikacyjne, wróć do trzeciej sekcji przewodnika i upewnij się, że edytowałeś poprawny plik uwierzytelniający Ubuntu.

5: Zapobieganie blokowaniu 2FA

W przypadku utraty lub zniszczenia urządzenia mobilnego ważne jest podanie metod Zarezerwuj kopię aby odzyskać dostęp do konta z włączonym 2FA. Gdy konfigurujesz 2FA po raz pierwszy, masz kilka opcji odzyskania dostępu po zablokowaniu:

• Przechowuj kopię zapasową tajnych kodów konfiguracyjnych w bezpiecznym miejscu. Możesz to zrobić ręcznie, ale niektóre aplikacje uwierzytelniające, takie jak Authy, udostępniają funkcje tworzenia kopii zapasowych kodu.
• Zapisz kody odzyskiwania w bezpiecznym miejscu poza środowiskiem obsługującym 2FA, do którego można uzyskać dostęp w razie potrzeby.

Jeśli z jakiegoś powodu nie masz dostępu do opcji tworzenia kopii zapasowych, możesz spróbować przywrócić dostęp do lokalne środowisko lub na zdalny serwer z obsługą 2FA w inny sposób.

Krok 6: Przywracanie dostępu do środowiska lokalnego (opcjonalnie)

Jeśli masz fizyczny dostęp do komputera, możesz uruchomić system w trybie odzyskiwania, aby wyłączyć 2FA. Tryb odzyskiwania jest typem docelowym (podobnym do poziomu pracy) w systemie Linux, który jest używany do wykonywania zadań administracyjnych. Będziesz musiał edytować niektóre ustawienia w GRUB, aby przejść do trybu odzyskiwania.

Aby uzyskać dostęp do GRUB, najpierw uruchom ponownie komputer:

Kiedy pojawi się menu GRUB, upewnij się, że pozycja Ubuntu jest podświetlona. Jest to domyślna nazwa instalacji 18.04, ale może być inna, jeśli zmienisz ją ręcznie po instalacji.

Następnie naciśnij klawisz e na klawiaturze, aby edytować konfigurację GRUB przed uruchomieniem systemu.

Przejdź na koniec pliku, który się pojawi i znajdź wiersz, który zaczyna się od linux i kończy na $vt_handoff. Przejdź do końca tej linii i dodaj systemd.unit=rescue.target. Upewnij się, że zostawiłeś spację między $vt_handoff i systemd.unit=rescue.target. Umożliwi to uruchomienie komputera Ubuntu w trybie odzyskiwania.

Po wprowadzeniu zmian zapisz plik za pomocą skrótu klawiszowego Ctrl + X. Twój komputer uruchomi się ponownie i będziesz w wiersz poleceń. Naciśnij klawisz Enter, aby przejść do trybu odzyskiwania.

W wierszu poleceń otwórz plik konfiguracyjny Google Authenticator znajdujący się w katalogu domowym zablokowanego użytkownika.

nano /home/8host/.google-authenticator

Pierwszy wiersz w tym pliku to klucz prywatny użytkownika, który jest używany do konfiguracji uwierzytelniania.

Teraz masz dwie opcje:

1. Możesz skopiować klucz prywatny i skonfigurować uwierzytelnianie.
2. Jeśli chcesz zacząć z czystym kontem, możesz całkowicie usunąć plik ~/.google-authenticator, aby wyłączyć 2FA dla tego użytkownika. Po ponownym zalogowaniu się będziesz mógł ponownie skonfigurować 2FA i uzyskać nowy tajny klucz.

W każdym razie możesz przywrócić system po zablokowaniu 2FA w środowisku lokalnym za pomocą programu ładującego GRUB. Następnie wyjaśnimy, jak przywrócić dostęp do zablokowanego środowiska zdalnego.

Krok 7: Przywracanie dostępu do usuniętego środowiska (opcjonalnie)

Jeśli twoje konto sudoer jest zablokowane w środowisku zdalnym, możesz tymczasowo wyłączyć lub ponownie skonfigurować 2FA przy użyciu użytkownika root.

Zaloguj się jako użytkownik root:

cisza [e-mail chroniony] _IP serwera

Po zalogowaniu otwórz plik Ustawienia Google Authenticator, który znajduje się w katalogu domowym zablokowanego użytkownika:

sudo nano /home/8host/.google_authenticator

Pierwszy wiersz w tym pliku to klucz prywatny użytkownika, którego potrzebujesz, aby skonfigurować uwierzytelnianie.

Teraz masz dwie ścieżki:

1. Jeśli chcesz skonfigurować nowe lub wymazane urządzenie, możesz użyć tajnego klucza, aby ponownie skonfigurować aplikację uwierzytelniającą.
2. Jeśli chcesz zacząć od nowa, możesz całkowicie usunąć plik /home/8host/.google_authenticator, aby wyłączyć 2FA dla tego użytkownika. Po zalogowaniu się jako użytkownik sudo będziesz mógł ponownie skonfigurować 2FA i uzyskać nowy klucz prywatny.

Z każdą z tych opcji będziesz mógł odzyskać od przypadkowego bloku 2FA za pomocą konta root.

Wniosek

W tym samouczku konfigurujesz 2FA na komputerze z systemem Ubuntu 18.04. Uwierzytelnianie dwuskładnikowe zapewnia dodatkową warstwę bezpieczeństwa konta i systemu. Oprócz standardowych danych logowania, aby się zalogować, musisz również wprowadzić dodatkowy kod weryfikacyjny. Uniemożliwia to nieautoryzowany dostęp do Twojego konta, nawet jeśli atakującemu uda się uzyskać Twoje dane uwierzytelniające.

Jeśli jesteś administratorem Linuksa i chcesz jak najlepiej zabezpieczyć swoje serwery i komputery stacjonarne, prawdopodobnie zastanawiałeś się nad użyciem uwierzytelniania dwuskładnikowego. Ogólnie rzecz biorąc, zdecydowanie zaleca się skonfigurowanie go przez wszystkich, ponieważ uwierzytelnianie dwuskładnikowe znacznie utrudnia atakującym uzyskanie dostępu do twoich komputerów.

Linux umożliwia skonfigurowanie komputera tak, aby nie można było zalogować się do konsoli, pulpitu lub przez Secure Shell bez dwuskładnikowego kodu uwierzytelniającego powiązanego z tym komputerem. Rozważ cały proces konfiguracji dla System Ubuntu Serwer 16.04.

Wstęp

Przed rozpoczęciem należy pamiętać, że po skonfigurowaniu uwierzytelniania dwuskładnikowego nie będzie można uzyskać dostępu do komputera bez kodów wygenerowanych przez osoby trzecie. Za każdym razem, gdy chcesz się zalogować, będziesz potrzebować swojego smartfona lub kodów awaryjnych, które możesz ustawić po drodze.

Potrzebny nam będzie serwer Linux lub desktop. Upewnij się, że system jest aktualny, a Twoje dane mają kopię zapasową na wypadek nieprzewidzianych okoliczności. Do tworzenia kodów dwuskładnikowych użyjemy aplikacja strony trzeciej, takich jak Authy lub Google Authenticator. Warunkowo będziemy używać Google Authenticator, który należy najpierw zainstalować.

Instalacja

Zaloguj się do systemu i wykonaj następujące kroki:

1. Otwórz okno terminala.
2. Uruchom polecenie: sudo apt install libpam-google-authenticator.
3. Wpisz hasło sudo i naciśnij Enter.
4. Jeśli pojawi się monit o potwierdzenie, wpisz „y” i naciśnij klawisz Enter.
5. Poczekaj na zakończenie instalacji.

Teraz nadszedł czas, aby skonfigurować komputer do uwierzytelniania dwuskładnikowego.

Konfiguracja

Wróć do okna terminala i wprowadź polecenie: sudo nano /etc/pam.d/common-auth. Dodaj następujący wiersz na końcu pliku:

Zapisz i zamknij ten plik.

Teraz musimy skonfigurować Google Authenticator dla każdego użytkownika, który musi mieć dostęp do systemu. Aby to zrobić, wróć do okna terminala i w imieniu użytkownika, któremu planujesz przyznać dostęp, uruchom polecenie google-authenticator. Tutaj musisz odpowiedzieć na kilka pytań.

Pierwsze pytanie brzmi: „Czy chcesz, aby tokeny uwierzytelniania były oparte na czasie (t/n)”. Odpowiedz "y", otrzymasz kod QR. Otwórz aplikację dwuskładnikową na smartfonie, dodaj konto i zeskanuj ten kod QR.

Rysunek 1. Otrzymany kod QR

Po dodaniu kodu pozostaje jeszcze kilka pytań, na które należy odpowiedzieć:

• Czy chcesz, abym zaktualizował Twój plik „/home/jlwallen/.google_authenticator” (t/n) — Czy chcesz zaktualizować swój plik /home/jlwallen/.google_authenticator;
• Czy chcesz uniemożliwić wielokrotne użycie tego samego tokena uwierzytelniania (t/n)? - Czy chcesz wyłączyć możliwość wielokrotnego używania tego samego tokena? To ustawienie pozwala tylko na jedno logowanie co 30 sekund. Włączenie tej opcji zwiększa szanse na wykrycie lub nawet zapobieżenie atakowi typu man-in-the-middle.
• Ponieważ domyślna wartość to 30 sekund, a czas serwera i klienta może się nieznacznie różnić, możliwe jest użycie dodatkowego tokena. Dlatego jeśli masz problemy z synchronizacją, możesz wydłużyć czas okna do około 4 minut. Czy chcesz to zrobić? - Czy chcesz to zrobić (t / n).
• Jeśli masz jakiekolwiek wątpliwości co do ochrony swojego komputera przed atakami typu brute-force, możesz aktywować ograniczenie prędkości dla modułu uwierzytelniania. Domyślnie nie więcej niż 3 próby logowania co 30 sekund. Czy chcesz włączyć ograniczenie prędkości? - Czy chcesz włączyć ograniczanie szybkości (t/n)

Odpowiedz tak na każde pytanie, wpisując „y” i naciskając Enter.

Konfiguracja SSH

Następnym krokiem jest skonfigurowanie SSH do pracy z uwierzytelnianiem dwuskładnikowym. Jeśli pominiesz ten krok, nie będziesz mógł zalogować się przez SSH.

Najpierw musisz włączyć moduł PAM. W tym celu wpisujemy polecenie: sudo nano /etc/pam.d/sshd. Po otwarciu pliku dodaj następujący wiersz na końcu pliku:

wymagane uwierzytelnienie pam_google_authenticator.so nullok

Zapisz ten plik, a następnie uruchom polecenie: sudo nano /etc/ssh/sshd_config. W tym pliku znajdujemy:

WyzwanieOdpowiedź Numer uwierzytelnienia

I zmień na:

WyzwanieOdpowiedźUwierzytelnianie tak

Zapisz ten plik i uruchom ponownie sshd - sudo systemctl restart sshd.

Zaloguj sie

Przed wylogowaniem zdecydowanie zalecamy otwarcie nowego okna terminala i próbę zalogowania się przez SSH. Jeśli to się nie powiedzie, powtórz wszystkie powyższe kroki, upewniając się, że niczego nie przegapiłeś. Po pomyślnym zalogowaniu się przez SSH możesz wylogować się z sesji i zalogować ponownie.

wnioski