Forefront TMG 2010 - część 17 - Uwierzytelnianie z wykorzystaniem weryfikatora RADIUS

Autor: Jacek Światowiak

Opublikowano: 2012-03-29

Wprowadzenie

W poprzedniej części cyklu omówiono wykorzystanie weryfikatora LDAP, jednakże zdecydowanie częściej wykorzystywany jest serwer RADIUS, celem uwierzytelniania, autoryzacji i rozliczania użytkowników czy urządzeń.

Wstęp

Na wstępie, przypomnimy procedurę instalacji i konfiguracji serwera RADIUS dla najprostszego scenariusza. Serwer RADIUS jest elementem roli serwera 2008/2008 R2, określanej jako Network  Network Policy and Access Services, w skrócie zwany NPS. Wybór instalacji roli NPS pokazano na Rys. 1.

Rys. 1. Instalacja roli serwera NPS.

W oknie Network Policy and Access Services (Rys. 2.) przedstawione zostały informacje o roli pełnionej przez komponenty roli NPS.

Rys. 2.Okno wprowadzenia do roli serwera NPS.

W oknie Select Role Services (Rys. 3.) dokonujemy wyboru komponentów roli serwera usług NPS. Serwer RADIUS kryje się pod nazwą Network Policy Server.

Rys. 3. Wybór komponentu Network Policy Server.

W oknie Confirm Installation Selection (Rys. 4.) następuje potwierdzenie wybranych do instalacji komponentów.

Rys. 4. Okno potwierdzenia procesu instalacji roli serwera NPS.

Na Rys. 5., w oknie Installation Results przedstawiony został wynik instalacji komponentów roli NPS. Przy instalacji roli NPS nie jest wymagany restart serwera.

Rys. 5. Okno zakończenia procesu instalacyjnego.

Niezależnie czy serwer NPS instalowany jest na kontrolerze domeny czy na innym serwerze, będącym członkiem domeny, wymagana jest rejestracja serwera NPS w Active Directory. Należy w tym celu kliknąć prawym przyciskiem myszy na nazwie NPS(Local) i wybrać z menu opcję Register server in Active Directory. Na Rys. 6. pokazano wygląd menu po zarejestrowaniu serwera, zaś na Rys. 7. i Rys. 8. zaprezentowano okno informacyjne, wyświetlane w trakcie rejestracji.

Rys. 6. Menu opcji serwera NPS.

Każdy obiekt użytkownika oraz komputera, we właściwościach w przystawce Active Directory Users and Computer, posiada specjalną zakładkę Dial-In, na której definiowane są opcje elementów (atrybuty obiektu) odpowiadających za kontrolę zdalnego dostępu (bez znaczenia, czy jest to dostęp wdzwaniany, VPN czy inny kanał dostępu, obsługiwany poprzez serwer RADIUS). Rejestracja serwera RADIUS w Active Directory pozwala na odczytywanie tych atrybutów przez serwer RADIUS. Wygląd omawianej zakładki przedstawiony został na Rys. 12.

Rys. 7. Okno informujące o nadaniu uprawnień roli NPS do atrybutów użytkownika.

Rys. 8. Okno informujące o zakończeniu rejestracji serwera NPS w Active Directory użytkownika.

Jeżeli w tym momencie wybierzemy z menu (Rys. 6.) opcję Properties, będzie można określić, jakie zdarzenia będą musiały zostać zalogowane przez serwer NPS. Logowane domyślnie są zarówno żądania dostępu, zakończone sukcesem, jak i niepowodzeniem.

Rys. 9. Okno konfiguracyjne opcji logowania serwera NPS.

Proces rejestracji serwera NPS w Active Directory skutkuje dodaniem obiektu komputera, na którym zainstalowana została rola serwera NPS do grupy RAS and IAS Servers. Lokalizację grupy prezentuje Rys. 10.

Rys. 10. Lokalizacja grupy RAS and IAS Servers.

Listę członków grupy przedstawiono na Rys. 11. Jeżeli instalator nie dodał tu obiektu reprezentującego konto komputera serwera RADIUS, należy taki obiekt dodać manualnie.

Rys. 11. Lista członków grupy RAS and IAS Server.

Uwaga informacyjna

 Nie jest wymagany restart serwera NPS po dodaniu konta komputera do grupy.

Rys. 12. Właściwości użytkownika, zakładka Dial-in.

Wybór kontroli dostępu (niezależnie, czy będzie to dostęp wdzwaniany, VPN czy inny kanał kontrolowany przez serwer RADIUS) jest zależny od ustawień sekcji Network Access Permission zakładki Dial-in (telefonowanie w polskiej wersji językowej serwera) właściwości konta użytkownika lub komputera. Wygląd zakładki Dial-in konta użytkownika prezentuje Rys. 12.

Konsola zarządzania serwera NPS.

W konsoli serwera NPS można wyróżnić cztery kontenery konfiguracyjne (Rys. 13.) Są to:

• RADIUS Client and Servers – kontener służy do definiowania obiektów typu RADIUS CLIENT, RADIUS PROXY oraz grup serwerów RADIUS,
• Policies – tu definiowane są zasady (polityki/polisy) zdalnego dostępu,
• Network Access Protection – poziom konfiguracji mechanizmu NAP (nie będzie wykorzystywany w omawianym scenariuszu konfiguracyjnym),
• Templates Management – szablony obiektów, zasad i innych elementów konfiguracyjnych (nie będzie wykorzystywany w omawianym scenariuszu konfiguracyjnym).

Rys. 13. Konsola zarządzania serwera RADIUS (Network Policy Server).

KROK  1. Dodawanie/konfiguracja klientów RADIUS.

W pierwszym kroku konfiguracyjnym należy zdefiniować klienta RADIUS. Klientem RADIUS jest serwer zapewniający obsługę żądań zdalnych, w naszym scenariuszu jest to serwer TMG 2010. Opcje menu dodawania klienta RADIUS przedstawione zostały na Rys. 14.

Rys. 14. Menu dodawania nowego klienta RADIUS.

W oknie New RADIUS Client (Rys. 15.) należy zdefiniować:

• przyjazną nazwę klienta RADIUS,
• adres IP lub nazwę klienta RADIUS,
• hasło odpowiadające za wzajemne uwierzytelnianie klienta RADIUS <-> serwera RADIUS.

Rys. 15. Okno definiowania nowego klienta RADIUS.

Okno weryfikacji poprawności nazwy oraz adresu IP klienta RADIUS przedstawiono na Rys. 16. 

Rys. 16. Okno weryfikacji poprawności nazwy oraz adresu IP klienta RADIUS.

Po utworzeniu klienta RADIUS można podejrzeć jego zaawansowane parametry. Jeżeli klikniemy prawym przyciskiem myszy w oknie Radius Client (z Rys. 13.) na nazwie klienta RADIUS, zostanie wyświetlone okno Properties. Zakładka Settings ma identyczne opcje, jak podczas definiowania klienta RADIUS. Na zakładce Advanced (Rys. 17.) można określić dodatkowe parametry. Dla scenariusza przy uwierzytelnianiu do serwera Web wystarczy konfiguracja domyślna:

• Vendor Name: RADIUS Standard**,**
• Additional Options: obie niezaznaczone opcje.

Rys. 17. Ustawienia zaawansowane klienta RADIUS.

 

KROK  2. Konfiguracja /modyfikacja Connection Request Policies.

W kolejnym kroku należy zweryfikować lub utworzyć obiekt Connection Request Policies. Jest to zasada określająca mechanizmy komunikacji pomiędzy serwerem RADIUS a weryfikatorem, którym jest Active Directory. 

Rys. 18. Okno zarządzania obiektami Connection Request Policies.

Obiekt Connection Request Policies definiuje:

• warunki, które muszą zostać spełnione, aby przekazać żądanie dostępu do weryfikatora – Sekcja Condition,
• miejsce, gdzie żądanie ma zostać przekazane – Sekcja Settings.

