Instalacja agenta TS na serwerze terminali
Gdy mamy zintegrowanego agenta FSSO z AD to możemy tworzyć polityki firewalla bazując na zalogowanych kontach użytkownika, lecz ma to jest problem. W tym założeniu jeden użytkownik korzysta w jednym czasie z jednego komputera. W przypadku, gdy ma się w organizacji wdrożony serwer do pulpitów zdalnych domyślnie będziemy widzieli cały czas 1 konto korzystające z komputera (konto, które zalogowało się jako ostatnie do serwera terminali). To oznacza, że jeśli ostatnim kontem będzie np. konto dyrektora mającego pełny dostęp to wszyscy podłączeni przez pulpity zdalne do tego serwera taki dostęp będą mieć. W drugą stronę – jeśli ostatnią osobą będzie przyjmijmy rekruter to wszyscy podłączeni będą mieli takie same ograniczenia w wykorzystywaniu sieci jak on.
Dlatego też mając agenta FSSO należy korzystać z agenta TS (terminal server) dla Fortgate’a. Instalacja jest prosta. Na tej stronie możemy znaleźć link do progrania najnowszej wersji TS Agenta po zalogowaniu, przejściu do Download > Firmware images, wybierając urządzenie FortiGate wybieramy też niżej zakładkę download, przechodzimy do najnowszej wersji urządzenia i koniec końców tak jak na zrzucie poniżej wybieramy instalator TSAgent_Setup_5.0.0827.msi.
Po ściągnięciu i wrzuceniu pliku na wspomniany serwer terminali musimy przejść przez szybki proces instalacji.
Klikamy Next.
Zatwierdzamy warunki umowy licencyjnej i Next.
Nie zmieniamy katalogu instalacyjnego, Next.
Next.
I Finish. W ten sposób mamy wdrożonego agenta.
Jak widać z poziomu Fortinet Signle Sign On Agent Configuration agent TS jest wykrywany i działa.
To oznacza, że tym razem nie powinno być problemu z sesjami. Z poziomu Monitor > Firewall User Monitor po kliknięciu Show all FSSO Logins możemy zobaczyć wielu użytkowników zalogowanych na maszynie z adresem 192.168.30.5, poza tym w sekcji Method agent to FSSO Citrix. To akurat jest jednoznaczne.
Następnie na postawie polityk z poprzedniego posta (zwykli użytkownicy nie mają dostępu do kategorii z obciążających przepustowość + stron związanych z graniem), admini domenowi nie mają restrykcji. W ramach testu stworzyłem RemoteApp, którym jest Google Chrome (najłatwiejsza opcja na sprawdzenie jak jest realizowany web filtering dla konkretnych użytkowników). Jak widać, tutaj jest zablokowany dostęp:
Tutaj też:
A tutaj nie (zalogowane konto to konto admina). Wszystko się zgadza.
Jak widać, było to łatwiejsze, niż się wydawało.
Podłączenie drugiego kontrolera domeny do FSSO
Do tego najlepiej mieć jakiś wydzielony host, który zbiera logowania ze wszystkich miejsc (kontrolery domeny i serwery terminali). W moim przypadku to host z Windowsem 10, który nazywa się fsso-collector.
UPDATE: to jednak nie jest potrzebne, ponieważ można po prostu zainstalować Collector Agenta na dwóch kontrolerach domeny i na wzajem się nasłuchiwać.
Ogólnie pod kątem instalacji należy podążać za przykładem, który przedstawiłem tutaj, a gdy mamy już kwestię uprawnień dla konta użytkownika serwisowego i konfigurację zapory sieciowej za sobą to powinniśmy podłączyć agenty DC do naszego nowego collectora wraz z agentem TS, który też jest w środowisku. Nie różni się też bardzo tym od instalacji z 1 agentem TS – po prostu mamy dwa kontrolery domeny na liście:
Ja akurat na dc1 miałem już agenta, lecz na dc2 nie, dlatego też po instalacji na dc2 należy wykonać restart systemu:
W przypadku dc1 jedynie otrzymamy informację, że wszystko jest gotowe.
Musimy też podpiąć agenta TS, który w moim przypadku jest jeszcze podpięty do starego collectora z poprzedniego przykładu, więc na dobrą sprawę by to zmienić musimy uruchomić TS Config:
Potem wystarczy w oknie poniżej kliknąć Run as administrator i zmienić adres w Fortinet SSO Collector Agent IP/Port na nowy, w moim przypadku 192.168.30.6. Po tym klikam przycisk Save&close.
UPDATE: w przypadku posiadania Collector Agentów należałoby wpisać adresy obu CA, więc zamiast 192.168.30.6 powinno być 192.168.30.2;192.168.30.3.
Następnie w Fortigate, w Security Fabric > Fabric Connectors możemy zwrócić, że nasz connector ma status down:
Następnie definiujemy poprawny adres collectora i hasło w polu Primary FSSO Agent, po czym klikając Apply & Refresh. Potem można kliknąć OK by sprawdzić status połączenia:
Dodałem tutaj zaznaczoną opcję Trusted SSL Certificate, gdzie zaznaczyłem certyfikat mojego urzędu CA w organizacji. Polecam zapoznać się z tym postem, ponieważ tutaj omówiłem to, jak takie certyfikaty konfigurować. To jest opcjonalne, ale przydatne. W przypadku korzystania z SSL musimy się upewnić, że nasz FortiGate poprawnie rozwiązuje nazwy DNS z naszej domeny oraz w profilu LDAP Profile jak i w profilu FSSO Agent on Windows AD są zdefiniowane adresy FQDN kontrolerów domeny zamiast adresów IP. W innym wypadku certyfikaty nie zostaną uznane jako prawidłowe i niektórzy robią jakieś krzywe myki z ignorowaniem poprawności certyfikatów, czego nie polecam.
Swoją drogą, tutaj jak widać collector zbiera informacje z agentów DC. Warto nie zapomnieć zdefiniować hasło, które podajemy w Fabric Connectorze w sekcji Authentication zakładając, że mamy zaznaczoną opcję Require authenticated connection from FortiGate:
Ostatnim elementem, który musimy zmienić jest obiekt serwera LDAP w Fortigate, lecz takiej zmiany nie możemy zrobić z poziomu GUI, bo mamy tylko 1 pole adresowe dla serwera LDAP (ustawienie jest w User & Device > LDAP Servers):
Na wdrożeniach staram się zawsze używać połączenia szyfrowanego, ponieważ dzięki temu nie da się w komunikacji wyłapać loginów i haseł, które wpisują użytkownicy np. w polu logowania do FortiGate’a. Wymaga to wdrożenia AD CS, zaimportowania certyfikatu CA do FortiGate’a (tutaj napisałem jak zmienić nazwę na łatwo wyszukiwalną) i wybrania go z listy. Nie ma znaczenia, czy korzystamy z LDAP over STARTTLS czy over SSL/TLS.
Taką operację musimy wykonać z poziomu CLI:
supra-forti # config user ldap
supra-forti (ldap) # edit serba.local
supra-forti (serba.local) # set secondary-server dc2.serba.local
supra-forti (serba.local) # end
W przypadku, gdy mamy trzy kontolery domeny, możemy w obiekcie zdefiniować trzeci kontroler za pomocą pola tertiary-server, na przykład:
supra-forti # config user ldap
supra-forti (ldap) # edit serba.local
supra-forti (serba.local) # set tertiary-server dc3.serba.local
supra-forti (serba.local) # end
W ten sposób, jak widać byłem w stanie zalogować się na swoje konto administracyjne pomimo tego, że pierwszy kontroler domeny był wyłączony:
