FAQ: Citrix Secure Gateway / NetScaler Gateway Secure Ticket Authority

Uwaga: te same zasady i koncepcje są dobre również dla NetScaler Gateway.

Ten artykuł odpowiada na najczęściej zadawane pytania dotyczące Citrix Secure Ticket Authority (STA). Pytania są podzielone na cztery kategorie:

przegląd

P: czym jest Secure Ticket Authority?
P: Jakie produkty Citrix wchodzą w interakcje z STA?
P: Dlaczego STA jest konieczne?
P: Jak wdrażana jest usługa STA?
Q: Czy istnieje wersja STA, która nie wymaga usług IIS?
P: Gdzie znajduje się serwer STA?
P: Jakie są różnice między różnymi wersjami STA?

bezpieczeństwo

P: W Jaki Sposób generowany jest bilet STA?
P: co stanowi bilet STA?
P: czy bilet jest sprawdzany na stacji roboczej?
P: czy bilet jest usuwany po użyciu?
P: czy bilety są kiedyś zapisywane na dysk w STA?
P: czy to możliwe, aby ktoś porwał bilet?
P: Jak chronić ruch STA za pomocą SSL?
Q: Czy STA musi być zawsze adresowane przy użyciu w pełni kwalifikowanej nazwy domeny?
P: Jak zmienić port STA z 80 na inny?
P: Czy atakujący może wysłać losowe bilety do bramki, aby się zalogować?
P: Jakie inne informacje są wymagane do logowania poza ważnym biletem STA?
P: Jak możemy ustawić czas życia biletu STA, po którym bilet powinien być nieważny?

skalowalność

p: ile STAs potrzebuję?
Q: Czy użytkownicy logują się rano przez bramę i uruchamiają jedną opublikowaną aplikację przez cały dzień, czy uruchamiają kilka aplikacji w ciągu dnia?
P: Jak mogę zapewnić odporność na błędy STA?
P: jak załadować balans wielu STAs?
P: Czy Mogę używać kilku STAs z równoważeniem obciążenia sieci Microsoft?
P: Czy Mogę współdzielić jeden STA z wieloma farmami, bramkami i serwerami wyliczeń?

Rozwiązywanie problemów

P: Jak skonfigurować IIS do hostowania STA?
P: Jak włączyć logowanie w STA?
Q: Dlaczego narzędzie Microsoft IISLockDown łamie STA?
P: Jak mogę przetestować STA, aby upewnić się, że działa poprawnie?
P: Jak interpretować pliki dziennika STA?
P: Jakie są typowe błędy konfiguracji widoczne w Pomocy Technicznej Citrix?

przegląd

P: Co to jest Secure Ticket Authority?

A: Secure Ticket Authority (Sta) to usługa internetowa XML, która wymienia informacje o serwerze XenApp dla losowo generowanych biletów. Służy do kontrolowania dostępu do serwera Citrix Secure Gateway.

P: Jakie produkty Citrix wchodzą w interakcje z STA?

A: XenMobile, Web Interface, StoreFront, XenApp Secure Access Manager, NetScaler Gateway i Citrix Secure Gateway współdziałają ze STA. W tym artykule, następujące typy serwerów są pogrupowane w jedną kategorię o nazwie serwery wyliczania aplikacji:

• interfejs sieciowy 2.0 lub nowszy
• Secure Access Manager 2.0 lub nowszy
• StoreFront
• serwery wyliczania aplikacji są odpowiedzialne za uwierzytelnianie użytkowników, wyliczanie opublikowanych ikon aplikacji i tworzenie pliku ICA dla klienta, który pozwala im połączyć się z opublikowaną aplikacją za pośrednictwem bezpiecznego serwera bramy.

P: Dlaczego STA jest konieczne?

A: we wdrożeniach Citrix Secure Gateway serwer bramy nie przeprowadza uwierzytelniania przychodzących żądań. Zamiast tego serwer bramy odkłada uwierzytelnianie na serwer wyliczania aplikacji i wykorzystuje STA, aby zagwarantować uwierzytelnienie każdego użytkownika. Serwery wyliczania aplikacji żądają biletów tylko dla użytkowników, którzy są już uwierzytelnieni na serwerze WWW. Jeśli użytkownicy mają ważne bilety STA, bramka zakłada, że przeszli testy uwierzytelniania na serwerze WWW i powinni mieć dostęp.

ten projekt umożliwia serwerowi Citrix Secure Gateway dziedziczenie wszelkich metod uwierzytelniania na serwerze WWW. Na przykład, jeśli serwer interfejsu WWW jest chroniony za pomocą SecurID RSA, tylko użytkownicy uwierzytelnieni za pomocą SecurID mogą przeglądać bezpieczny serwer bramy.

P: W Jaki Sposób wdrażana jest usługa STA?

A: Sta jest napisany jako rozszerzenie ISAPI dla Microsoft Internet Information Services (IIS). Rozszerzenie nazywa się CtxSta.dll i jest domyślnie hostowany w folderze / Scripts. Inne komponenty komunikują się ze STA za pomocą XML przez HTTP.

serwery wyliczania aplikacji żądają biletów w czasie uruchomienia aplikacji, wysyłając dane do STA w ramach żądania zgłoszenia. Dane przesyłane do STA zawierają adres serwera XenApp, z którym użytkownik będzie się łączył oraz, w przypadku Web Interface 2.0 i Secure Access Manager 2.0, rozszerzoną informację o nazwie bieżącego użytkownika i opublikowanej aplikacji, którą użytkownik chce uruchomić. STA odpowiada poprzez wygenerowanie biletu i odesłanie go z powrotem do serwera wyliczeń aplikacji. Ten bilet i odpowiadające mu dane pozostają w pamięci w STA przez konfigurowalną liczbę sekund (domyślnie 100).
serwer wyliczeń aplikacji konstruuje plik ICA dla użytkownika i wstawia bilet STA w polu adresu pliku ICA. Gdy klient łączy się z bezpieczną bramką, bilet jest prezentowany, a bramka powinna potwierdzić bilet przed ustanowieniem bezpiecznej sesji dla klienta. Gateway wykonuje żądanie danych, wysyłając bilet z powrotem do STA i prosząc o odpowiednie dane w zamian. Po pomyślnej walidacji STA przekazuje oryginalne dane do bramy, a Brama ustanawia przekaźnik między Użytkownikiem końcowym a serwerem XenApp.

zarówno żądania biletów, jak i żądania danych są realizowane jako dokumenty żądania/odpowiedzi XML.

P: czy istnieje wersja STA, która nie wymaga usług IIS?

A :nie, w tej chwili IIS jest wymagane do hostowania STA. Pamiętaj, że STA nie musi być narażony na niezaufaną sieć, taką jak Internet; STA znajduje się w zaufanej sieci i jest dostępny tylko przez serwery wyliczania bramek i aplikacji.

P: Gdzie znajduje się serwer STA?

A: serwer STA może być umieszczony w dowolnym miejscu, o ile do niego dotrze Bezpieczna Brama i serwery wyliczania aplikacji. Citrix zaleca umieszczenie STA w zaufanej sieci lub w oddzielnej części wewnętrznej zapory sieciowej, ale nie ma wymagań dotyczących serwera STA innego niż usługi IIS. STA nie musi należeć do żadnej domeny, farmy serwerów XenApp, farmy Secure Access Manager ani innego wewnętrznego serwera www, ale współdzielenie STA z inną funkcją jest powszechną praktyką. STA jest dołączany automatycznie jako część konfiguracji Secure Access Manager 2.0; wielu administratorów uważa, że wygodne jest zlokalizowanie STA na serwerze XenApp.

P: Jakie są różnice między różnymi wersjami STA?

A: nie ma istotnych różnic funkcjonalnych między wersjami 1.0 i 1.1, ale przy użyciu 2.0 STA z interfejsem Web 2.0 lub Secure Access Manager 2.0, rozszerzone informacje są dodawane do żądania zgłoszenia: nazwa użytkownika i aplikacja, którą użytkownik chce uruchomić. Te rozszerzone dane są wykorzystywane przez usługę gateway do wyświetlania szczegółów każdej sesji bramy w konsoli zarządzania Secure Gateway 2.0.

jeśli Secure Gateway 2.0 jest skonfigurowany tak, aby używać starszego standardu STA z wersji 1.1 lub 1.0, użytkownicy mogą łączyć się z aplikacjami, ale Konsola zarządzania Secure Gateway wyświetli „N/A” Dla nazwy użytkownika i nazwy aplikacji powiązanych z każdą sesją ICA. Aby zobaczyć rozszerzone informacje w Secure Gateway 2.0 konsola zarządzania, należy użyć wersji 2.0 lub nowszej STA i użyć albo Secure Access Manager 2.0 lub Web Interface 2.0 jako serwera wyliczania aplikacji.

bezpieczeństwo

P: Jak generowany jest bilet STA?

Odp: rozszerzenie ISAPI CtxSta.dll używa generowania liczb pseudolosowych do wytworzenia szesnastobajtowego ciągu szesnastkowego. Ze względów bezpieczeństwa Citrix nie ujawnia dokładnych kroków zastosowanych do wytworzenia tej losowej sekwencji znaków.

P: co stanowi bilet STA?

A: format kodowania jest ciągiem postaci:

;STA_VERSION;STA_ID; TICKET

gdzie:

• STA_VERSION jest polem numerycznym identyfikującym wersję STA. Obecnie jedynymi poprawnymi wartościami dla tego pola są „10 „dla wersji STA 1.0 i 1.1 oraz” 20 ” dla wersji STA 2.0.
• STA_ID jest sekwencją 0-16 znaków reprezentującą dowolną nazwę przypisaną przez Administratora do konkretnego STA. W Wersji 1.x, ten ciąg znaków domyślnie STA01, STA02 i tak dalej. Gdy STA jest instalowany automatycznie jako część Secure Access Manager 2.0, STA ID jest skrótem nazwy serwera. Gdy wiele Sta jest współdzielonych przez pojedynczy serwer bramy, każdy identyfikator STA musi być unikalny. Dzięki temu bramka może zlokalizować pracownika, który utworzył bilet, i wrócić do niego w celu zatwierdzenia biletu. Bilet utworzony na STA01 nie będzie istniał na STA02.
• TICKET jest losowo generowanym ciągiem 32 wielkich liter alfabetu lub znaków numerycznych.

  na przykład:
  ;10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

P: czy bilet jest sprawdzany na stacji roboczej?

A :nie, nic nie wiąże biletu z konkretną stacją roboczą. Teoretycznie możliwe jest żądanie zgłoszenia ze stacji roboczej A, a następnie wykorzystanie ze stacji roboczej B. Aby zmniejszyć to ryzyko:

• Zawsze używaj protokołu HTTPS między Klientem a serwerem wyliczania aplikacji, aby uniemożliwić atakującemu przechwycenie biletu podczas podróży z serwera do klienta.
• zredukuj czas trwania biletu tak bardzo, jak to możliwe, aby skrócić czas, w którym atakujący musiałby przenieść bilet z maszyny A do maszyny B.

pamiętaj, że bilet wystawiony przez STA może być użyty tylko raz, więc jeśli zamierzony użytkownik na maszynie a połączy się pomyślnie, bilet jest nieważny dla wszystkich przyszłych prób połączenia z maszyny a lub maszyny B.

P: czy bilet został usunięty po użyciu?

A: tak, paragony są usuwane natychmiast po pomyślnym żądaniu danych, więc mogą być użyte tylko raz. Są one również usuwane po konfigurowalnym czasie (domyślnie 100 sekund), jeśli nie są używane.

P: czy bilety są kiedykolwiek zapisywane na dysk w STA?

A: Tylko wtedy, gdy verbose logging jest włączone przez ustawienie LogLevel=3 w CtxSta.config. W przeciwnym razie STA przechowuje wszystkie zaległe bilety (bilety, które zostały zażądane przez serwer wyliczania aplikacji, ale nie zostały jeszcze zatwierdzone przez bezpieczną bramę) za pomocą bazy danych w pamięci. Dane XML są zawsze wysyłane do STA za pomocą polecenia HTTP POST, więc żadne znaczące dane biletu nie są nigdy zapisywane do dzienników serwera www Sta.

P: czy jest możliwe, aby ktoś porwał bilet?

A: podczas normalnej pracy bilet musi podróżować przez następujące cztery segmenty sieci:

• z serwera wyliczeń aplikacji
• z serwera wyliczeń aplikacji do klienta
• z Klienta do serwera bezpiecznej bramy
• z bramy do serwera STA

