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.

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:

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:

I od razu Port Status:

I to by było na tyle.