Zwiększenie bezpieczeństwa TS Gateway za pomocą serwera ISA Server 2006

Autor: Dr. Thomas W. Shinder i Yuri Diogenes

Opublikowano: 5 grudnia 2008

Zawartość strony

	Poza zakresem
	Pierwszy scenariusz
	Konfiguracja serwera ISA Server 2006
	Testowanie i monitorowanie dostępu klientów
	Monitorowanie z poziomu ISA Server
	Drugi scenariusz
	Co będzie z klientem?

Po sukcesie, jaki odniósł Outlook Anywhere w Exchange Server 2007, Windows Server 2008 daje z kolei możliwość dostępu do komputera biurkowego z dowolnego miejsca, w bezpieczny i kontrolowany sposób.

Nowa usługa Terminal Server Gateway (TS Gateway) w Windows Server® 2008 oferuje elastyczność usług Windows® Terminal Server Services wraz z możliwością połączenia przez HTTP z serwerem terminala (Terminal Server) z dowolnego miejsca. Usługa ta korzysta z protokołu RDP (Remote Desktop Protocol) przez HTTPS (SSL), aby zwiększyć bezpieczeństwo przy zapewnieniu pojedynczemu klientowi interfejsu dostępu do zasobów Usług terminala.

Nowa usługa TS Gateway oferuje znaczące korzyści tym, którzy chcą mieć zdalny dostęp do swoich komputerów:

• Nie trzeba ustanawiać sesji VPN (Virtual Private Network) przed połączeniem za pomocą RDP z wewnętrznymi zasobami.
• Bezpieczeństwo jest zwiększone za pomocą NAP (Network Access Protection) oraz Windows Security Health Checks sprawdzające połączenia RDP.
• Nie ma potrzeby otwierania portu wejściowego TCP 3389, aby umożliwić bezpieczniejsze publikowanie w sieci Web przez zapory sieciowe.

Można korzystać z Microsoft® Internet Security oraz Acceleration (ISA) Server 2006, aby zwiększyć bezpieczeństwo usługi bramy TS, pozwalając jednocześnie na zewnętrzny dostęp do wewnętrznych zasobów. Można ustawić most według scenariusza SSL-to-SSL, w którym serwer ISA Server 2006 otrzymuje żądanie i przekazuje je do wewnętrznej bramy TS, także za pomocą HTTPS. Podczas zestawiania żądania, zapora sieciowa ISA odszyfrowuje połączenie SSL i wykonuje sprawdzenie na poziomie warstwy aplikacji.

Jeśli strumień protokołu HTTP przejdzie inspekcję, to połączenie jest ponownie szyfrowane i przekazywane do proxy usług terminala. Jeśli strumień protokołu nie przejdzie kontroli, połączenie zostaje przerwane.

Poza zakresem

Microsoft zainwestował wiele wysiłku na rzecz bezpieczeństwa, zaś Windows Server 2008 jest, jak do tej pory, najbezpieczniejszą i najbardziej rozbudowaną wersją Windows. Jednak firma interesuje się także sposobem, w jaki użytkownicy implementują jej produkty i przestrzeganiem przez nich najlepszych praktyk w celu zabezpieczenia swoich środowisk. Najlepsze praktyki wymagają dogłębnego podejścia do ochrony, co zapewnia ochronę w wielu punktach dostępu i warstwach. Warstwami, których dotyczy nasze omówienie są zasady, procedury i czujność; otoczenie zewnętrzne; sieć wewnętrzna i host.

Gdy pozwolimy zewnętrznym użytkownikom na dostęp do wewnętrznych zasobów za pośrednictwem serwera ISA Server 2006, trzeba zrozumieć ograniczenia każdego z używanych produktów. ISA Server 2006 oraz TS Gateway zapewniają bezpieczeństwo w warstwie zewnętrznej (Perimeter layer), natomiast dla zasobów wewnętrznych trzeba wprowadzić zasady, które w miarę potrzeb zezwalają na dostęp lub nie. Zasady sieci (Network Policy) oraz Usługi dostępu NPAS (Access Services) pozwalają na to, działając w warstwie Zasad, procedur i czujności (Policies, Procedures and Awareness layer). Dostęp do wewnętrznych zasobów (stacji dysków, schowka, drukarek itp.) jest określony przez Zasady autoryzacji usług terminala (Terminal Service Resource Authorization Policies), odnoszące się do warstwy sieci wewnętrznej.