pierwszy i ostatni segment istnieje tylko pomiędzy serwerami w DMZ a STA na serwerze twoja zaufana sieć, co oznacza, że intruz musiałby mieć dostęp do twojej sieci, aby przechwycić bilet wzdłuż tych linii. Mimo to, ścieżki te mogą być szyfrowane za pomocą SSL, Jeśli używasz Secure Gateway w wersji 2.0. W Citrix Secure Gateway 1.1 i wcześniej ruch do STA nie może być szyfrowany przy użyciu protokołu SSL.

aby zabezpieczyć drugi segment, umieść certyfikat na serwerze internetowym wyliczenia aplikacji i Zezwalaj klientom na łączenie się tylko wtedy, gdy używają HTTPS. Trzeci segment jest zawsze zabezpieczony SSL.

nawet jeśli wszystkie poprzednie linki są zabezpieczone SSL, klienci są nadal podatni na ataki trojanów monitorujących aktywność klientów. Aby ograniczyć to ryzyko, Doradź użytkownikom, aby łączyli się z maszynami, na których zainstalowane jest oprogramowanie do wykrywania wirusów i trojanów.

P: Jak chronić ruch STA za pomocą SSL?

A: Najpierw zainstaluj certyfikat serwera www na kopii usług IIS, w której znajduje się STA. Więcej informacji można znaleźć w dokumentacji usług IIS.

Skonfiguruj serwer wyliczania aplikacji i serwer bezpiecznej bramy, aby korzystał z protokołu HTTPS podczas komunikacji z bramą. Podczas łączenia się przez HTTPS zawsze muszą być spełnione następujące reguły:

• musisz adresować STA przy użyciu w pełni kwalifikowanej nazwy domeny, która pasuje do tematu certyfikatu serwera sta.
• maszyna komunikująca się z STA musi być w stanie rozwiązać w pełni kwalifikowaną nazwę domeny STA na odpowiedni adres IP.
• maszyna komunikująca się z STA musi zaufać urzędowi certyfikacji, który wydał certyfikat serwera sta.
• aby spełnić wymagania trzeciej pozycji punktora, certyfikat główny CA musi być zainstalowany na serwerze Secure Gateway i na serwerze wyliczeń aplikacji. Zachowaj ostrożność podczas instalowania certyfikatu głównego: nie można po prostu dwukrotnie kliknąć pliku certyfikatu głównego i uruchomić Kreatora importu certyfikatu.

(oznacza to, że konto użytkownika, a nie serwer lub jakiekolwiek usługi systemowe, Ufa urzędowi certyfikacji.) Aby zainstalować certyfikat główny do użytku z Citrix Secure Gateway lub interfejsem internetowym, wykonaj następujące kroki:

1. Uruchom Mmc.exe i dodaj przystawkę Certyfikaty.
2. gdy pojawi się pytanie, którymi certyfikatami zarządzać, wybierz pozycję Konto komputera, a następnie komputer lokalny.
3. rozwiń węzeł Certyfikaty (Komputer lokalny) >Zaufane główne urzędy certyfikacji. Kliknij prawym przyciskiem myszy certyfikaty, a następnie wybierz Wszystkie zadania > Importuj.
4. Przeglądaj, aby wybrać certyfikat główny urzędu certyfikacji i ukończyć Kreator importu.

P: Czy STA musi być zawsze adresowane przy użyciu w pełni kwalifikowanej nazwy domeny?

A :jeśli zamierzasz zabezpieczyć ruch do STA za pomocą protokołu SSL, każdy komponent, który uzyskuje dostęp do STA, w tym serwer bramy i serwer wyliczania aplikacji, musi adresować STA przy użyciu w pełni kwalifikowanej nazwy domeny (FQDN), która odpowiada tematowi certyfikatu serwera używanego przez usługi IIS na STA. Na przykład w interfejsie Web 2.0 adres STA zostanie wprowadzony jako:https://sta-server.company.com/Scripts/CtxSta.dll

jeśli zdecydujesz się nie zabezpieczać ruchu do STA, możesz adresować STA za pomocą adresu IP, nazwy hosta lub FQDN.

P: Jak zmienić port STA z 80 na inny?

A: ponieważ STA jest obsługiwany przez usługi IIS, zmieniasz port STA podczas zmiany portu usług IIS. Poniższy przykład ilustruje, jak zmienić port usług IIS z 80 na 81.