W scenariuszu wykorzystujemy domyślnie zdefiniowany obiekt (polisę) – Use Windows authentication for all users. Umożliwia ona uwierzytelnianie obiektów typu konto użytkownika w środowisku domenowym – lokalnie (gdyż serwer RADIUS zainstalowany jest na kontrolerze domeny – sekcja Settings – Authentication Provider – Local Computer).

KROK  3. Tworzenie/modyfikacja Network Policies.

Trzeci, najważniejszy, krok to utworzenie obiektu (polisy) typu Network Policy. Na Rys. 19. przedstawiono wygląd otwartego okna zarządzania obiektami tego typu. Domyślnie zdefiniowane są dwa tego typu obiekty. W scenariuszu oba zostały wyłączone. Utworzony zostanie nowy.

Rys. 19. Okno zarządzania obiektami Network Policies.

Po kliknięciu prawym przyciskiem myszy na kontenerze Network Policies wybieramy z menu opcję New. Okno wstępne tworzenia obiektu typu Network Policy przedstawione zostało na Rys. 20. W oknie tym określamy nazwę nowego obiekty typu Network Policy. W polu Type of network access server pozostawiamy wartość - Unspecified.

Rys. 20. Okno wstępne tworzenia obiektu typu Network Policy.

W oknie Specify Condition (Rys. 21.) określamy, jakie warunki muszą być spełnione, aby można było zaakceptować i przekazać do weryfikatora żądanie dostępu. W przykładzie zdefiniowano dwa warunki:

• Day and time restriction – godziny i dni dostępu (klasyczny harmonogram 7 dniowy),
• User Groups – członkostwo użytkownika w określonej grupie domeny Windows.

Rys. 21. Okno określania warunków dostępu.

W oknie Specify Access Permission (Rys. 22.) określamy typ dostępu (jest to de facto element odpowiadający za autoryzację dostępu). Dostępne opcje to:

• Access granted – dostęp zostanie przydzielony,
• Access denied – dostęp zostanie odmówiony,
• Access is determined by Dial-in properties – za kontrolę dostępu odpowiadają właściwości zakładki Dial-in konta użytkownika lub komputera.

Rys. 22. Okno określania typu dostępu.

W oknie Configure Authentication Methods (Rys. 23.) określamy, jakie protokoły uwierzytelniania będą wspierane dla danej metody dostępu. Serwer TMG pobiera od użytkownika poświadczenia metodą BASIC lub FormBased, zatem przesyłane są one jawnym tekstem (co najwyżej w formacie BASE 64). Należy więc dodać uwierzytelnianie, bazujące na protokole PAP – Password Authentication Protocol (Unencrypted authentication).

Rys. 23. Okno wyboru protokołów uwierzytelniania.

W oknie Configure Constraints (Rys. 24.) zostawiamy wartości domyślne.

Rys. 24. Okno Configure Constraints.

 

W oknie Configure Settings (Rys. 25.) również nie wprowadzamy żadnych modyfikacji.

Rys. 25. Okno Configure Settings.

 

Okno podsumowania tworzenia obiektu typu Network Policy przedstawiono na Rys. 26.

Rys. 26. Okno podsumowania tworzenia obiektu typu Network Policy.

 

Modyfikacje komponentów TMG – Listener

Po skonfigurowaniu serwera RADIUS oraz wymaganych obiektów typu Connection Request Policy, oraz Network Policy należy dokonać konfiguracji serwera TMG, czyli klienta RADIUS. Zgodnie z tym, co zostało już wcześniej omówione, za uwierzytelnianie odpowiada obiekt listener. Na zakładce Authentication, pokazanej po lewej stronie na Rys. 27., wybieramy uwierzytelnianie metodą BASIC. Aktywna będzie wówczas opcja RADIUS. Po kliknięciu Configure Validation Server…. można będzie wybrać/zdefiniować weryfikator typu RADIUS. Wygląd okna Authentication Servers – RADIUS Servers zaprezentowano po prawej stronie na Rys. 27.