W tym artykule zajmiemy się najpierw sposobem publikowania Terminal Services Gateway przez ISA Server 2006. Następnie tak rozszerzymy scenariusz publikowania ISA Server 2006, aby obejmował wdrożenie zdrowia klienta za pomocą NAP. Dzięki korzystaniu z NAP możemy utworzyć zasady zdrowia klienta, które pomogą nam na kontrolę dostępu w warstwie hosta (Host Layer).

 Do początku strony

Pierwszy scenariusz

Naszym celem jest pokazanie, jak przekazać TS Gateway przez ISA Server 2006. Rysunek 1 pokazuje wszystkie komputery i przepływ danych podczas połączenia. W tym scenariuszu implementujemy rolę NPS (Network Policy Server) na samej bramie TS Gateway; jednak zmienimy to w drugim scenariuszu, gdzie wykorzystamy centralny serwer NPS. Prześledźmy poniższą sekwencję, aby zrozumieć, jak działa połączenie pomiędzy komponentami rozwiązania z TS Gateway:

Rysunek 1: Publikowanie TS Gateway przez ISA Server 2006.

1. Zewnętrzny użytkownik RDP inicjuje połączenie. Pierwszą czynnością, którą musi wykonać, klient jest pobranie zewnętrznej nazwy bramy TS Gateway (w tym przypadku tsg.contoso.com). Zewnętrzny DNS znajduje nazwę, która wskazuje zewnętrzny adres IP serwera ISA.
2. Zostaje ustanowiony tunel SSL pomiędzy klientem RDP a zewnętrznym interfejsem serwera ISA. Serwer ISA ma zasadę publikowania w sieci przez port TCP 443, który korzysta z certyfikatu wydanego dla tsg.contoso.com.
3. Po sprawdzeniu zasady i stwierdzeniu, że ruch jest dozwolony, serwer ISA wysyła zapytanie DNS do wewnętrznego serwera DNS (umieszczonego w kontrolerze domeny), aby określić nazwę serwera podanego w zasadzie publikowania w sieci.
4. Serwer ISA otwiera następnie tunel SSL do bramy TS Gateway i przekazuje jej żądanie uwierzytelnienia.
5. Serwer bramy TS Gateway sprawdza uprawnienia użytkownika i sprawdza, czy użytkownik ma autoryzację do ustanowienia połączenia.
6. Po stwierdzeniu, że użytkownik ma autoryzację do ustanowienia połączenia, usługa bramy TS Gateway otrzymuje żądanie na porcie TCP 443 i przekazuje pakiety RDP przez port TCP 3389 (domyślnie) do wewnętrznego serwera terminala, gdzie znajduje się aplikacja (jak na przykład aplikacja CRM).

Od tego momentu wszystkie pakiety wysłane przez klienta RDP do usługi bramy TS Gateway przez serwer ISA, są przekazywane do wewnętrznego serwera terminala i vice versa.

Warto zauważyć, że RDP przez HTTPS w tle oznacza po prostu połączenie RDP/RPC/HTTPS. Klient RDP enkapsuluje komunikację RDP w nagłówku RPC, który z kolei jest enkapsulowany w nagłówku HTTP zabezpieczanym za pomocą SSL (lub Transport Level Security, TLS). Wszystkie komponenty potrzebne do rozwiązania RPC przez HTTPS muszą być obecne. Dlatego właśnie podczas instalacji usługi roli bramy TS Gateway automatycznie instaluje ona proxy RPC przez HTTP. Aby lepiej zrozumieć działanie tego protokołu, polecamy lekturę pracy „Testing RPC over HTTP through ISA Server 2006 Part 1; Protocols, Authentication and Processing”, którą można znaleźć na blogu zespołu ISA Server (dostępnym pod adresem blogs.technet.com/isablog).