1. Open Internet Services Manager.
2. kliknij prawym przyciskiem myszy domyślną stronę internetową i zobacz Właściwości.
3. na karcie strony internetowej Zmień numer portu TCP z 80 na 81.
4. kliknij OK.
   poprzednia zmiana dotyczy również wszystkich innych zasobów opublikowanych z serwera www STA. Jeśli chcesz zmienić port komunikacyjny STA bez wpływu na inne strony internetowe hostowane przez ten sam serwer WWW, możesz utworzyć nową witrynę internetową w IIS wyłącznie w celu hostowania STA. Poniżej znajduje się przykład utworzenia nowej strony internetowej na porcie 81 dla STA.
5. Utwórz nowy fizyczny folder, taki jak C:\MYSTA na dysku twardym serwera sieci Web, aby służyć jako root dokumentu dla witryny STA.
6. Utwórz podkatalog pod MYSTA o nazwie Scripts. Przenieś następujące pliki z istniejącego STA do nowego folderu Scripts:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. Open Internet Services Manager.
8. kliknij prawym przyciskiem myszy nazwę serwera i wybierz nową witrynę >.
9. Utwórz nową stronę o nazwie „Moja strona STA” i C:\MYSTA jako katalog główny dokumentu.
10. zobacz właściwości nowej witryny sieci web i zmień port TCP na 81.
11. w sekcji Moja strona STA w Menedżerze usług internetowych kliknij prawym przyciskiem myszy folder skrypty i zobacz właściwości. W sekcji Ustawienia aplikacji zmień uprawnienia do wykonywania na ” skrypty i pliki wykonywalne.”

Uwaga :Możesz wybrać inną nazwę folderu niż „Scripts”, ale pamiętaj, że Secure Gateway i wszystkie serwery wyliczania aplikacji, takie jak interfejs WWW, zakładają, że STA jest publikowany jako /Scripts/CtxSta.dll, więc trzeba będzie również zaktualizować adres URL STA w ustawieniach na tych serwerach.

P: Czy atakujący może wysłać losowe bilety do bramki, aby się zalogować?

A: atakujący musiałby odgadnąć ważny bilet, a także zrealizować go w ciągu kilku milisekund po tym, jak klient zażąda go, ale zanim Brama go zażąda.

P: Jakie inne informacje są wymagane do logowania poza ważnym biletem STA?

A: użytkownicy potrzebują również poświadczeń domeny lub biletu serwera XenApp, który jest wymagany przez serwer wyliczeń aplikacji. (Bilet na serwer XenApp nie jest tym samym, co bilet STA.) Spełnienie STA otwiera ścieżkę tylko do zaufanej sieci dla danego serwera. Tam użytkownik musi nadal uwierzytelniać się za pomocą ważnych poświadczeń domeny.
P: Jak możemy ustawić czas życia biletu STA, po którym bilet powinien być nieważny?
A: możemy ustawić żywotność biletu STA, tworząc następujący klucz rejestru na kontrolerze dostawy:
lokalizacja: HKLM \ Software \ Citrix \ DesktopServer
Nazwa: XmlStaTicketLifetimeInSeconds
Typ: Wartość Dword: Podaj wartość w sekundach (dziesiętne)
przed edycją wartości rejestru wykonaj kopię zapasową rejestru, należy również pamiętać, że zmiana rejestru wymagałaby ponownego uruchomienia na końcu kontrolera.

skalowalność

p: ile STAs potrzebuję?

A :STA jest dostępne tylko wtedy, gdy użytkownik uruchamia aplikację, odpowiedź na to pytanie różni się w zależności od wdrożenia.

P: czy użytkownicy logują się rano przez bramę i uruchamiają jedną opublikowaną aplikację przez cały dzień, czy uruchamiają kilka aplikacji w ciągu dnia?

A: Obowiązki wykonywane przez STA nie są drogie pod względem CPU; jest to lekka usługa XML ograniczona tylko wydajnością IIS. W jednym teście serwer niskiego zasięgu z procesorem 1GHz i 256MB pamięci RAM obsługiwał ponad 250 zapytań o bilet na sekundę, podczas gdy wykorzystanie procesora pozostało poniżej 60%.

P: Jak mogę zapewnić odporność na błędy STA?

A: wszystkie następujące serwery wyliczania aplikacji umożliwiają wprowadzanie wielu adresów URL STA podczas konfigurowania parametrów dla Secure Gateway:

• interfejs WWW 2.0
• Secure Access Manager 2.0
• StoreFront

we wszystkich przypadkach, jeśli STA nie odpowiada, serwer wyliczeń aplikacji próbuje użyć innego STA na liście. Każdy serwer bramy z kolei musi być skonfigurowany z adresem URL STA i unikalnym identyfikatorem STA dla każdego organu biletowego.

P: jak załadować balans wielu STAs?

A :Należy zachować szczególną ostrożność podczas równoważenia obciążenia bezpiecznymi organami biletowymi. W celu zrównoważenia obciążenia połączenia między serwerem wyliczania aplikacji a STAs można użyć różnych metod, ale bezpieczny serwer bramy musi zawsze kontaktować się z każdym STA indywidualnie na podstawie jego identyfikatora STA. Podczas konfigurowania adresu każdego STA w narzędziu konfiguracyjnym usługi gateway, każdy adres STA musi być prawdziwym adresem serwera STA — nie należy tutaj wpisywać adresu żadnego sprzętowego Load balancera, nazwy klastra ani nazwy round-robin DNS.

StoreFront, Web Interface 2.0 i Secure Access Manager 2.0 wszystkie obsługują round-robin load balancing STAs, gdy na liście znajduje się wiele STAs. Gdy ta opcja jest włączona, nie jest wymagane dodatkowe oprogramowanie lub sprzęt równoważący obciążenie.

serwery wyliczania aplikacji mogą używać dowolnej formy równoważenia obciążenia do wystawiania żądania biletu, ponieważ każdy otrzymany bilet zawiera pole wskazujące unikalny identyfikator STA, który go wygenerował. Tak długo, jak każdy identyfikator STA jest unikalny i wszystkie serwery bramy mogą rozwiązać identyfikator STA na konkretny (nie równoważony obciążeniem) adres serwera, operacja powiedzie się, a ruch STA jest równoważony obciążeniem.

Q: Czy Mogę używać kilku STAs z równoważeniem obciążenia sieci Microsoft?

A: nie można używać równoważenia obciążenia sieci między serwerem bezpiecznej bramy a wieloma STAs. Jeśli skonfigurowany w ten sposób, użytkownicy otrzymują przerywane zaprzeczenia, ponieważ, podczas procesu walidacji biletu, brama może być obciążony równoważony do organu, który pierwotnie nie wygenerował biletu użytkownika.

P: Czy Mogę współdzielić jeden STA z wieloma farmami, bramkami i serwerami wyliczeń?

A: Tak, pojedynczy STA może być współdzielony między dowolną liczbą bezpiecznych serwerów bram i serwerów wyliczania aplikacji. STA nie jest ograniczony do żadnej konkretnej domeny, farmy lub serwera wyliczeń aplikacji. Jest to anonimowa usługa XML.

Rozwiązywanie problemów

P: Jak skonfigurować IIS do hostowania STA?

The STA URL /Scripts/CtxSta.dll musi być obsługiwany z włączonym dostępem anonimowym. Jeśli wskażesz dowolną przeglądarkę internetową na adres URL STA, nie zostaniesz poproszony o podanie hasła.

• musisz przyznać uprawnienia skryptów zasobów i plików wykonywalnych w metabase usługi IIS. To uprawnienie nie jest potrzebne dla całego folderu / Scripts, ale może być ustawione dla CtxSta.plik dll indywidualnie.
• w przypadku Secure Gateway w wersji 1.1 i wcześniejszych nie włączaj opcji Require SSL I Require 128-bit SSL.
• domyślnie wymagane są następujące uprawnienia konta:

na serwerach Windows 2000

• konto IUSR_MachineName wymaga dostępu do odczytu CtxSta.dll.
• konto IWAM_MachineName wymaga modyfikacji dostępu do katalogu pliku dziennika, który jest domyślnie \Inetpub\Scripts.

na serwerach Windows 2003

• konto IUSR_MachineName wymaga dostępu do odczytu CtxSta.dll.
• wbudowane konto usługi sieciowej wymaga modyfikacji dostępu do katalogu pliku dziennika, który jest domyślnie \Inetpub\Scripts.

P: Jak włączyć logowanie w STA?

A: używając Notatnika, Edytuj plik \Inetpub\Scripts\Ctxsta.konfiguracja na serwerze STA i zlokalizowanie linii, która mówi LogLevel=0. Dla maksymalnego logowania zmień to na LogLevel=3. Aby zmiany weszły w życie, należy ponownie uruchomić usługę publikacji w sieci World Wide Web.
Uwaga: Po włączeniu logowania konto użytkownika, pod którego władzą wykonuje STA (domyślnie IUSR_MachineName w systemie Windows 2000 lub usługa sieciowa w systemie Windows 2003), musi mieć dostęp do zapisu do katalogu pliku dziennika, który jest domyślnie \Inetpub \ Scripts. Możesz także zmienić katalog plików dziennika podczas edycji CtxSta.config.

P: Dlaczego narzędzie Microsoft IISLockDown łamie STA?

A: Jeśli zaakceptujesz wszystkie domyślne ustawienia narzędzia IISLockDown, folder / Scripts zostanie wyłączony. Sta jest zaimplementowany jako filtr ISAPI opublikowany jako / Scripts / CtxSta.dll; wyłączając katalog / Scripts, odmawiasz dostępu do STA. Włącz folder / Scripts i Zezwalaj na dostęp do skryptów i plików wykonywalnych dla funkcji STA.

P: Jak mogę przetestować STA, aby upewnić się, że działa poprawnie?

A :jeśli skierujesz przeglądarkę internetową na adres URL STA, zobaczysz pustą białą stronę lub komunikat ” 405 Resource not Allowed.”Każdy z tych wyników wskazuje na funkcjonujący STA. Możesz skontaktować się ze STA w ten sposób z konsoli serwera Secure Gateway, a także z dowolnego serwera wyliczania aplikacji skonfigurowanego do korzystania z bramy. Jeśli pojawi się okno dialogowe uwierzytelniania z monitem o podanie hasła, STA nie jest publikowany anonimowo i wymagania dotyczące uwierzytelniania muszą zostać usunięte.

aby sprawdzić, czy serwer wyliczeń aplikacji pomyślnie żąda biletów STA, spójrz na pliki ICA, które generuje. Na przykład w interfejsie Web 2.0 można kliknąć prawym przyciskiem myszy ikonę opublikowanej aplikacji i zapisać wynik jako uruchomienie.ica. Otwierać.ica w Notatniku i widok linii Address=. W przypadku normalnej pracy Secure Gateway parametr Address będzie zawierał bilet zamiast rzeczywistego adresu serwera XenApp.

P: Jak interpretować pliki dziennika STA?

A: jeśli włączysz logowanie przez ustawienie LogLevel = 3 w CtxSta.config, zobaczysz szczegóły każdego zgłoszenia i żądania danych otrzymane przez STA. Pamiętaj, że żądanie zgłoszenia jest generowane przez serwer wyliczania aplikacji, taki jak interfejs sieciowy, a żądanie danych jest wykonywane przez usługę Secure Gateway. Jeśli plik dziennika pokazuje kilka żądań biletów, ale nie żądań danych, oznacza to, że serwer wyliczeń aplikacji może dotrzeć do STA, ale serwer bezpiecznej bramy nie może. Może to również oznaczać, że użytkownicy nie mogą dotrzeć do serwera bramy.

podczas normalnej pracy funkcja współdzielenia sesji klienta ICA może spowodować, że bilety będą żądane od STA, ale nigdy nie zostaną odebrane przez bramę. Rozważ następujący scenariusz:

• użytkownik loguje się do interfejsu internetowego i klika ikonę programu Outlook. Interfejs sieciowy żąda zgłoszenia od STA i wysyła go do użytkownika w pliku ICA.
• użytkownik łączy się przez bezpieczną bramę i prezentuje bilet wstępu. Bramka weryfikuje bilet i pozwala użytkownikowi połączyć się z serwerem XenApp Hosting Outlook.
• po kilku minutach pracy użytkownik wraca do listy aplikacji na stronie interfejsu internetowego i klika ikonę programu Excel. Interfejs sieciowy żąda drugiego biletu od STA i wysyła go do użytkownika w pliku ICA.
• przed połączeniem się z nowym serwerem programu Excel Klient ICA najpierw sprawdza, czy istniejące serwery, do których klient jest już podłączony, mają dostęp do opublikowanej aplikacji Excel.
• serwer, na którym Klient jest już uruchomiony Outlook, ma również zainstalowany program Excel, więc klient ICA odrzuca plik ICA i uruchamia program Excel w ramach istniejącej sesji ICA.
• drugi bilet wymagany przez interfejs sieciowy nigdy nie jest używany, ponieważ druga sesja ICA nie była konieczna. Domyślnie bilet wygasa po 100 sekundach.

