To jest całkiem przydatna rzecz, szczególnie w 2 przypadkach: mamy wdrażane vCenter i chcemy mieć zaufane wszystkie certyfikaty lub wdrażamy SSL deep inspection. Do tego niektórzy używają Firefoxa i tego nie jesteśmy w stanie przeskoczyć, więc pozostaje nam spróbować wymusić ustawienia przez GPO. Takich ustawień nie ma domyślnie w GPO, ale możemy wykorzystać pliki ADMX, które nam dodają specjalne ustawienia w przeglądarkach. Do Firefoxa plik ADMX znajduje się na stronie getadmx.com i to wykorzystamy. Klonujemy repo, w którym są te ustawienia, otwieramy katalog SYSVOL na naszym kontrolerze domeny (pod adresem //domena.local/SYSVOL lub //kontroler-domeny/SYSVOL, np. //serba.local/SYSVOL lub //dc1.serba.local/SYSVOL), w nim otwieramy folder o nazwie naszej domeny (w moim przypadku serba.local), w nim tworzymy folder PolicyDefinitions i wklejamy tam folder o nazwie języka + pliki ADMX, które znajdują się w folderze. Z faktu, że nie ma języka polskiego – kopiuję folder en oraz pliki *.admx.
Folder PolicyDefinitions istnieje także w C:/Windows/PolicyDefinitions. Takie tworzenie folderu w SYSVOL dla definicji polityk GPO jest określane jako Central Store. Poza samymi zmienionymi politykami powinniśmy skopiować wszystko, co jest we wspomnianym folderze systemowym do //serba.local/SYSVOL/serba.local/PolicyDefinitions. Dzięki temu wszystkie opcje w GPO będą trzymane w jednym miejscu, co jest istotne w przypadku posiadania wielu kontrolerów domeny. Dlatego też nie polecam wrzucania 3rd party plików ADMX do lokalnego folderu – w przyszłości jeśli będzie się miało drugi kontroler domeny to ten nie będzie wiedział w ogóle co znaczą te polityki i one mogą nam nie działać.
Następnie w GPO tworzymy nowy obiekt (nazwałem go firefox use local ca store), następnie rozwinąłem w Konfiguracja komputera > Zasady > Szablony administracyjne: definicje zasad (pliki ADMX) pobrane z komputera lokalnego > Mozilla > Firefox > Certificates i włączamy opcję Import Enterprise Roots.
Po tym wystarczy podłączyć taką politykę i wymusić aktualizację zasad grupy:
Po aktywowaniu, jak sama polityka wskazuje zmiany są stosowane nawet jeśli przeglądarka była zainstalowana po wprowadzeniu polityki, ponadto użytkownik nie może zmienić wskazanego ustawienia:
Po raz kolejny będziemy starać się zintegrować logowanie do środowiska vSphere po to, by móc się logować za pomocą kont z Active Directory. Dzięki temu po raz kolejny ograniczamy hasło, które musimy pamiętać. Fakt, można korzystać z menedżera haseł i przechowywałbym w nim hasło do kont lokalnych (np. w przypadku ESXi do konta root, w przypadku vCenter do konta [email protected] (chodzi o domyślne konto administracyjne vCenter, oczywiście zawsze można zmienić przy instalacji nazwę domeny, po prostu ta jest domyślna i często jest w środowiskach produkcyjnych pomimo wszystko).
Integracja SSO z VMware ESXi 7.0
Ogólnie integracja nie różni się w żaden sposób od wersji 6.5 i 6.7 – na początku należy mieć prawidłowo skonfigurowane serwery DNS:
By ustawić je, należy przejść do Networking > TCP/IP stacks, kliknąć na Default TCP/IP stack i wybrać Edit settings.
Zaznaczamy opcję Manually configure the settings for this TCP/IP stack i poniżej ustalamy opcje:
Host name – definiujemy tutaj nazwę hosta ESXi, w moim przypadku vhost1,
Domain name – tutaj wskazujemy domenę, do której ma należeć host, w moim przypadku serba.local. To jest po to, by móc określać FQDN hosta, czyli w tym przypadku vhost1.serba.local,
Primary DNS server – tutaj wstawiamy adres pierwszorzędnego kontrolera domeny,
Secondary DNS server – jeśli mamy drugi kontroler domeny – wstawiamy tutaj.
Search domains – tutaj dodałem serba.local, ta funkcja polega na tym, że jeśli na przykład chcemy się połączyć do serwera dc1 bez podania FQDNa w pełnej formie czyli host + domena to nasz host sam spróbuje dopisać domenę z search domains, czyli będzie wykonana próba połączenia do dc1.serba.local.
Zanim podłączymy hosta do domeny warto zwrócić uwagę na jeden szczegół w ustawieniach zaawansowanych ESXi – po dodaniu do domeny host sprawdza, czy w AD istnieje grupa o nazwie, która jest zdefiniowana w zmiennej Config.HostAgent.plugins.hostsvc.esxAdminsGroup w ustawieniach Manage > System > Advanced Settings. Domyślna wartość to ESX Admins, co oznacza, przy logowaniu do serwera ESXi ten będzie sprawdzał czy taka grupa istnieje oraz czy użytkownik, który się loguje znajduje się w tej grupie (przy czym działa też możliwość dodawania grup jako członków i dziedziczenie obiektów). Zawsze można ją zmienić na Administratorzy domeny lub Domain Admins (jeśli mamy anglojęzyczny Windows Server na którym postawiliśmy pierwszy kontroler domeny), dzięki czemu nie trzeba ustawiać w żaden sposób dodatkowych grup i od razu wszyscy admini w domenie mają możliwość logowania swoimi kontami.
Poniżej przykład rozwiązania kwestii domyślnej grupy, do której można jak wspomniałem dodać adminów domeny (jeśli chcemy zostawić wspomniane ustawienie z wartością domyślną):
Następnie przechodzimy do Manage > Security & Users, wybieramy Authorization i kilkamy Join Domain. Potem zostaje nam podać nazwę domeny w Domain Name oraz login i hasło do konta, które ma uprawnienia do dodawania komputerów do domeny. Po tym klikamy Join domain…
…i w ten sposób można zobaczyć efekt.
W ten sposób zalogowałem się na swoje konto z AD:
Integracja SSO z VMware vCenter 7.0
Pora na vCenter, gdzie podobnie możemy zintegrować logowanie z AD zarówno w interfejsie vCenter jak i w vCenter Server Management (interfejs na porcie 5480 z którego robimy aktualizację i kopie zapasowe vCenter).
Na początku trzeba upewnić się, że serwer DNS, który jest ustawiony w vCenter rozwiąże nazwę naszej domeny, więc do vCenter Server Management pod adresem https://<adres-vcenter>:5480, w moim przypadku: https://vcenter.serba.local:5480/#/login.
Następnie przechodzimy do Networking i klikamy na górze po prawej Edit:
Wybieramy interfejs vCenter i klikamy Next.
Następnie w Hostname and DNS określamy FQDN naszej maszyny (w moim przypadku vcenter.serba.local) i w DNS Settings wybieramy opcję Enter DNS settings manually, i podajemy adresy kontrolerów domeny, które nam rozwiążą nazwę domeny.
Na końcu podajemy poświadczenia administracyjne, dzięki których możemy zatwierdzić zmianę.
Po zmianie vCenter zrestartuje usługi sieciowe, poza tym te zmiany mogą wpłynąć na prawidłowe działanie środowiska, dlatego przed wykonaniem trzeba potwierdzić, że zrobiło się backup przed zmianami (co polecam zrobić!).
Następnie należy zalogować się do zwykłego interfejsu vCenter, przejść do Menu > Administration, następnie do Single Sign on > Configuration.
Tutaj, w zakładce Identity Provider należy wybrać Active Directory Domain i kliknąć Join AD przy wpisie z naszym adresem vCenter:
Potem wystarczy wpisać w Domain naszą nazwę domeny (w moim przypadku serba.local), Organization Unit jest opcjonalne i nie musimy go ustawiać (jest po to, by zmienić domyślny kontener, do którego trafia obiekt komputera vCenter w domenie, określa się go za pomocą DN, np. OU=Serwery,OU=it.supra.tf,DC=serba,DC=local). Ponadto podajemy poświadczenia użytkownika, który ma prawo do dodawania komputerów do domeny i klikamy Join.
Gdy nam się to uda, jesteśmy poproszeni o zrestartowanie vCenter w celu zatwierdzenia zmian:
Restart możemy wykonać za pomocą opcje Restart Guest (opcja wysyła sygnał do systemu operacyjnego zamiast natychmiast restartować maszynę wirtualną) lub możemy skorzystać z tej opcji w vCenter Server Management:
Po restarcie należy wrócić do miejsca, gdzie dodawaliśmy vCenter do domeny i w Identity Sources należy kliknąć Add i szczerze powiedziawszy to od razu można kliknąć Add, ponieważ domyślnie wszystko, co się zaznacza jest tym, co nas interesuje.
Potem można dodatkowo zmienić w tym menu domyślnego dostawcę logowania na AD zaznaczając go na liście oraz klikając Set as default, a następnie zatwierdzić klikając OK. To spowoduje, że logując się do vCenter nie musimy podawać UPN nazwy użytkownika (np. [email protected]), lecz wystarczy nazwa użytkownika (tzw. sAMAccountName, np. rserba):
Następnie w Administration > Access Control > Global Permissions należy dodać grupę, która będzie mogła zarządzać ustawieniami vCenter. Klikamy + i wskazujemy grupę w AD, która ma możliwość logowania i administracji. Ponadto działa tutaj dziedziczenie obiektów, więc można zawsze wskazywać grupy, których członkami są inne grupy, w której są dopiero nasi użytkownicy.
Wygląda to tak:
W ten sposób jestem w stanie się zalogować, ale niestety nie mam uprawnień do niektórych ustawień:
Problem wynika z tego, że nie jesteśmy w lokalnej grupie Administrators, która jest widoczna w vCenter 6.7 na liście, w przypadku vCenter 7.0 trzeba na dole po prawej przejść do następnej strony grup:
Grupy w vCenter 6.7
Poniżej animacja pokazująca jak dodać grupę Administratorzy domeny do grupy Administrators. Na tym etapie muszę zaznaczyć, że taką operację wykonujecie na własną odpowiedzialność, ponieważ VMware takiej opcji nie zaleca.
Po tej zmianie jak widać, mamy dostęp do wszystkich ustawień:
Tak samo możemy się od teraz logować kontami AD w vCenter Server Management, lecz tutaj logujemy się UPNem, czyli na przykład w moim przypadku kontem [email protected].
VMware Enhanced Authentication Plugin
vCenter pozwala na logowanie poprzez konto zalogowanego użytkownika na komputerze poprzez ten plugin. Wystarczy go pobrać, zainstalować i gotowe. Można to zrobić poprzez instalator, który znajdziemy na dole po prawej stronie w ekranie logowania:
Instalatora nie trzeba w żaden sposób konfigurować – idziemy wszędzie dalej i to się zainstaluje. Jedynie na początku dostajemy komunikat świadczący o tym, że po wykonaniu instalacji trzeba otworzyć na nowo przeglądarki, z których się używa.
Potem instalacja wygląda tak:
Koniec pierwszego instalatora odpala drugi, który można tak samo wyklikać.
Gdy mamy to już za sobą, możemy otworzyć na nowo przeglądarkę (w moim przypadku Google Chrome) i otworzyć stronę vCenter. Automatycznie po otwarciu Chrome spyta nas czy chcemy otworzyć program, do którego chce się dostać strona:
Następnie zatwierdzamy i otworzy się plugin, który nas spyta czy ufamy tej stronie. Z faktu, że tak dodatkowo zaznaczamy opcję Always ask before allowing this site i w ten sposób nie będziemy o to pytani ponownie.
Po tym wystarczy, że na ekranie logowania zaznaczymy Use Windows session authentication i nie musimy podawać loginu i hasła – po prostu klikamy Login.
Ten problem niestety jest przy każdym środowisku z Windowsem Server w domyślnej konfiguracji, lecz bez obaw – jest na to rozwiązanie. Problemem są wyłączone domyślne polityki firewalla w Windowsach, więc wystarczy je włączyć. Oczywiście robi się to polityką GPO, bo nie wyobrażam sobie takie coś wklepywać na 100 komputerach.
Należy włączyć następujące polityki firewalla w ruchu przychodzącym:
Instrumentacja zarządzania Windows (ruch przychodzący ASync)
Instrumentacja zarządzania Windows (ruch przychodzący DCOM)
Instrumentacja zarządzania Windows (ruch przychodzący WMI)
Zdalne zarządzanie usługami (RPC)
Zdalne zarządzanie usługami (RPC-EPMAP)
Zdalne zarządzanie zaplanowanymi zadaniami (RPC)
Zdalne zarządzanie Zaporą Windows Defender (RPC-EPMAP)
Na zrzucie ekranu można zobaczyć poniżej jak wyglądają ustawienia:
Oczywiście nie trzeba ich tworzyć ręcznie. Wystarczy otworzyć Zaporę Windows Defender z zabezpieczeniami zaawansowanymi, znaleźć pasujące nazwy i poprzeciągać do GPO. Od razu wszystko się ładnie doda. Po utworzeniu obiektu GPO można go na spokojnie przypiąć do korzenia drzewa AD, dzięki czemu obiekt będzie zmieniał ustawienia firewalla we wszystkich komputerach w domenie – tego chcemy.
Po tym należy odczekać 2 godziny, aż komputery kliencie same spróbują pobrać nową konfigurację GPO z domeny lub można zrestartować maszyny – to da nam ten sam skutek – maszyny będą miały zmienione ustawienia firewalla.
Gdyby ktoś był leniwy – tutaj kopia polityk, którą można sobie zaimportować. Do tego trzeba zrobić nowy obiekt, a potem kliknąć prawym i Importuj ustawienia….
Z istotnych rzeczy należy wybrać folder, w którym jest nasz plik ZIP z polityką.
Często we wdrożeniach SSL deep inspection jest pomijane, bo wdrażanie go jest upierdliwe. Osobiście uważam, że pomijanie wdrażania tej funkcjonalności to głupota. Aktualnie w sieci prawie 80% ruchu jest szyfrowana SSLem, więc bez takiego wdrożenia nie jesteśmy w stanie filtrować tego całego ruchu pod kątem potencjalnych zagrożeń, bo po prostu nie jesteśmy w stanie zaglądać bezinwazyjnie do ruchu użytkownika. Problem nie dotyczy stricte FortiGate, lecz dowolnego urządzenia, które takie filtrowanie robi (dzisiaj robi to każdy normalny UTM na rynku).
Dlaczego wdrożenie tego jest upierdliwe? FortiGate w ramach tej techniki rozszyfrowuje ruch pomiędzy klientem i serwerem, a następnie przed dotarciem do klienta ten ruch musi ponownie zaszyfrować, więc strony, które otwiera klient będą miały podpisane certyfikaty SSL przez FortiGate’a. To powoduje, że musimy mieć certyfikat CA FortiGate’a mieć zainstalowany na każdym komputerze wpadającym w regułę deep inspection.
W przypadku grupy roboczej rzeczywiście to może być piekło, ale w takiej sytuacji raczej większym zmartwieniem jest po prostu brak domeny Active Directory w organizacji. Teoretycznie można taki certyfikat CA FortiGate wysłać użytkownikom przez GPO, ale jest ogólnie lepsze rozwiązanie (można je zastosować tylko w przypadku posiadania wdrożonej domeny Active Directory) – użycie usług certyfikatów Active Directory. Można podpisać certyfikat dla podrzędnego urzędu certyfikacji, dzięki czemu ten z góry jest zaufany w naszych komputerach domenowych, bo główny urząd certyfikacji automatycznie jest dodawany po wdrożeniu do każdego komputera będącego w AD. W ten sposób nie trzeba dogrywać na komputerach klienckich żadnych dodatkowych certyfikatów.
Standardowo nie przedstawiam tutaj sposobu jak wdrażać AD CS, bo zakładam, że to już jest wdrożone (z dodatkową funkcją Rejestracja w sieci Web dla urzędu certyfikacji). Skupiam się tutaj nad samą częścią związaną z certyfikatem dla FortiGate’a. Na początku należy sobie wygenerować klucz prywatny oraz przygotować żądanie podpisania certyfikatu dla naszego nowego urzędu. Opisałem to tutaj, więc zalecam przejrzeć jak to się robi. W stosunku do tej stronki różnica w naszej konfiguracji jest taka, że tutaj moje pole CN i DNS.1 posiada wartość fortigate.serba.local, ponieważ tak się nazywa FQDN mojego urządzenia.
Po utworzeniu CSRki dostaniemy plik z podobną zawartością jak ta:
To jest nasze żądanie i te musimy przesłać do urzędu certyfikacji, by podpisać certyfikat. Wchodzimy na adres http://<adres-ca>/certsrv, w moim przypadku https://dc1.serba.local/certsrv:
Następnie należy wybrać Żądanie certyfikatu.
Następnie wybieramy zaawansowane żądanie certyfikatu.
Na tym etapie musimy otworzyć nasz plik CSR w jakimś edytorze tekstu, skopiować zawartość i wkleić w pole żądania. Ponadto, musimy wybrać szablon certyfikatu, dzięki czemu określamy przeznaczenie certyfikatu, który generujemy. To, co nasz interesuje to Podrzędny urząd certyfikacji. Po tym klikamy Prześlij >.
Na końcu pobieramy plik w formacie Base-64.
Ponadto, musimy pobrać certyfikat urzędu certyfikacji, co możemy zrobić na stronie głównej urzędu poprzez opcję Pobierz certyfikat urzędu certyfikacji, łańcuch certyfikatów lub listę CRL, a następnie mając zaznaczoną metodę kodowania Base 64, następnie klikając Pobierz certyfikat urzędu certyfikacji.
Mając oba certyfikaty, należy je dodać w FortiGate. Po zalogowaniu się do urządzenia należy przejść do sekcji System > Certificates i tam kliknąć Import > CA Certificate:
Po prawej stronie otworzy nam się menu, w Type wybieramy File i w Upload wskazujemy plik, a następnie zatwierdzamy:
W ten sposób CA jest dodane, więc dodatkowo warto też zmienić nazwę certyfikatu w FortiGate, by móc ją łatwiej w ustawieniach odnajdywać, co opisałem tutaj. Następnie dla certyfikatu podrzędnego CA należy zamiast Import > CA Certificate wybrać Import > Local Certificate. W Type wybieramy Certificate, następnie w Certificate file wybieramy plik certyfikatu, potem w Key file wybieramy klucz prywatny, który był wykorzystywany przy tworzeniu CSR i ewentualnie podajemy hasło do klucza. Ponadto można w Certificate Name z góry przypisać nazwę certyfikatu. Finalnie wygląda to tak:
Jak widać CA zostało dodane:
Dzięki temu możemy wykorzystywać nowy certyfikat podrzędny CA w SSL deep inspection:
Jako część mojej pracy inżynierskiej musiałem skonfigurować mechanizm uwierzytelniania oparty o domenę Active Directory. Założeniem było to, by użytkownicy z podłączonymi komputerami do domeny miały móc się logować bez jakiegokolwiek problemu do dwóch sieci Wi-Fi oraz do portów na switchu. Postaram się opisać jak wszystko skonfigurować od zera.
W każdym przypadku potrzebujemy serwera RADIUS. Są tutaj różne opcje, ponieważ można zainstalować serwer FreeRadius, lecz z faktu, że korzystałem w tym projekcie ze środowiska bazującego na Windowsach skorzystałem z roli Serwera zasad sieciowych (Network Policy Server).
Mechanizm działania jest dosyć prosty: użytkownik wykonuję próbę połączenia się z siecią po czym dostaje odpowiedź od urządzenia (access point lub switch), że musi się dodatkowo autoryzować i ten próbuje dokonać autoryzacji swoim kontem komputera lub aktualnie zalogowanego użytkownika w AD. Access point/switch komunikują się z serwerami RADIUS będąc ich klientami w celu sprawdzenia czy dany użytkownik ma mieć prawo do korzystania z zasobu (definiuje się to na podstawie grup użytkowników/komputerów). W trakcie połączenia klienta RADIUS z serwerem ci wykorzystują klucz współdzielony w celu uwierzytelnienia się. W przypadku, gdy użytkownik jest w grupie zdefiniowanej dla zasady przypisanej do klienta RADIUS – dostaje połączenie. W innym przypadku zostaje odrzucony.
Zanim zaczniemy instalować NPSa musimy mieć wcześniej wdrożony urząd certyfikacji (Usługi certyfikatów Active Directory). Myślę, że wkrótce taki poradnik pojawi się na mojej stronie (jeśli tak się stanie to dodam link tutaj do niego). Tak czy siak, gdy mamy to za sobą to instalujemy tą rolę:
Wybieramy Instalacja oparta na rolach lub oparta na funkcjach. Potem wybieramy serwer z listy, klikamy Dalej > i wybieramy Usługi zasad sieciowych i dostępu sieciowego i Dodaj funkcje. Potem Dalej >, Dalej >, Dalej > i Zainstaluj.
Po tym rola powinna być zainstalowana i powinniśmy zacząć konfigurację serwera.
Konfiguracja RADIUS dla sieci Wi-Fi na FortiGate
W tym scenariuszu będę bazował na urządzeniu FortiWiFi 60E, które ma wbudowaną kartę bezprzewodową. Na początku należy otworzyć okno Serwera zasad sieciowych, po czym zdefiniować nową zasadę poprzez wybranie w oknie Konfiguracja standardowa opcję Serwer usługi RAIDUS na potrzeby bezprzewodowych i przewodowych połączeń 802.1X i klikamy Skonfiguruj połączenia 802.1X.
Na dobrą sprawę nie ma znaczenia czy wybierzemy połączenia bezprzewodowe czy nie, bo i tak będziemy modyfikować zasadę tak, by brała pod uwagę adres IP klienta RADIUS zamiast przeznaczenia, ale z faktu, że to miało być dla Wi-Fi zaznaczamy opcję Bezpieczne połączenia bezprzewodowe i nazywamy jakoś zasadę, np. fortigate wifi.
Na następnej karcie kreatora należy zdefiniować klientów RADIUS, którzy będą się łączyli w ramach zasady RADIUS. Na początku nie ma żadnych, więc należy dodać przyciskiem Dodaj… nowego. Po tym należy zdefiniować pole Przyjazna nazwa, która jest po prostu nazwą klienta, a następnie adres IP lub jego FQDN. Z faktu, że dla moich klientów mam wcześniej przygotowane nazwy DNS, wpisałem po prostu fortigate.serba.local, co w moim przypadku odpowiada adresowi 192.168.30.1. Po tym definiujemy wspólny klucz tajny na dole okienka dwa razy. Powinien być długi i powinniśmy sobie go zapisać, bo taki klucz też trzeba będzie zdefiniować w FortiGate. Po tym zapisujemy i idziemy dalej.
Następnie wybieramy typ protokołu EAP dla tworzonej przez nas zasady i tutaj wybieram opcję Microsoft: Chroniony protokół EAP (PEAP). Gdy klikniemy Konfiguruj…, możemy sprawdzić lub zmienić jaki certyfikat będzie wykorzystywany przy komunikacji z klientem. W moim przypadku certyfikat był już wskazany, a ten się wygenerował po postawieniu AD CS (automatycznie, wystarczyło zrestartować serwer i mogłem się cieszyć certem z własnego urzędu).
Następnie należy dodać grupy, które mogą się autoryzować w ramach tej zasady. W moim założeniu dostęp mają wszyscy użytkownicy i wszystkie komputery będące w domenie, więc dodajemy grupy Użytkownicy domeny oraz Komputery domeny tak jak ja poniżej:
Następny punkt wykonuje się tylko i wyłącznie w przypadku FortiGate’a – definiujemy przesyłany parametr tekstowy, który służy do identyfikacji sieci. To działa tak, że FortiGate jest w stanie szukać polityki z konkretnym parametrem. Jeśli w różnych sieciach autoryzujemy różne grupy, możemy mieć takie ciągi znaków różne w różnych regułach, np. siec-handlowcy i siec-marketing, dzięki czemu dwie grupy mogą być inaczej brane pod uwagę przy logowaniu.
W oknie Konfigurowanie elementów kontroli ruchu w sieci klikamy po prawej Konfiguruj…, następnie wybieramy kartę Atrybuty specyficzne dla dostawcy. Domyślnie jest zdefiniowany jeden o nazwie atrybutu Ventor-Specific, klikamy na niego i Edytuj…. Po tym pojawi się okno Informacje o atrybutach i tutaj klikamy Dodaj…, a następnie otworzy się kolejne okno (szał!) Informacje o atrybutach specyficznych dla dostawcy i tutaj należy podać kod dostawcy 12356, zaznaczyć opcję Tak, jest zgodny pod kątem zgodności z RADIUS RFC i kliknąć Konfiguruj atrybut…. Tutaj zmieniamy Format atrybutu na Ciąg i wpisujemy wartość, którą chcemy określić daną politykę, byśmy mogli ją potem wskazać w FortiGate. W moim przypadku to wifi-fortigate. Ten parametr jest ogólnie opcjonalny; zobaczycie za niedługo dlaczego. Po tym wszędzie klikamy OK i Dalej na końcu.
Okienny rozgardiasz związany z milionem podopcji.
W ten sposób mamy prawie wszystko gotowe po stronie serwera:
Pod koniec trzeba zmienić nieco parametry warunkowe dla naszej zasady. Otwieramy Zasady żądań połączeń, znajdujemy naszą zasadę, klikamy prawym i Właściwości. W karcie Warunki usuwamy wszystko i klikając na dole Dodaj… dodajemy nowy warunek: Adres IPv4 klienta dostępu. Po tym jeszcze raz Dodaj… i tutaj podajemy adres IP naszego FortiGate’a.
Końcowo powinno wyglądać to tak (jeśli u Was też to tak wygląda to można zapisać ustawienia):
Po tym warto zmienić jeszcze 1 rzecz: metody uwierzytelnieniaw w zasadach sieciowych. W Zasady > Zasady sieciowe odnajdujemy naszą zasadę, klikamy na nią prawym i Właściwości. W zakładce Ograniczenia, w opcji Metody uwierzytelnienia odznaczamy opcje uwierzytelnianie z szyfrowaniem firmy Microsoft (MS-CHAP) i zostawiamy zaznaczone Uwierzytelnianie z szyfrowaniem firmy Microsoft wersja 2 (MS-CHAP-v2). Jeśli macie tak, jak na zrzucie ekranu – można zapisać.
Nie można zapomnieć o tym, by odblokować port dla RADIUSa na firewallu. Ruch musi być odblokowany dla portów TCP i UDP 1812, 1813, 1645, 1646 (dwa ostatnie dla starych urządzeń) dla połączeń przychodzących i wychodzących pomiędzy serwerem RADIUS a jego klientami (w naszym przypadku FortiGate, AP i switch z Netgear). Ja akurat zrobiłem na taką potrzebę politykę GPO:
Po zapisaniu wystarczy kliknąć prawym OU, w którym znajdują się serwery NPS (w moim przypadku są postawione na kontrolerze domeny) i wybrać Aktualizacja zasad grupy…, a następnie potwierdzić.
Efekty widać tutaj:
Tak samo odblokowujemy ruch do reguł wychodzących.
W interfejsie FortiGate, w User & Authentication > RADIUS Servers należy kliknąć Create New i zdefiniować profil w przykładzie jak niżej, przy czym w moim przypadku w IP/Name podałem FQDNy serwerów NPS, które posiadam (skonfigurowałem tak samo drugi serwer, by mieć redundancję, na koniec pokażę jak skopiować z serwera drugi wszystkie ustawienia). Do tych serwerów w polu Secret definiujemy klucz tajny, który definiowaliśmy na początku w zasadzie.
Następnie, po zapisaniu tych ustawień należy w User & Authentication > User Groups należy utworzyć grupę klikając Create New oraz w Remote Groups kliknąć Add, potem z listy Remote Server wybieramy wcześniej zdefiniowany profil RADIUSa i w Groups wybieramy Any jeśli nie chcemy określać się co do zasad, które zdefiniowaliśmy lub wybierając Specify możemy określić parametr, który zdefiniowaliśmy wcześniej w polu specyficznym dla dostawcy (w naszym przypadku wifi-fortigate).
Mając to trzeba edytować profil SSID w WiFi & Switch Controller > SSIDs lub stworzyć nowy klikając Create New > SSID. W Name definiujemy nazwę profilu (w moim przypadku (serba-corp-wifi), potem w WiFi Settings, w SSID definiujemy nazwę WiFi (w moim przypadku serba.local), w Security Mode wybieramy WPA2 Enterprise i w Authentication należy wybrać RADIUS Server i wybrać profil, który wcześniej zdefiniowaliśmy (w moim przypadku serba.local_radius). Mając zdefiniowane SSID możemy je przypisać do FortiAPków lub do interfejsu Software Switch, w którym są interfejsy, którym są podłączeni użytkownicy przewodowo. Poniżej przykład:
W ten sposób możemy zalogować się do sieci Wi-Fi nawet przez telefon z Androidem:
Tutaj ustawienia z telefonu. Warto dodać certyfikat CA do telefonu, by móc go wybrać.
I tutaj efekt końcowy.
Efekt końcowy widoczny z komputera, który jest członkiem AD:
Możemy to też przygotować wcześniej dodatkową polityką GPO, która dodaje sieć Wi-Fi o naszym SSID tak jak w zrzucie ekranu poniżej, ponadto niżej też konfiguracja zabezpieczeń dla profilu:
Konfiguracja RADIUS dla sieci Wi-Fi na AP od Netgear
Przykład jest prezentowany na urządzeniu Netgear WAC505. Scenariusz jest prawie taki sam, jak w przypadku definicji zasady dla FortiGate’a z drobną różnicą – nie definiujemy żadnego atrybutu specyficznego dla urządzenia i definiujemy dodatkowego klienta RADIUS na początku kreatora. Tak samo definiujemy inne ustawienia. W mojej konfiguracji klient posiada FQDN wac.serba.local, który odpowiada adresowi IP 192.168.30.253. Ten model, który mamy w przykładzie obsługuje też konfigurację przez chmurę, ja akurat definiuję ustawienia lokalnie. Pewnie jak bym miał takich access pointów 10 to definiowałbym to przez chmurę, bo łatwiej wszystko skonfigurować.
Na początku w w Configuration > Security > RADIUS Settings definiujemy adresy IP serwerów RADIUS, porty wykorzystywane do komunikacji oraz klucze współdzielone.
Potem, w Configuration > Wireless > Basic w karcie WLAN Settings należy wybrać SSID, w którym chcemy umożliwić na autoryzację kontami AD i wybrać w Network Authentication opcję WPA2-enterprise.
Po tym możemy dodać tak samo profil Wi-Fi jak w przypadku FortiGate’a. Jak widać poniżej, sieć działa:
I widok z komputera będącego w AD:
Konfiguracja RADIUS dla sieci przewodowej ze switchem marki Netgear
W tym scenariuszu wdrożenia posługiwałem się przełącznikiem Netgear GS716T.
Scenariusz wygląda bardzo podobnie jak w poprzednich politykach – tworzymy nową zasadę na serwerze zasad sieciowych (NPS) korzystając z opcji Bezpieczne połączenia przewodowe (Ethernet) w oknie Wybieranie typu połączeń 802.1X, usuwamy warunki połączenia klienta dla zasad żądań połączeń i definiujemy adres klienta jako adres switcha (w moim przypadku jest to adres netgear.serba.local (192.168.30.254).
Tak wyglądają warunki dla zasad żądań połączeń:
Tak wyglądają dla zasad sieciowych:
I tak wygląda profil klienta RADIUS dla switcha:
Dalsza część jest do ustawienia na switchu. Zaczynamy od zdefiniowania adresów DNS, które mają być wykorzystywane przez przełącznik (w System > Management > DNS > DNS Configuration) poprzez dodanie wszystkich adresów kontrolerów domeny w naszej sieci. Po wpisaniu wartości w puste pole należy kliknąć na dole Add.
Następnie w System > Management > IP Configuration należy się upewnić, że adres IP switcha się pokrywa z tym, który zdefiniowaliśmy w zasadzie w NPSie. W naszym przypadku jest w porządku.
Następnie w Security > Management Security > RADIUS > Server Configuration należy dodać wpisy adekwatne do środowiska:
Server Address: dc1.serba.local
Authentication Port: 1812
Secret Configured: Yes
Secret: tutaj podajemy klucz współdzielony
Active: Primary/Secondary, wybieramy w zależności tego, który serwer ma być wykorzystywany w autoryzacji w pierwszej kolejności
Message Authenticator: Disable
Po tym klikamy na dole Add i tak samo dodajemy serwer dc2.serba.local. Efekt końcowy wygląda tak:
Następnie w Security > Management Security > Authentication List > Dot1x Authentication List należy ustawić dla pola dot1xList w kolumnie 1 wartość Radius. i zatwierdzić kliknięciem Apply.
Teraz, w Security > Port Authentication > Advanced > Port Authentication należy zdefiniować w kolumnie Port Control odpowiednią opcję. Możliwości to:
Auto – ustawienie zależy od globalnego ustawienia pod kątem autoryzacji (ustawimy je na końcu). W domyślnych ustawieniach przełącznika autoryzacja nie jest wymagana.
Authorized – podłączone urządzenia w tym trybie nie przechodzą żadnej autoryzacji nawet, gdy ta jest włączona globalnie.
Unauthorized – brak możliwości autoryzacji pod wskazanym portem.
MAC Based – ustawienia są bazowane na tym, co jest zdefiniowane w ACL dla adresów MAC.
Dla wykonania testu ustawiłem port 1 i 2 w trybie Auto, resztę w trybie Authorized. Dzięki temu możemy na 2 portach testować czy komunikacja z RADIUS działa poprawnie, by potem móc ja włączyć dla reszty switcha.
Na końcu, w Security > Port Authentication > Advanced > 802.1X Configuration włączamy opcję Port Based Aurthentication State i zapisujemy klikając Apply. W ten sposób wszystko jest skonfigurowane po stronie switcha, więc zobaczmy efekty na urządzeniu, które jest w AD i urządzeniu, które w nim nie jest.
Obsługa 802.1X w Windowsie jest domyślnie wyłączona, więc włączamy ją zmienieniem ustawień usługi Automatyczna konfiguracja sieci przewodowej zmieniając Typ uruchomienia na Automatyczny oraz klikając Uruchom, by zaczęła działać.
Wygodniej jest stworzyć politykę GPO, która to nam ustawi na każdym komputerze, więc ta powinna mniej więcej wyglądać tak (dodam, że w tej polityce zmiana ustawień usługi WlanSvc okazała się niepotrzebna):
Tutaj można zobaczyć efekt końcowy:
Ponadto, w Security > Port Authentication > Advanced > Port Summary można zobaczyć, że na porcie 1 Port Status to Authorized:
W przypadku komputera, który nie jest członkiem AD akcja wygląda tak:
Niedawno się tym zajmowałem i w sumie dobrze by było się podzielić takim skryptem. Jest on nieco zmodyfikowany w stosunku, do tego co znalazłem na tej stronie.
Na początku próbka danych, która powinna być zapisana w pliku CSV:
firstname;lastname;username;email;streetaddress;city;zipcode;state;country;department;password;telephone;jobtitle;company;ou
Miron;Trawiński;mtrawinski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Mikołaj;Staszewski;mstaszewski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Adam;Rekowski;arekowski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Joachim;Grabiński;jgrabinski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Norbert;Ewertowski;newertowski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Aureliusz;Wręczycki;awreczycki;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Heronim;Ambroży;hambrozy;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Piotr;Jaroszek;pjaroszek;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Miłosz;Szcześniak;mszesniak;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Eustachy;Kowalewski;ekowalewski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Dorian;Kłopotowski;dklopotowski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Olgierd;Zaniewski;ozaniewski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Gracjan;Zambrzycki;gzambrzycki;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Fabian;Ciura;fciura;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Piotr;Skonieczny;pskonieczny;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Poniżej tworzenie OU oraz użytkowników w CSV (warto zwrócić uwagę, że pozycja Państwo jest zdefiniowana jako PL, a nie Polska ze względu na to, że w tym polu daje się Country Code.
<#Import active directory module for running AD cmdlets#>
Import-Module activedirectory
<#Create main OU#>
$baseDN = "DC=SERBA,DC=LOCAL"
$baseOU = "OU=it.supra.tf"
$baseOUstring = $baseOU + "," + $baseDN
<#New-ADOrganizationalUnit -Name "SUPRA" -Path $baseOU#>
if (Get-ADOrganizationalUnit -Filter "distinguishedName -eq '$baseOUstring'") {
Write-Host "$baseOUstring already exists."
} else {
New-ADOrganizationalUnit -Name $baseOU -Path $baseDN
}
<#Create OU's#>
$OUs = @("Dyrekcja","Handlowy","Marketing","Ksiegowosc","Rozwojowy","Prawny","Logistyczny","Techniczny")
<#Loop through each name of the OU to create them#>
foreach ($OUcreate in $OUs) {
$fullOUstring = "OU=" + $OUCreate + "," + $baseOUstring
Write-Output $fullOUstring
if (Get-ADOrganizationalUnit -Filter "distinguishedName -eq '$fullOUstring'") {
Write-Host "$OUcreate already exists."
} else {
New-ADOrganizationalUnit -Name $OUcreate -Path $baseOUstring
}
}
<#Store the data from ADUsers.csv in the $ADUsers variable#>
$ADUsers = Import-csv -Delimiter ";" -Path .\bulk-users-polska.csv
<#Loop through each row containing user details in the CSV file#>
foreach ($User in $ADUsers)
{
<#Read user data from each field in each row and assign the data to a variable as below#>
$Username = $User.username
$Password = $User.password
$Firstname = $User.firstname
$Lastname = $User.lastname
$OU = $User.ou <#This field refers to the OU the user account is to be created in#>
$email = $User.email
$streetaddress = $User.streetaddress
$city = $User.city
$zipcode = $User.zipcode
$state = $User.state
$country = $User.country
$telephone = $User.telephone
$jobtitle = $User.jobtitle
$company = $User.company
$department = $User.department
$Password = $User.Password
<#Check to see if the user already exists in AD#>
if (Get-ADUser -F {SamAccountName -eq $Username})
{
<#If user does exist, give a warning#>
Write-Warning "A user account with username $Username already exist in Active Directory."
}
else
{
<#User does not exist then proceed to create the new user account
Account will be created in the OU provided by the $OU variable read from the CSV file#>
New-ADUser `
-SamAccountName $Username `
-UserPrincipalName "[email protected]" `
-Name "$Firstname $Lastname" `
-GivenName "$Firstname" `
-Surname "$Lastname" `
-Enabled $True `
-DisplayName "$Firstname $Lastname" `
-Path "$OU" `
-City "$city" `
-Company "$company" `
-State "$state" `
-StreetAddress "$streetaddress" `
-Country "$country" `
-PostalCode "$zipcode" `
-OfficePhone "$telephone" `
-EmailAddress "$email" `
-Title "$jobtitle" `
-Department "$department" `
-AccountPassword (convertto-securestring $Password -AsPlainText -Force) -ChangePasswordAtLogon $False -PasswordNeverExpires $True -CannotChangePassword $True
}
}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Downtown'}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=Techniczny,OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Headquarters'}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=Dyrekcja,OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Headquarters'}
I na koniec tworzenie kont w Exchange dla tych użytkowników (istotne – ten skrypt musi być odpalony przez Exchange Management Shell):
Import-Module activedirectory
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
<#adding everyone in that specified company#>
$users = Get-ADUser -Filter {company -eq "it.supra.tf"}
Write-Output $users
foreach($user in $users)
{
Enable-Mailbox -Identity $user.SamAccountName
}
Akurat to użycie integracji nie daje aż takich korzyści w stosunku do integracji AD na przykład z FortiGate’m, ale nadal można to wykorzystać w ciekawy sposób niespecjalnie pocąc się przy konfiguracji. Założenie jest dosyć proste – umożliwić logowanie się na konta z domeny Active Directory (najnornalniejszej na świecie, żadne udziwnienia w postaci AD na QNAPie czy tym podobne) oraz umożliwić konkretnej grupie w AD korzystanie z uprawnień administracyjnych (aka korzystanie z polecenia sudo).
Moje środowisko składa się z dwóch kontrolerów domeny, ad1.serba.local (192.168.30.2) i ad2.serba.local (192.168.30.3). Do tego są inne hosty w sieci, które są totalnie nieistotne. Jak FQDNy wskazują, moja nazwa domeny to serba.local. Grupa, której damy uprawnienia administracyjne w Linuksach to wbudowana grupa AD Administratorzy domeny. Adres sieci to 192.168.30.0/24 i pierwszy użyteczny adres to adres routera. Przykład integracji opieram na Windowsach Server 2019 v. 1809, Xubuntu 19.10 i Red Hat Enterprise Linux 8.0. Dobrałem takie 2 dystrybucje Linuksa ze względu na to, że one i ich pochodne (przy czym Ubuntu jest pochodną Debiana te podobieństwo działa w drugą stronę) są bardzo podobne w konfiguracji, więc w jednym poradniku będzie można zobaczyć jak zrobić taką integrację na większości dystrybucji. W praktyce powinniśmy być w stanie zintegrować dowolną dystrybucję Linuksa posiadając zainstalowane w systemie odpowiednie pakiety.
Integracja AD na (X)ubuntu
Na początku zaczynamy od instalacji potrzebnych pakietów:
Następnie edytujemy plik /etc/samba/smb.conf w sekcji [global] (ta sekcja zaczyna się pod tym nagłówkiem, a kończy się z miejscem kolejnego):
workgroup = SERBA #tutaj nazwa NETBIOS domeny
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = SERBA.LOCAL #koniecznie dużymi literami
security = ads
idmap config *: range = 10000-20000 #bez dodania tego parametru nie przechodził test cfg
Po wykonaniu zmian warto przetestować, czy wszystko w tym pliku konfiguracyjnym jest OK, w innym wypadku sługi smbd i nmbd nie uruchomią się po restarcie. Robimy to poleceniem sudo testparm:
Następnie edytujemy /etc/sssd/sssd.conf (ten plik domyślnie nie istnieje, więc nie zdziwcie się, jeśli pliku nie będzie):
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[sssd]
domains = serba.local #tutaj nazwa domeny małymi literami
config_file_version = 2
services = nss, pam
default_domain_suffix = SERBA.LOCAL #tutaj domena dużymi literami
full_name_format = %1$s #dzięki tej linijce nie musimy wpisywać `użytkownik@domena` tylko wystarczy `użytkownik`
[domain/serba.local] #małymi literami domena
ad_domain = serba.local #ponownie domena małymi literami
krb5_realm = SERBA.LOCAL #tym razem domena dużymi literami
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash #definiujemy shell dla logujących się użytkowników AD, może być inny
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u #składnia: /home/<nazwa-domeny>/<nazwa-uzytkownika>
access_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_schema = ad
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
Po stworzeniu konfiguracji musimy zabezpieczyć plik w ten sposób, by inni poza rootem nie mieli do niego dostępu:
[active-directory]
os-name = Linux Ubuntu
os-version = 19.04
[service]
automatic-install = yes
[users]
default-home = /home/%d/%u
default-shell = /bin/bash
[serba.local]
user-principal = yes
fully-qualified-names = no
[providers]
samba = no #bez tej linijki są problemy z logowaniem ze wskazaniem uprawnień grup do logowania poprzez realm
Mając to zrobione musimy zrestartować usługi, które konfigurowaliśmy:
# systemctl restart smbd nmbd sssd realmd
Następnie możemy sprawdzić, czy mamy połączenie z domeną pobierając „bilecik” z KDC poprzez polecenie kinit określając nazwę użytkownika@domenę, z której się logujemy:
# kinit [email protected]
Password for [email protected]:
# /etc/sssd > klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
02.04.2020 21:04:52 03.04.2020 07:04:52 krbtgt/[email protected]
renew until 09.04.2020 21:04:49
Po tym możemy dołączyć naszym Linuksowym hostem do domeny AD. Najpierw sprawdźmy, czy jesteśmy w stanie wykryć domenę w naszej sieci poleceniem realm discover -v NAZWA.DOMENY:
I teraz już na serio dołączamy do domeny poleceniem realm join NAZWA.DOMENY -U konto_admina -v:
# realm join SERBA.LOCAL -U rserba -v
* Resolving: _ldap._tcp.serba.local
* Performing LDAP DSE lookup on: 192.168.30.3
* Performing LDAP DSE lookup on: 192.168.30.2
* Successfully discovered: serba.local
realm: Już dołączono do tej domeny
Powtarzamy poleceniem net ads join -k:
# net ads join -k
Using short domain name -- SERBA
Joined 'SUPRA-VM' to dns domain 'serba.local'
Następnie musimy ograniczyć logowanie do tego hosta poprzez wskazanie grupy, która może się logować oraz reszty, która tego robić nie może. Pierwszym poleceniem blokujemy dostęp wszystkim użytkownikom, a następnie dodajemy grupę, która może się logować do tego systemu. Wszyscy członkowie tej grupy mogą się zalogować.
# realm deny -a
# realm permit --groups 'serba.local\Administatorzy domeny'
Przed zalogowaniem się musimy też umożliwić automatyczne tworzenie katalogów dla użytkowników (w innym wypadku na dobrą sprawę użytkownicy AD nie będą w stanie normalnie funkcjonować w systemie na własnych prawach):
# pam-auth-update
Po otwarciu okna zaznaczamy Create home directory on login i dajemy OK:
Warto też sprawdzić plik /etc/nsswitch.conf, w sekcjach passwd, group i shadow, netgroup, services i sudoers powinno być dopisane na końcu sss:
Po tym powinniśmy dodać do /etc/pam.d/common-account linijkę na samym dole pliku:
I teraz instalujemy winbind po to, by móc wykorzystać konta AD w ekranie logowania:
# apt install winbind
Usługa winbind.service powinna się uruchomić od razu po instalacji. Sprawdźmy, czy możemy pobrać użytkowników i grupy z AD poleceniami wbinfo -u i wbinfo -g:
# wbinfo -u
SERBA\administrator
SERBA\gość
SERBA\krbtgt
SERBA\fsso
SERBA\rserba
SERBA\smatuszczyk
SERBA\serviceacc
SERBA\mblaszczyk
SERBA\dkania
# wbinfo -g
SERBA\komputery domeny
SERBA\kontrolery domeny
SERBA\administratorzy domeny
SERBA\użytkownicy domeny
SERBA\goście domeny
SERBA\twórcy-właściciele zasad grupy
SERBA\kontrolery domeny tylko do odczytu
SERBA\klonowalne kontrolery domen
SERBA\protected users
SERBA\administratorzy kluczy
SERBA\dnsupdateproxy
SERBA\wydawcy certyfikatów
SERBA\serwery ras i ias
SERBA\grupa z replikacją haseł na kontrolerach rodc
SERBA\grupa bez replikacji haseł na kontrolerach rodc
SERBA\dnsadmins
SERBA\administratorzy schematu
SERBA\administratorzy przedsiębiorstwa
SERBA\kontrolery domeny tylko do odczytu na poziomie organizacji
SERBA\administratorzy kluczy przedsiębiorstwa
Jak widać, działa. Sprawdźmy, czy jesteśmy sprawdzić informacje o użytkowniku rserba:
Na końcu dodamy grupę Administratorzy domeny do /etc/sudoers i umożliwimy na logowanie poprzez interfejs graficzny (wykorzystując menedżer wyświetlania LightDM). Edytujemy /etc/sudoers (plik określający kto w tym systemie może korzystać z polecenia sudo) poleceniem visudo (jak root) i dodajemy linijkę:
#%SERBA\\administratorzy\ domeny ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
#%administratorzy\ [email protected] ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
%administratorzy\ domeny ALL=(ALL:ALL) ALL
Potem edytujemy plik /usr/share/lightdm/lightdm.conf.d/60-xubuntu.conf (na dobrą sprawę możemy sobie nawet sami utworzyć nowy plik w katalogu /usr/share/lightdm/lightdm.conf.d i upewnić się, że będzie miał prawidłową składnię) i dodajemy:
Dzięki temu trzeba będzie wpisać w pole logowania nazwę użytkownika i hasła i w ten sposób będzie można się logować na pulpit tak samo, jak lokalni użytkownicy. Zmiany są widoczne po restarcie usługi lightdm.service, więc możemy po prostu uruchomić system ponownie i wszystko powinno już wejść w życie.
Przy okazji próbując zmienić konto poprzez polecenie su - nazwa_usera_ad możemy sprawdzić czy ograniczenia na logowanie działają:
supra@supra-vm > ~ > su - rserba
Hasło:
rserba@supra-vm:~$ exit
wylogowanie
supra@supra-vm > ~ > su - smatuszczyk
Hasło:
su: Uwierzytelnienie się nie powiodło
W ten sposób wszystko działa poprawnie, przetestujmy sudo:
Okej, na tym etapie musimy też edytować plik /etc/krb5.conf:
# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
udp_preference_limit = 1
rdns = false
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
spake_preauth_groups = edwards25519
default_realm = SERBA.LOCAL #tak, domena musi być z dużej litery
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
SERBA.LOCAL = { #tutaj podobnie
kdc = serba.local #nie wpisujemy poszczególnych kontrolerów domeny, jeśli discovery działa to nie ma sensu podawać tutaj FQDNa kontrolera
admin_server = serba.local #podobnie, w obu przypadkach podajemy z małych liter nazwę domeny
}
[domain_realm]
.serba.local = SERBA.LOCAL #w obu przypadkach z dużej litery domena
serba.local = SERBA.LOCAL
Okej, mając to ustawione zastosujmy konfigurację poleceniem authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update:
[root@rhel8 ~]# authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update
Running authconfig compatibility tool.
The purpose of this tool is to enable authentication against chosen services with authselect and minimum configuration. It does not provide all capabilities of authconfig.
IMPORTANT: authconfig is replaced by authselect, please update your scripts.
See man authselect-migration(7) to help you with migration to authselect
Warning: These options are not supported anymore and have no effect:
--enablelocauthorize
Executing: /usr/bin/authselect check
Executing: /usr/bin/authselect select sssd with-mkhomedir --force
Executing: /usr/bin/systemctl enable sssd.service
Executing: /usr/bin/systemctl stop sssd.service
Executing: /usr/bin/systemctl start sssd.service
Executing: /usr/bin/systemctl enable oddjobd.service
Executing: /usr/bin/systemctl stop oddjobd.service
Executing: /usr/bin/systemctl start oddjobd.service
Dobra, teraz upewnijmy się, że /etc/sssd/sssd.conf wygląda mniej więcej tak (jeśli nie, warto to nieco skorygować):
Jeśli zmienimy cokolwiek, restartujemy usługę (od razu sobie warto ustawić ją tak, by uruchamiała się wraz ze startem systemu):
# systemctl start sssd //w dokumentacji jest service sssd start
# systemctl enable sssd //w dokumentacji jest chkconfig sssd on
Po tym zrestartowałbym system. Na końcu musimy zdefiniować kto może faktycznie się logować do swoich kont administracyjnych:
sudo realm deny -a
sudo realm permit --groups 'serba.local\Administratorzy domeny'
Na końcu dodamy grupę Administratorzy domeny do /etc/sudoers za pomocą visudo:
#%SERBA\\administratorzy\ domeny ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
#%administratorzy\ [email protected] ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
%administratorzy\ domeny ALL=(ALL:ALL) ALL
Na dobrą sprawę to tyle. GDM (menedżer wyświetlania w RHEL 8) nie wymaga dodatkowych modyfikacji, by umożliwić użytkownikom z AD logowanie się na swoje konta w interfejsie graficznym. Wspominając o Fortigate – z pewnego powodu agent FSSO nie widzi logowań na hostach z Linuksem, więc jeśli ktoś by wiedział jak to rozwiązać – zostawcie komentarz.