Implementacja ta wymaga Windows Server 2008 z zainstalowaną usługą Terminal Service Gateway, zaś funkcja ta jest zależna od RPC przez proxy HTTP. Aby funkcja RDP przez RPC poprzez proxy HTTP działała, wymagana jest zainstalowana i działająca usługa Internet Information Services (IIS) 7.0. Potrzebne są także Zasady sieci (Network Policy) i Usługi dostępu (Access Services). Możemy też tak skonfigurować bramę TS Gateway, aby korzystała z serwera NTS, znanego wcześniej jako Internet Authentication Services (IAS), w celu scentralizowania pamięci, zarządzania i sprawdzenia zasad Terminal Services Connection Authorization Policies (TS CAPs). Wreszcie trzeba uzyskać certyfikat SSL dla serwera bramy TS Gateway, jeśli go jeszcze nie mamy. Warto podkreślić, że serwer ISA Server 2006 musi ufać urzędowi certyfikacji (CA) wydającemu certyfikat. Dlatego trzeba koniecznie zaimportować certyfikat do zaufanego składu Trusted Root Certificate Authorities Store.

Usługa Active Directory® Domain Services jest konieczna tylko wtedy, gdy konfigurujemy zasady autoryzacji bramy TS Gateway, które wymagają, aby w celu połączenia się z serwerem bramy TS Gateway, użytkownicy byli członkami grupy zabezpieczeń Active Directory. Dla tej konkretnej konfiguracji będziemy korzystać z Active Directory na komputerze działającym w systemie Windows Server 2003 SP2.

Po zakończeniu instalacji usługi bramy Terminal Services Gateway pojawia się ekran pokazany na rysunku 2, pokazując zainstalowane komponenty. Aby połączyć bramę TS Gateway, klienci muszą działać w jednym z podanych systemów: Windows Vista®; Windows XP z SP2 oraz RDP 6.0 lub w wersja późniejsza; Windows Server 2008; Windows Server 2003 z SP1 lub wersja późniejsza oraz RDP 6.0 lub nowszym. Więcej informacji na temat konfiguracji TS Gateway można uzyskać w przewodniku Windows Server 2008 TS Gateway Server Step-By-Step Setup Guide, dostępnym na witrynie go.microsoft.com/fwlink/?LinkId=122251. Popatrzmy teraz, jak skonfigurować ISA Server 2006.

Rysunek 2: Podsumowanie instalacji TS Gateway.

 Do początku strony

Konfiguracja serwera ISA Server 2006

Pierwszy krok stanowi utworzenie Web Listener, który obsługuje żądania pochodzące od zewnętrznego klienta RDP. Nasz Web Listener ma następujące parametry:

• Uwierzytelnienie: podstawowe
• Sprawdzenie uwierzytelnienia: Windows (Active Directory)
• Połączenia: włączenie połączeń SSL (HTTPS) na porcie 443
• Certyfikaty: certyfikat wydany dla tsg.contoso.com
• Sieci: zewnętrzne

Następnie trzeba utworzyć zasadę publikacji w sieci. Z perspektywy serwera ISA Server 2006, klient RDP będzie korzystał z tego samego protokołu, z którego korzysta Outlook® Anywhere, należy więc wybrać kreator Exchange Server 2007. Po prostu wykonujemy poniższe kroki:

1. Klikamy prawym przyciskiem na Zasady zapory (Firewall Policy), wybierany Nowy (New), a następnie klikamy zasadę publikowania Exchange Web Client Access.
2. Na stronie powitania (Welcome to the Create a New Web publishing rule) wpisujemy nazwę zasady i klikamy Dalej (Next).
3. Na stronie Wybierz działanie zasady (Select Rule Action) wybieramy opcję Zezwól (Allow) i klikamy Dalej.
4. Na stronie publikacji zasad New Exchange, wybieramy wersję Exchange – w naszym przypadku Exchange Server 2007. Wybieramy Outlook Anywhere (RPC/HTTP(s)) i klikamy dalej (Uwaga: nie należy wybierać opcji klienta Publikuj dodatkowe foldery w Exchange Server for Outlook 2007).
5. Na stronie Rodzaj publikacji (Publishing Type), wybieramy opcję publikacji pojedynczej witryny lub równoważenia obciążenia i klikamy Dalej.
6. Na stronie Zabezpieczenie połączenia z serwerem (Server Connection Security), wybieramy Użyj SSL (Use SSL), aby połączyć się z serwerem publikowanej witryny lub farmą serwerów, a następnie klikamy Dalej.
7. Na stronie Szczegóły wewnętrznego publikowania (Internal Publishing Details), w polu nazwy Lokalizacja wewnętrzna (Internal site), wpisujemy nazwę serwera bramy TS Gateway. Wybieramy pole wyboru Użyj nazwy komputera lub adresu IP, aby połączyć się z publikowanym serwerem (Use a computer name or IP address to connect to the published server), a następnie w polu Nazwa komputera lub adres IP (Computer name or IP address) wpisujemy nazwę serwera. Jeśli nie znamy nazwy serwera bramy TS, klikamy Przeglądaj (Browse), aby znaleźć jego lokalizację. Zauważmy, że nazwa używana na tej stronie musi być zgodna z nazwą zwykłą lub nazwą tematu na certyfikacie witryny powiązanej z witryną bramy TS.
8. Na stronie Szczegóły domeny publicznej (Public Name Details) wybieramy z rozwijanej listy Akceptuj żądania (Accept requests), Nazwa tej domeny (This domain name) (poniżej), a następnie w polu Nazwa publiczna (Public name) wpisujemy nazwę publiczną, która pasuje do nazwy certyfikatu wydanego dla tego URL – w naszym przypadku nazwa jest tsg.contoso.com. Następnie kliknij Dalej.
9. Na stronie Wybierz Web Listener (Select Web Listener) klikamy rozwijaną listę i wybieramy wcześniej utworzony Web Listener, a następnie klikamy Dalej.

Na stronie Delegowanie uwierzytelniania (Authentication Delegation) wybieramy opcję Bez delegowania, ale klient może uwierzytelnić się bezpośrednio (No delegation, but client may authenticate directly), a następnie klikamy Dalej.

Na stronie Ustawienia użytkownika (User Set), sprawdzamy, czy jest wybrana domyślna opcja Wszyscy użytkownicy (All Users), a następnie klikamy Dalej i Zakończ, aby zastosować wybrane opcje.

