Forefront TMG 2010 – część 15 – Publikacja zasobów – serwerów WEB z uwierzytelnianiem dostępu

Udostępnij na: Facebook

Autor: Jacek Światowiak

Opublikowano: 2012-03-08

Wprowadzenie

W poprzedniej części cyklu artykułów omówiono kwestię publikacji zasobów serwera Web, zabezpieczonej certyfikatem SSL. Wszystkie zagadnienia omówione do tej pory zakładały publikacje w trybie anonimowym (bez uwierzytelniania). W wielu przypadkach, dostęp do zasobów publikowanych serwerów musi być odpowiednio uwierzytelniony.

 

Wstęp

Omawiając kwestie uwierzytelniania musimy się zastanowić, w którym miejscu musi ono nastąpić: na serwerze docelowym bądź na serwerze TMG 2010, z przekazywaniem poświadczeń bezpieczeństwa do serwera docelowego lub bez, czy też może w obu tych miejscach. Przy wyborze uwierzytelniania na serwerze docelowym, serwer TMG 2010 musi zapewnić przekazywanie poświadczeń w trybie przezroczystym. W przypadku uwierzytelniania na serwerze TMG 2010, musimy zapewnić mechanizm weryfikacji, poświadczeń bezpieczeństwa w tzw. Weryfikatorze, podanych przez użytkownika. Mogą to być: Active Directory, LDAP, RADIUS lub serwer RSA SecureID**.**

****Rys. 1.****Ilustracja uwierzytelniania na serwerze TMG.**

Za uwierzytelnianie Na TMG 2010 odpowiada listener. Dotychczas nie korzystano z tej funkcji, dlatego w opcjach konfiguracyjnych listenera wybierano No Authentication. Pozostałe opcje to: HTTP Authentication, HTML Form Authentication oraz SSL ClientCertificate Authentication. Na Rys. 2. przedstawiony został wybór omawianych metod uwierzytelniania, realizowanych na serwerze TMG 2010.

****Rys. 2.****Opcje listenera związane z mechanizmami uwierzytelniania klienta.**

Serwer TMG 2010 nie posiada bazy, w której może zweryfikować poświadczenia użytkownika. Musi skorzystać z zewnętrznego weryfikatora. Może to być Active Directory, baza LDAP, serwer RADIUS lub serwer SecureID. Ilustracją weryfikacji poświadczeń w weryfikatorze przez TMG 2010 jest Rys. 3.

****Rys. 3.****Ilustracja uwierzytelniania TMG 2010 do weryfikatora.**

Wyboru weryfikatora dokonuje się również we właściwościach listenera. Opcje Authentication Validation Method pokazano na Rys. 4. Nie zawsze wszystkie metody będą dostępne, zależy to od wybranego protokołu uwierzytelniania oraz trybu pracy serwera TMG (w domenie lub grupie roboczej).

****Rys. 4.****Opcje związane z mechanizmami weryfikacji poświadczeń klienta.**

Omawianie problematyki rozpoczniemy od najprostszej metody, dostępnej dla wszystkich typów przeglądarek internetowych, metody HTTP Authentication. Zakłada ona przesyłanie poświadczeń bezpieczeństwa od klienta za pomocą jednego z mechanizmów: Basic, Digest lub Windows Integrated (Negocjowane/Kerberos/NTLM). Opcje związane z uwierzytelnianiem klienta znajdują się w zakładce Authentication listenera. Sytuacja ta przedstawiona została na Rys. 5.

****Rys. 5.****Opcje uwierzytelniania klienta definiowane na listenerze.**

Dla opcji HTTP Authentication dostępne są następujące metody uwierzytelniania klienta:

  • Basic,
  • Digest,
  • Integrated.

W zależności od wyboru protokołu uwierzytelniania, na listenerze dostępne będą różne warianty weryfikacji poświadczeń podanych przez klienta w weryfikatorze. Zagadnienie to ilustruje Tabela 1.

Tabela 1. Warianty weryfikacji poświadczeń podanych przez klienta w weryfikatorze.

Uwierzytelnianie na listenerze Uwierzytelnianie na weryfikatorze
Basic Windows (ActiveDirectory), LDAP lub RADIUS
Digest Windows (ActiveDirectory) — wyłącznie
Integrated Windows (ActiveDirectory) — wyłącznie

Uwaga informacyjna

Mechanizmy Basic i Digest Authentication omówione są precyzyjnie w dokumencie RFC 2617— HTTP Authentication: Basic and Digest Access Authentication.

Uwierzytelnianie metodą BASIC

W celu włączenia uwierzytelniania metodą BASIC należy dokonać drobnej rekonfiguracji ustawień standardowych serwera TMG 2010. Z uwagi na niebezpieczeństwa związane z metodą BASIC, blokuje on domyślnie uwierzytelnianie. Hasło nie jest szyfrowane, ale przesyłane w formacie BASE-64, co jest bardzo proste do odkodowania. W przypadku metody Basic zaleca się dodatkowo włączenie komunikacji zaszyfrowanej metodą SSL. W poniższych przykładach, dla celów demonstracyjnych, nie będziemy korzystali z SSL. W przypadku próby uwierzytelniania metodą BASIC pojawiają się dwa komunikaty, które przedstawiono na Rys. 6. Pierwszy (błąd 12311) informuje, iż komunikacja nie jest objęta ochroną SSL, drugi (błąd 12320) informuje o blokowaniu przekazywania poświadczeń po protokole HTTP.


****Rys. 6.****Standardowe zachowanie serwera TMG 2010. Blokowanie komunikacji wymagającej uwierzytelniania oraz nieobjętej ochroną SSL.**

W celu włączenia przekazywania poświadczeń przez protokół HTTP w trybie BASIC należy kliknąć na zakładkę Authentication, na przycisk Advanced… i zaznaczyć opcję Allow client authentication over HTTP. Jeżeli chcemy dodatkowo wymusić, aby wszyscy użytkownicy musieli się uwierzytelniać, włączamy również opcję Require all users to authenticate. Obie zaznaczone opcje przedstawiono na Rys. 7.

Włączenie zezwolenia na uwierzytelnianie metodą BASIC po protokole HTTP

****Rys. 7.****Włączenie zezwolenia na uwierzytelnianie metodą BASIC po protokole HTTP.**

Po dokonaniu tej zmiany zostaniemy poinformowani, iż powinniśmy, ze względów bezpieczeństwa, skojarzyć z metodą BASIC szyfrowanie SSL, ale jak wspomniano wcześniej — celowo wyłączamy tutaj szyfrowanie. Komunikat informacyjny zaprezentowano na Rys. 8.

Komunikat informujący o zaleceniu włączenia szyfrowania w oparciu o certyfikat SSL

****Rys. 8.****Komunikat informujący o zaleceniu włączenia szyfrowania w oparciu o certyfikat SSL.**

Pierwsza próba połączenia z serwerem zostanie odrzucona z komunikatem błędu numer 401 Unauthorized. Jest to standardowe zachowanie, gdyż trzeba przekazać klientowi, iż serwer obsługuje, określoną metodą, wyłącznie komunikację uwierzytelnioną. Przykład ten został zaprezentowany na Rys. 9.

Przechwycona komunikacja pomiędzy klientem a serwerem wymagającym uwierzytelnienia

****Rys. 9.****Przechwycona komunikacja pomiędzy klientem a serwerem wymagającym uwierzytelnienia.**

Przeglądarka internetowa wyświetli okno logowania. Rys. 10. ilustruje ten przykład. Po lewej stronie można zobaczyć okno wyświetlane przez systemy i przeglądarki starszego typu, po prawej przez systemy nowszej generacji.

 

****Rys. 10.****Okno logowania przy włączonej metodzie uwierzytelniania HTML — BASIC.**

Podane hasło zostanie przetworzone na format Base64 i wysłane do serwera. Przykładowa, przechwycona komunikacja zaprezentowana została na Rys. 11.

Przykładowa, przechwycona komunikacja przy metodzie uwierzytelniania HTML — BASIC

****Rys. 11.****Przykładowa, przechwycona komunikacja przy metodzie uwierzytelniania HTML — BASIC.**

Uwaga informacyjna

Linia Credentials (w postaci rozszyfrowanego ciągu znaków) w rzeczywistości nie jest przysyłana. Linię tę samodzielnie dodaje analizator sieci, np. WireShark.

Po prawidłowym uwierzytelnieniu i weryfikacji klienta w Active Directory, serwer wyśle do przeglądarki treść strony, do której chcemy uzyskać dostęp.

Uwierzytelnianie Digest/WDigest

Uwierzytelnianie Digest dostępne jest już od wersji Windows 2000. Rozróżniamy dwie wersje: Digest i Advance Digest (Wdigest). W środowisku opartym na kontrolerach domeny, zbudowanych na Windows Server 2000, lub w środowisku mieszanym 2000/2003 wykorzystywana jest wersja określana jako Digest. W przypadku, gdy kontrolerami domeny są wyłącznie serwery Windows Server 2003 i późniejsze, wykorzystywana jest metoda Advance Digest (Wdigest). Metoda ta korzysta z funkcji skrótu MD5 (zamiast MD4 w zwykłym Digest) oraz wykorzystuje  dodatkowy element kryptograficzny, określany jako nonce. Więcej informacji dostępnych jest w dokumencie RFC 2617. Dodatkowo, przy korzystaniu z metody Digest wymagane jest zapisywanie haseł metodą szyfrowania odwracanego (ang. Store password usingreversible encryption**).

Przykładowe okno uwierzytelniania metodą Digest lub WDigest zaprezentowano na Rys. 12. Po lewej stronie można zobaczyć okno wyświetlane przez systemy i przeglądarki starszego typu, po prawej przez systemy nowszej generacji.

Przykładowa, przechwycona komunikacja przy metodzie uwierzytelniania HTML — BASIC Okno logowania przy włączonej metodzie uwierzytelniania HTML — Digest

**Rys. 12.****Okno logowania przy włączonej metodzie uwierzytelniania HTML — Digest.

Analogicznie do metody Basic, pierwsza próba połączenia z serwerem zostanie odrzucona z komunikatem błędu numer 401 Unauthorized.  Jest to standardowe zachowanie, gdyż trzeba przekazać klientowi, iż serwer obsługuje określoną metodą wyłącznie komunikację uwierzytelnioną. Na Rys. 13. zaprezentowano fragment żądania uwierzytelniania metodą WDigest, wysyłany wraz z komunikatem 401 Unauthorized, zaś na Rys. 14. odpowiedź – uwierzytelnienia użytkownika jan.kowalski.

Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą WDigest – komunikacja od serwera do klienta

Rys. 13. Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą WDigest – komunikacja od serwera do klienta.**

 Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą WDigest – odpowiedź klienta

Rys. 14. Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą WDigest – odpowiedź klienta.**

Uwagi dodatkowe związane z uwierzytelnianiem metodą Digest lub WDigest:

  • Funkcjonalność WDigest dostępna jest wyłącznie na poziomie funkcjonalności domeny — NATIVE 2003 i wyższych.
  • Jeżeli kontrolery domeny pracują w oparciu o serwery Windows 2003 i nowsze, to system konfiguruje się domyślnie w trybie WDigest.
  • Serwer TMG 2010 musi być członkiem domeny Active Directory, gdyż jedynym weryfikatorem, przy metodzie Digest/WDigest, jest Active Directory. Uwierzytelnianie Digest/WDigest nie będzie dostępne w przypadku, gdy serwer TMG jest członkiem grupy roboczej. Nie ma wymagań na członkostwo stacji roboczej w domenie.
  • Mechanizm uwierzytelniania Wdigest jest jedynym, w którym zarówno w nazwie użytkownika, jak i w nazwie domeny rozpoznawane są duże i małe litery. Jest to sytuacja odwrotna niż w innych metodach uwierzytelniania, gdzie znaki są rozpoznawane wyłącznie w haśle.

Uwierzytelnianie Windows Integrated Authentication

Kolejną metodą uwierzytelniania jest Windows Integrated Authentication. Tej metody używa się, korzystając z protokołów NTLM, Kerberos lub GSAPI (Negocjowane), w zależności od tego, czy mamy bezpośredni dostęp do kontrolera domeny, czy nie. Standardowo, spoza sieci wewnętrznej, takiego dostępu mieć nie będziemy, zatem uwierzytelnianie realizowane będzie praktycznie wyłącznie w oparciu o protokół NTLM w wersji 1 lub 2. Przykładowe okno logowania metodą Windows Integrated przedstawiono na Rys. 15. Po lewej stronie, można zobaczyć okno wyświetlane przez systemy i przeglądarki starszego typu, po prawej przez systemy nowszej generacji.

Okno logowania przy włączonej metodzie uwierzytelniania HTML — Windows Integrated Okno logowania przy włączonej metodzie uwierzytelniania HTML — Windows Integrated

****Rys. 15.****Okno logowania przy włączonej metodzie uwierzytelniania HTML — Windows Integrated.**

Analogicznie, jak przy użyciu metody Basic, pierwsza próba połączenia z serwerem zostanie odrzucona z komunikatem błędu numer 401 Unauthorized.  Jest to standardowe zachowanie, gdyż trzeba przekazać klientowi, iż serwer obsługuje określoną metodą wyłącznie komunikację uwierzytelnioną. Na Rys. 16. zaprezentowano fragment żądania uwierzytelniania metodą Windows Integrated, wysyłany wraz z komunikatem 401 Unauthorized, zaś na Rys. 14 odpowiedź – uwierzytelnianie użytkownika jan.kowalski.