Rys. 27. Konfiguracja listenera do uwierzytelniania poprzez serwer RADIUS.*

 

W celu dodania serwera RADIUS należy kliknąć w przycisk Add… (Rys. 27.). W oknie Add RADIUS Server, pokazanym po lewej stronie na Rys. 28., definiujemy:

• Server name - nazwę serwera RADIUS, 
• Server description – przyjazny opis,
• Authentication port – port wykorzystywany do komunikacji pomiędzy klientem a serwerem RADIUS (domyślnie 1812 dla nowych implementacji serwera i klienta RADIUS),
• Shared secret – hasło służące wzajemnemu uwierzytelnianiu serwera i klienta RADIUS.

Rys. 28. Konfiguracja RADIUS od strony serwera TMG.**

 

W celu zdefiniowania hasła należy kliknąć w przycisk Change… Zostanie wówczas wyświetlone okno przedstawione na Rys. 29. Hasło musi być tym samym hasłem, które było definiowane w serwerze RADIUS dla danego klienta RADIUS.

Rys. 29. Definiowanie hasła wzajemnego uwierzytelniania serwera/klienta RADIUS.

 

Widok skonfigurowanej reguły publikacji serwera Web z uwierzytelnianiem poprzez serwer RADIUS zaprezentowano na Rys. 30.

Rys. 30. Reguła publikacji serwera Web z uwierzytelnianiem poprzez serwer RADIUS.

 

Logowanie operacji serwera RADIUS

Diagnozowanie problemów z uwierzytelnianiem poprzez serwer RADIUS jest dość proste. Logi przechowywane są w pliku tekstowym INxxxx.log, gdzie xxxx – to data w formacie dzienmiesiac, w folderze na dysku systemowym c:\Windows\System32\Logfiles. Fragment logu zaprezentowano na Rys. 31.

Rys. 31. Fragment logu serwera RADIUS.

Format nie jest zbyt czytelny, dlatego najwygodniej posłużyć się dowolnym paserem logów IAS. Przykład wykorzystania aplikacji IAS Log Viewer przedstawiono na Rys. 32.

Rys. 32. Parser logów serwera RADIUS.

Na Rys. 33. pokazano rozwiniętą jedną linię logu odpowiadającą pojedynczemu żądaniu dostępu.

Jeżeli otworzymy teraz pojedynczą linię, odpowiadającą pojedynczemu żądaniu logowania, można wyczytać tam wiele informacji: czy operacja zakończyła się sukcesem czy niepowodzeniem, kiedy nastąpiła próba uzyskania dostępu, kto próbował uzyskać dostęp, poprzez jaki port i jaką metodą, jakie obiekty serwera NPS były wykorzystane, i wiele innych.

Rys. 33. Rozwinięty pojedynczy wpis z logu serwera RADIUS.**

 

Zdarzenia są również logowane w logu security. Przykład takiego zdarzenia zaprezentowano na Rys. 34. Jest to próba uzyskania dostępu zakończona powodzeniem.

Rys. 34. Zdarzenie logu security – odpowiadające zdarzeniu uzyskania dostępu.

Rys. 35. przedstawia dalszy fragment tego samego zdarzenia. Najwięcej informacji znajduje się w sekcji Authentication Details.

 

 

Rys. 35. Zdarzenie logu security – odpowiadające zdarzeniu uzyskania dostępu.

Podsumowanie

W niniejszej części cyklu omówiono zagadnienie wykorzystania weryfikatora RADIUS. Weryfikator RADIUS bywa bardzo często stosowany w szczególności dla konfiguracji pracy serwera TMG w grupie roboczej lub w przypadku wykorzystywania metod uwierzytelniania wieloskładnikowego, np. TOKENY czy hasła jednorazowe. W kolejnym artykule omówione zostaną mechanizmy przekazywania poświadczeń przez serwer TMG do serwerów docelowych.