Jeśli klikniemy dwukrotnie na zasadzie i przejdziemy do zakładki Ścieżka (Path), zobaczymy, że jedyną dostępną ścieżką jest /rpc/*. Wynika to z faktu, że korzystaliśmy z kreatora Exchange Server 2007 Outlook Anywhere Wizard.

 Do początku strony

Testowanie i monitorowanie dostępu klientów

Jak już wspomniano, aby połączyć się z brama TS, trzeba mieć klienta RDP 6.0 lub wersję późniejszą. Aby skonfigurować aplikację klienta RDP, trzeba go uruchomić i wpisać w polu Komputer (Computer) nazwę serwera terminala, z którym chcemy się połączyć. Klikamy przycisk Opcje (Options), zakładkę Zaawansowane (Advanced), a następnie Ustawienia (Settings) i wpisujemy zewnętrzną nazwę serwera bramy TS, jak na rysunku 3. W naszym przykładzie jest to nazwa na certyfikacie przypisanym do programu Web Listener używanego przez zasadę publikacji w sieci do akceptacji przychodzących zadań. Zauważmy, że w tym przykładzie używane jest uwierzytelnienie Windows NT® LAN Manager. Po zakończeniu klikamy OK, a następnie Połącz (Connect). Otrzymamy zgłoszenie uwierzytelnienia. Wpisujemy uprawnienia użytkownika z dostępem do serwera terminala i klikamy OK.

Rysunek 3: Konfigurowanie klienta RDP.

Zauważmy, że klient RDP 6.0 (dla Windows XP i Windows Server 2003) pokaże ekran z rysunku 3. Dwukrotnie otrzymamy pytanie o uwierzytelnienie – pierwsze uwierzytelnienie jest dla komputera bramy TS, a drugie dla serwera terminala, do którego chcemy mieć dostęp. Jest to ważna informacja, gdyż można by pomyśleć, że wynika to z konfiguracji serwera ISA, lecz serwer ISA nie obsługuje w ogóle uwierzytelnienia, gdyż reguła publikacji w sieci dotyczy „Wszystkich użytkowników”, co pozwala na anonimowe połączenia przez zaporę sieciową ISA.

Klient RDP, który jest dostarczany z Windows Server 2008, ma uprawnienia do używania bramy TS (Use my TS Gateway) dla zdalnego komputera, co widać na rysunku 4. Mając wybrana te opcję, nie trzeba dwukrotnie wpisywać uprawnień, co poprawia sytuację użytkownika. Ta opcja pojedynczego wpisu (single sign-on) jest też dostępna w Windows Vista po zastosowaniu SP1.

Rysunek 4: Klient Windows Server 2008 RDP.

Korzystając z opcji Monitoring, można monitorować połączenie przez menedżera bramy RS (TS Gateway Manager). Usługa TS Gateway podaje także szczegóły, gdy nieautoryzowany użytkownik próbuje połączyć się z serwerem. Na rysunku 5 Przeglądarka zdarzeń (Event Viewer) pokazuje próbę połączenia przez użytkownika, który nie ma zgody na połączenie przez bramę TS.

Rysunek 5: Zdarzenie zapisane w usłudze TS Gateway.

Dla tego zdarzenia jest rejestrowany wewnętrzny adres IP serwera ISA 2006, gdyż opcja Żądania opcji wydaje się pochodzić z komputera ISA (Requests appear to come from the ISA Server computer) jest włączona w zasadzie publikowania w sieci. Jeśli chcemy zarejestrować adres IP oryginalnego klienta, trzeba zmienić zasadę publikowania w sieci serwera ISA Server 2006 i wybrać na zakładce Do (To) opcję Żądania wydają się pochodzić z oryginalnego klienta (Requests appear to come from the original client).

 Do początku strony

Monitorowanie z poziomu ISA Server

Dzięki użyciu nowych funkcji pakietu ISA Server 2006 Supportability Pack, możliwe jest uważniejsze obserwowanie i zrozumienie każdego połączenia z wewnętrzną siecią. Rysunek 6 pokazuje jedno wyróżnione połączenie oraz na żądanie: linię, czasownik RPC_IN_DATA wskazujący URL dla RPC przez proxy HTTP.

Rysunek 6: Rejestracja ISA Server 2006 za pomocą aktualizacji Supportability.

Jeśli będziemy kontynuować rejestrację, powinniśmy zobaczyć inny czasownik RPC przez HTTP, RPC_OUT_DATA. Trzeba być świadomym, które metody HTTP są używane, czy RPC_IN_DATA i RPC_OUT_DATA dla RDP/HTTP, gdyż jeśli mamy skonfigurowane filtrowanie HTTP blokujące te metody, ruch zostanie zablokowany na serwerze ISA. Jeśli chcemy zamknąć swoje środowisko, można skonfigurować zasadę publikowania w sieci RDP/HTTP, która pozwoli na zastosowanie tylko tych dwóch metod. Więcej informacji na temat metod HTTP używanych zwykle do publikowania można znaleźć w artykule „HTTP Filtering in ISA Server 2004„, na witrynie technet.microsoft.com/library/cc302627.

 Do początku strony

Drugi scenariusz

W tym scenariuszu TS Gateway będzie korzystać z zasad NPS Central Policy umieszczonych na innym serwerze. Wprowadzimy zasady NAP dla klientów łączących się zdalnie przez bramę TS. Używane są tu te same komponenty, które były wykorzystywane w scenariuszu 1, a dodany jest serwer NPS. Jednak w związku z wprowadzeniem NPS, po stronie klienta będzie używanych więcej komponentów, co widać na rysunku 7.

Rysunek 7: Główne komponenty topologii scenariusza 2.

Oto objaśnienie poszczególnych komponentów. W kliencie Windows Vista System Health Agent (SHA) składa się z komponentów po stronie klienta odpowiedzialnych za monitorowanie i raportowanie stanu zdrowia klienta. Windows Vista zawiera Windows SHA, ale także inni producenci pracują nad utworzeniem swoich własnych SHA.

Agent NAP na kliencie jest odpowiedzialny za ustanowienie komunikacji z NAP Enforcement Server, gdy klient próbuje uzyskać dostęp do sieci. Agent NAP wysyła do serwera Oświadczenie o zdrowiu (Statement of Health, SoH).

Na TS Gateway zasada TS Resource Authorization Policy (TS RAP) jest komponentem, który pozwala na określenie, które komputery są dostępne do otrzymywania nadchodzących żądań RDP. TS RAP określa także, którzy użytkownicy będą mieli zgodę na ustanowienie połączeń RDP do określonych serwerów.

Centralny NPS jest odpowiedzialny za kontrolę warunków, ograniczeń i ustawień regulujących dostęp do wewnętrznych komputerów. Elementy oceny zdrowia systemu, System Health Validators (SHV) w centralnym NPS są odpowiedzialne za ocenę, czy SoH dostarczone przez klienta są zgodne z zasadami ustalonymi przez administratora.

Zmieńmy teraz TS Grateway tak, aby wskazywała centralny serwer NPS (NPS Central Server). Otwórzmy TS Gateway Manager Console, klikamy prawym przyciskiem myszy na nazwie serwera i wybieramy opcję Właściwości (Properties). W oknie właściwości serwera klikamy na zakładce TS CAP Store i wybieramy serwer centralny NPS. Następnie wpisujemy nazwę lub adres IP serwera NPS i klikamy przycisk Dodaj (Add). Zobaczymy wyskakujące okno Współdzielony sekret (Shared Secret). Wpisujemy sekret i klikamy OK, a następnie ponownie klikamy OK, aby zamknąć okno. Trzeba zapamiętać ten sekret, gdyż będzie on wykorzystywany na serwerze NPS.

Przyjmując, że NPS jest już zainstalowany na innym serwerze, należy wykonać podane niżej kroki:

1. Otwieramy konsolę Network Policy Server i w lewym okienku klikamy NPS (Local).
2. W prawym okienku klikamy Konfiguruj NAP (Configure NAP). Pojawi się strona Wybierz metodę połączenia z siecią do wykorzystania przez NAP (Select Network Connection Method for Use with NAP).
3. Poniżej Metoda połączenia z siecią (Network Connection Method), wybieramy z rozwijanego pola TS Gateway (Terminal Services Gateway) i klikamy Dalej (Next).
4. Na stronie Określ serwery wymuszania NAP korzystające z bramy TS (Specify NAP Enforcement Servers Running TS Gateway) klikamy przycisk Dodaj (Add).
5. W oknie Nowa brama TS (New TS Gateway) wpisujemy przyjazną nazwę i adres IP serwera bramy TS. A następnie, na dole okna wpisujemy współdzielony sekret, wykorzystując ten sam sekret, co podczas konfiguracji bramy TS. Klikamy OK.
6. Na stronie Konfiguruj metodę przekierowania urządzenia klienta i uwierzytelniania (Configure Client Device Redirection and Authentication Methods) można podać, które urządzenia będą przekierowane oraz określić dopuszczalną metodę uwierzytelniania (hasło lub inteligentna karta). Na potrzeby tego przykładu pozostawiamy opcje domyślne i klikamy Dalej.
7. Na stronie Konfiguruj grupy użytkowników i grupy maszyn (Configure User Groups and Machine Groups) dodajemy grupę użytkownika, która może ustanowić połączenie. W tym przykładzie klikamy przycisk Dodaj użytkowników (Add Users) pod Grupy użytkowników (Wymagane) (User Groups: (Required)), a następnie wybieramy Administratorzy domeny (Domain Admins) Klikamy OK, a następnie Dalej.
8. Zauważymy, że na stronie Definiuj zasady zdrowia NAP (Define NAP Health Policy), ż wybrana jest domyślna opcja SHV. Zauważmy też, że na dole tej strony zabroniono dostępu dla niezgodnych komputerów. Pozostawiamy wartości domyślne i klikamy Dalej.
9. Na stronie Uzupełnienie zasad wymuszenia NAP i konfiguracja klienta RADIUS (Completing NAP Enforcement Policy and RADIUS Client Configuration) oceniamy wcześniej wybrane opcje. Można też kliknąć na hiperłącze Szczegóły konfiguracji (Configuration Details), co spowoduje otwarcie strony HTML z podsumowaniem dokonanego wyboru. Na zakończenie klikamy Zakończ (Finish).

Kreator ten zajmuje się konfiguracją ustawień dla szeregu ważnych zasad jak Zasady żądania połączenia, Zasady sieci i Zasady zdrowia (Connection Request Policies, Network Policies, Health Policies), znacznie ograniczając pracę potrzebną na konfigurację NAP w ramach tego scenariusza.

 Do początku strony

Co będzie z klientem?

Gdy mamy teraz ustawiony i skonfigurowany serwer, co mamy zrobić z klientem?

Aby skorzystać z zasad wymuszenia NAP, klient musi mieć system Windows Server 2008 lub Windows Vista. Dla Windows XP trzeba zainstalować SP3, który zawiera klienta NAP.

Poza wymaganiami na system operacyjny istnieje kilka usług i ustawień, które trzeba włączyć po stronie klienta. Obejmują one następujące elementy:

• Dodanie nazwy serwera TS Gateway do listy Zaufane serwery (Trusted Server) w kliencie.
• Rozpoczęcie usługi Agent NAP (NAP Agent) i ustawienie sposobu uruchomienia usługi jako Automatyczny (Automatic).
• Włączenie wymuszenia kwarantanny bramy TS (TS Gateway Quarantine Enforcement) u klienta.

Aby uprościć wdrożenie tego rozwiązania, Microsoft utworzył polecenie konfiguracji klienta Usług terminala NAP (Terminal Services NAP) – Tsgqecclientconfig.cmd, które można załadować z witryny go.microsoft.com/fwlink/?LinkId=122267. Po wykonaniu tego polecenia, klient zostanie skonfigurowany jako klient wymuszenia NAP dla bramy TS. Zauważmy, że polecenie trzeba uruchomić z podwyższonymi uprawnieniami.

W całym tym artykule podstawowym założeniem było nie tylko opisanie i wyjaśnienie nowej funkcji TS Gateway, która jest dostępna w systemie Windows Server 2008 i pokazanie, jak bezpiecznie publikować przez ISA Server 2006, lecz także zapewnienie całościowego spojrzenia na zalety w zakresie bezpieczeństwa, jakie zapewnia firmie połączenie obu produktów.

W dzisiejszym świecie możliwość połączenia z dowolnego miejsca stanowi kluczowe wymaganie każdego udanego biznesu. Jednak konieczne jest także zapewnienie, aby ten sposób połączenia nie stał się dodatkowym problemem dla użytkownika. A jeszcze ważniejsze jest sprawienie, aby wykonać to w sposób zapewniający bezpieczeństwo.

O autorach

Dr. Thomas W. Shinder ma certyfikaty MCSE i ISA Server MVP. Od roku 1996 pracował jako szkoleniowiec w zakresie technologii, autor i konsultant. Jest autorem sześciu książek na temat ISA Firewall (zapory sieciowej ISA). Jest także uznanym liderem i głównym „sprawcą” ISAserver.org, największej społeczności administratorów ISA Firewall i osób poświęcających się Internetowi.

Yuri Diogenes, posiadający certyfikaty MCSE+S, MCTS, MCITP, Security+, Network+ i CCNP, jest inżynierem wspomagania zabezpieczeń w zespole Microsoft ISA Server/IAG. Pisze artykuły do Microsoft TechNet Library i na blogu ISA Server Team. Pracuje w dziale technologii firmy Microsoft od 1993 roku. Przedtem pracował jako szkoleniowiec, analityk obsługi i konsultant produktów Microsoftu.

Do początku strony