Więcej informacji na temat negocjacji protokołów uwierzytelniania opisano na witrynie: http://davenport.sourceforge.net/ntlm.html.

Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą Windows Integrated – komunikacja od serwera do klienta

Rys. 16. Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą Windows Integrated – komunikacja od serwera do klienta.**

Na Rys. 17. przedstawiono odpowiedź klienta. Klient wysyła w odpowiedzi wynegocjowane elementy, służące uwierzytelnianiu, są to komunikaty NTLM Response i NTLMv2 Response. Serwer nie wspiera już uwierzytelniania LM – stąd komunikat Lan Manager Response zawiera zera.

Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą Windows Integrated – odpowiedź klienta

Rys. 17. Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą Windows Integrated – odpowiedź klienta.**

* *

Uwierzytelnianie oparte na formularzach (HTML Form-Based)

Najnowszym rozwiązaniem, umożliwiającym uwierzytelnianie klienta, jest wykorzystanie formularzy przewidzianych w języku HTML oraz plików cookie. Serwer TMG 2010 posiada predefiniowane formularze, które mogą być wykorzystane w tym celu. Wyboru uwierzytelniania, opartego o formularze, dokonuje się również w opcjach Listenera, w zakładce Authentication. Zamiast opcji HTTP Authentication, wybieramy HTML Form Authentication. Zakładka umożliwia również pobieranie od klienta dodatkowych informacji (zaznaczona opcja Collect additional delegation credentials in the form —jest ona jednak związana z uwierzytelnianiem klienta poprzez mechanizm Token RSA ID lub RADIUS OTP, i nie będzie w tej części  omawiana).

Wybór właściwej opcji zaprezentowano na Rys. 18. Serwer TMG 2010 będzie mógł weryfikować podane przez klienta dane w dowolnym z dostępnych weryfikatorów,  bez zaznaczenia wspomnianej wyżej opcji.

Opcje uwierzytelniania metodą HTML Form Authentication

****Rys. 18.****Opcje uwierzytelniania metodą HTML Form Authentication.**

Na Rys. 19. przedstawiono przykładowe okno logowania przy włączonej metodzie uwierzytelniania HTML Form Authentication.

Okno logowania przy włączonej metodzie uwierzytelniania HTML Form Authentication

****Rys. 19.****Okno logowania przy włączonej metodzie uwierzytelniania HTML Form Authentication.**

Na Rys. 20. i Rys. 21 zaprezentowano przechwyconą komunikację — sesja HTTP uwierzytelniana metodą Form - Based.

Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą Form Based – komunikacja od serwera do klienta

Rys. 20. Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą Form Based – komunikacja od serwera do klienta.

Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą Form Based – odpowiedź klienta

Rys. 21. Przechwycona komunikacja — sesja HTTP uwierzytelniana metodą Form Based – odpowiedź klienta.**

Uwaga informacyjna

Proszę zwrócić uwagę, iż formularz przekazuje do serwera nazwę użytkownika oraz hasło w postaci jawnego tekstu. Zatem ta metoda uwierzytelniania powinna być zawsze zabezpieczona komunikacją szyfrowaną SSL (HTTPS) lub IPSec.

Predefiniowane typy formularzy serwera ISA

Serwer TMG 2010 posiada dwa predefiniowane formularze dla uwierzytelniania metodą form-Based:

  • ISA— formularz ogólnego przeznaczenia, najwcześniej wykorzystywany przy uwierzytelnianiu do serwerów WWW, przy regułach publikacji oraz w konfiguracji listenerów (nazwę folderu zachowano z poprzedniej wersji produktu - ISA).
  • Exchange— zawiera definicję formularza w języku HTML, wykorzystywana jest przy uwierzytelnianiu w serwerze Exchange (OWA — Outlook Web Access).

Formularze na serwerze TMG 2010 pogrupowane są w zależności od typu klienta, który z danego formularza będzie korzystał:

  • HTML— standardowe przeglądarki internetowe.
  • cHTML— przeglądarki wspierające standard cHTML, jak urządzenia mobile.
  • XHTML-Mobile Profile (XHTML-MP) — urządzenia wspierające standard xhtml-mp, np. palmtopy z systemem Microsoft Windows Mobile.

*** ***

Struktura katalogów