ten scenariusz spowodowałby serię wpisów plików dziennika sta podobnych do następujących:

CSG1305 Request Ticket - Successful 8DE802AE5A2F561233450B6CFD553035 ...CSG1304 Request Data - Successful 8DE802AE5A2F561233450B6CFD553035 ...CSG1305 Request Ticket - Successful 63EF3EAB182D846958143D19C1FDAEBA ...CSG1303 Ticket Timed Out 63EF3EAB182D846958143D19C1FDAEBA

bardziej podejrzana aktywność może wyglądać mniej więcej tak:

CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB804 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB805 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB806 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB807 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB808 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB809

tutaj widzimy osobę, która wydaje się atakować, próbując różnych biletów pojedynczo, zwiększając identyfikator biletu przy każdej próbie. W każdym przypadku połączenie zostało odrzucone, a STA zarejestrował wejście wskazujące, że Klient przedstawił bilet, który nie został uznany za ważny. Aby zidentyfikować adres IP atakującego, poszukaj następującego komunikatu w przeglądarce zdarzeń na serwerze Secure Gateway:

CSG3207 Service received error from STA or Authentication Service , Client IP connection dropped.

nie należy interpretować niektórych komunikatów „nie znaleziono biletu” jako ataku. Klient Win32 Ica może próbować ponownie połączyć się z rozłączoną sesją, jeśli połączenie sieciowe użytkownika zostanie chwilowo przerwane. Funkcja automatycznego ponownego połączenia klienta nie działa w przypadku użytkowników Citrix Secure Gateway, ponieważ podczas każdej próby ponownego połączenia klient ponownie wysyła używany bilet STA, z którym pierwotnie się połączył. Klient zazwyczaj próbuje ponownie połączyć się trzy lub więcej razy przed rezygnacją, więc zobaczysz trzy lub więcej komunikatów „nie znaleziono biletu” odnoszących się do tego samego biletu w dzienniku STA dla każdego wystąpienia tego problemu. Próby ponownego połączenia klienta charakteryzują się próbą ponownego użycia wcześniej udanego zgłoszenia:

CSG1305 Request Ticket - Successful 766D558270CE32695903698AFA0F67A6 …CSG1304 Request Data - Successful 766D558270CE32695903698AFA0F67A6 …CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6

odłącz Auto Client Połącz się ponownie dla użytkowników bezpiecznej bramy, dodając TransportReconnectEnabled = Off do sekcji pliku ICA. Poprawnym sposobem ponownego połączenia się z rozłączoną sesją podczas korzystania z Secure Gateway jest powrót do serwera wyliczania aplikacji i ponowne kliknięcie ikony aplikacji.

P: Jakie są typowe błędy konfiguracji widoczne w Pomocy Technicznej Citrix?

• folder /Scripts lub Cała Domyślna strona internetowa jest wyłączona w wyniku uruchomienia IISLockDown lub przestrzegania zasad firmy dotyczących ochrony serwerów internetowych.
• Logowanie jest włączone w CtxSta.config, ale konto użytkownika, pod którego władzą wykonuje STA (domyślnie IUSR_MachineName), nie ma prawa zapisu do katalogu pliku dziennika.
• usługi IIS na serwerze STA są skonfigurowane tak, aby wymagały SSL, ale Bezpieczna Brama jest skonfigurowana tak, aby uzyskiwać dostęp do STA przy użyciu zwykłego protokołu HTTP.
• jeśli uruchomienie aplikacji nie powiedzie się, pierwszą rzeczą do sprawdzenia jest to, czy STAs na interfejsie StoreFront/Web i NetScaler są podane w dokładnie taki sam sposób, czy nie, tj. jeśli STAs są podane jako adres IP NA SF/WI, powinny być podane przy użyciu adresu IP NA NS i podobnie w przypadku FQDN.