Wszystkie elementy formularzy umieszczone są wewnątrz folderu zawierającego pliki serwera TMG 2010, w katalogach o strukturze pokazanej na Rys. 22.

Struktura katalogów predefiniowanych formularzy, wykorzystywanych do uwierzytelniania

****Rys. 22.****Struktura katalogów predefiniowanych formularzy, wykorzystywanych do uwierzytelniania.**

Każdy formularz zawiera katalog z plikami w formacie HTML (pliki .htm). Kiedy serwer TMG 2010 wyświetla formularz, następuje podstawienie zmiennych wewnątrz formularza, zgodnie z wybraną wersją językową na ciągi znaków, które umieszczane są w pliku strings.txt, w folderze o nazwie odpowiedniej dla kodu języka. Przeglądarka internetowa może wysyłać do serwera kod języka, tak aby serwer w odpowiedzi wyświetlił formularz prawidłowo. Jeżeli nie można określić języka, wyświetlany jest formularz w języku angielskim.

Uwaga informacyjna

Niestety kod Polski (język polski) jest błędnie zdefiniowany: zamiast pl jest po. Błąd ten występuje również w serwerze ISA 2006 i do dnia dzisiejszego nie został poprawiony. Należy skopiować zawartość folderu pl do po i zrestartować usługę TMG Firewall.

Uwaga informacyjna

Modyfikacje formularzy są opisane na stronach Web Microsoft Technet pod poniższym adresem internetowym https://technet.microsoft.com/en-us/library/bb794733.aspx.

*** ***

Zaawansowane ustawienia formularza

Wybór formularza użytkownika odbywa się w zakładce Forms listenera (Rys. 23.), podając samą jego nazwę, a bez ścieżki dostępu. Dodatkowo, można wymusić wyświetlanie formularza w określonym języku. Wyświetlany jest on domyślnie w języku angielskim. Na rysunku wybrano formę o nazwie Firmowa oraz zaznaczono opcję wyświetlania formularza w języku polskim.

Zaawansowane ustawienia uwierzytelniania metodą Form Based

****Rys. 23.****Zaawansowane ustawienia uwierzytelniania metodą Form Based.**

Uwierzytelnianie metodą opartą na formularzach posiada szereg zalet w stosunku do uwierzytelniana metodą BASIC. Pozwala na kontrolę czasu nieaktywności użytkownika i jego automatyczne wylogowywanie. Opcje te dostępne są w zakładce pojawiającej się po kliknięciu przycisku Advanced… Opcje zaawansowane przedstawione zostały na Rys. 24.

  • Cookie Settings — obsługa Cookiem,
  • Client Security Settings — ustawienia bezpieczeństwa klienta (czas trwania sesji).

Opcje zaawansowane związane z formularzem

Rys. 24.Opcje zaawansowane związane z formularzem.

Na Rys. 25. przedstawiono przykładowy formularz wyświetlany w języku polskim.

Przykładowy formularz wyświetlany w języku polskim

****Rys. 25.****Przykładowy formularz wyświetlany w języku polskim.**

Formularz posiada również opcje dodatkowe: zmianę hasła użytkownika oraz przypomnienie - za ile dni wygaśnie hasło. Opcje te pokazane są na Rys. 26.

Opcje związane ze zmianą hasła poprzez formularz

****Rys. 26.****Opcje związane ze zmianą hasła poprzez formularz.**

Na Rys. 27. przedstawiono przykładowy formularz wyświetlany w języku polskim, z włączoną opcją zmiany hasła.

Przykładowy formularz wyświetlany w języku polskim z włączoną opcją zmiany hasła

****Rys. 27.****Przykładowy formularz wyświetlany w języku polskim z włączoną opcją zmiany hasła.**

Dla osób chcących przeprowadzić modyfikację form wykorzystywanych przy uwierzytelnianiu, dostępny jest darmowy edytor, do pobrania z witryny http://blogs.platani.nl/downloads.php. Przykładową stronę edycyjną pokazano na Rys. 28.

Edytor form uwierzytelniania dla ISA/TMG

****Rys. 28.****Edytor form uwierzytelniania dla ISA/TMG.**

Podsumowanie

W tym artykule omówiono zagadnienia uwierzytelniania metodami: Basic, Digest (WDigest), Windows Authentication oraz Form Based, realizowanymi na serwerze TMG 2010.

W następnej części naszego cyklu omówione zostaną zagadnienia uwierzytelniania z wykorzystaniem certyfikatów oraz elementy przekazywania poświadczeń przez serwer TMG do serwerów docelowych.