Niestety, tych opcji aktualnie (w wersji FortiOS 6.4.1 jeszcze nie ma w interfejsie, więc trzeba to zrobić przez CLI. Dla przykładu mój profil i poniżej przykład dodania dodatkowych kontrolerów domeny:
anzena-forti # config user ldap
anzena-forti (ldap) # edit serba.local
anzena-forti (serba.local) # set secondary-server dc2.serba.local
anzena-forti (serba.local) # set tertiary-server dc3.serba.local
anzena-forti (serba.local) # set password-expiry-warning enable
anzena-forti (serba.local) # set password-renewal enable
anzena-forti (serba.local) # end
Dzięki temu certyfikat nie jest nazwany domyślnie tak jak na górze, lecz tak jak ten na dole:
anzena-forti # config vpn certificate ca
anzena-forti (ca) # rename CA_CERT_2 to SERBA-CA
table name 'CA_CERT_2' is not found!
Command fail. Return code 2 //jak widać wielkość liter ma znaczenie!
anzena-forti (ca) # rename CA_Cert_2 to SERBA-CA
anzena-forti (ca) # end
Rachunki za prąd mi nieźle podskoczyły, więc od niedawna włączam kompa tylko wtedy, jeśli go potrzebuję. Dlatego wcześniej łączę się do domu po VPNie i korzystam z opcji Wake on LAN – dzięki czemu mogę zdalnie włączyć komputer, bo niestety on nie ma interfejsu IPMI, ani nie ma w domu drugiej osoby, która mi ten przycisk wciśnie.
FortiGate:
execute wake-on-lan lan 00:d8:61:04:20:69
gdzie lan to nazwa intefejsu, do którego jest podpięty mój komputer, a następnie jest adres MAC mojej karty sieciowej w komputerze.
Mikrotik:
tool wol interface=ether4 mac=00:d8:61:04:20:69
Tutaj tak samo jak wyżej, jedynie nieco inne polecenie.
Zawsze jak uczę się czegoś (na przykład w pracy) staram się wyciągnąć z tego 100%. Przez to natrafiłem na 1 opcję w agencie FSSO FortiGate’a, której nigdzie nikt nie używa: FortiGate SSL. Nie trudno się domyślić, że tu chodzi o to, by komunikacja z FortiGate’m była szyfrowana (domyślnie jest przesyłana plaintextem). Więc skoro zabezpieczamy wszystko najlepiej to czemu tego nie zmienić?
Problem w tym, że w dokumentacji FortiGate’a ani w ich Cookbooku tego nie ma. Są inne rzeczy, ale tą funkcjonalność ktoś po prostu pominął i nie ma totalnie nic o jej konfiguracji, więc próbowałem się dowiedzieć na własną rękę jak ją się ustawia.
Na początku należy mieć własne CA. Na przykład ja używam do tego CA, które można postawić w AD (Usługi certyfikatów Active Directory):
Ja zawsze do niego doinstalowuję funkcję Rejestracja w sieci Web dla urzędu certyfikacji. Dzięki temu możemy przez stronkę taki certyfikat sobie podpisać, zakładając, że postawiliśmy sobie takie CA na serwerze dc1.serba.local wystarczy wejść na stronkę http://dc1.serba.local/certsrv (oczywiście da się zmienić na HTTPS) i tam możemy załatwić robotę. Część robię za pomocą OpenSSL, więc warto mieć zainstalowaną windowsową wersję lub korzystać z Windows Subsystem for Linux (korzystam z tego „czegoś” w Windows Store, w praktyce daje mi to możliwość korzystania ze wszystkich (prawie) poleceń z Ubuntu lecz będąc na Windowsie).
Zaczynamy od utworzenia klucza prywatnego:
openssl req -newkey rsa:2048 -keyout local.key
Generating a RSA private key
..........+++++
........+++++
writing new private key to 'local.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:SL
Locality Name (eg, city) []:Tychy
Organization Name (eg, company) [Internet Widgits Pty Ltd]:it.supra.tf
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:it.supra.tf
Email Address []:radoslaw@serba.ovh
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
-----BEGIN CERTIFICATE REQUEST-----
MIICzDCCAbQCAQAwgYYxCzAJBgNVBAYTAlBMMQswCQYDVQQIDAJTTDEOMAwGA1UE
BwwFVHljaHkxFDASBgNVBAoMC2l0LnN1cHJhLnRmMQswCQYDVQQLDAJJVDEUMBIG
A1UEAwwLaXQuc3VwcmEudGYxITAfBgkqhkiG9w0BCQEWEnJhZG9zbGF3QHNlcmJh
Lm92aDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNpWo2R6qcUQKCO
3rTL2nBnPa33lS9mtvC+j7HHU2ZNHgSYsm6jVP0t3ARWEGPg4soTI95GBojO4KbA
lUNw8D5tza0rj45C70VeNZkk5n6Y9OsoMyOrOPThZTmfJWdZXfN90rZC2leAdy24
7fTkcJ3jgkgHWgjbsu6kWvCLXgzPY71VfIFufDuUTLGHyD4RIAjT6MjML4SMToFU
vSQ3fwUbe+ayAV/XB0O2PR+zJ7TD1W4MoaJwTklPOb0pT/6sGNmOsxQiyoaqbK3q
nW8x37PKCXthwObpJMnyROXsyYCZqaHiDxtK7jEao4jyhUkzqcJyvHrv0RLwMZzr
OFgzxVECAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQA+h+TmOmJuzdcAaeYdZmjs
bL1VJR4ih38/LU+ELjha+380SPA9bvbmHNYcGLtc8Y5aMi00TZoRwZ6HO4ALA11Y
JD0f5bC3c/JulHuBy+5wCMw4JyM8GFz2yrayi1wqXJVDp57kDjrB1GWhX8sG2oh6
yf+Y6wJk9zyO48Aglgg7w/ZtEjnyBID182yUxSNEJuBoOooNmGqCQrvTJZFgnXzJ
NQT1f4KlCZhE8g9bA8dWuIW7aAm2ssck/QI15jyj22zNYk0c5m+kdcDhjss6qjFw
m0LXnHCLWWdnBKqqraTy5G7ZNTDGxl43n74bRCGAJkotkh5RxX+e3BzihyCjg5dH
-----END CERTIFICATE REQUEST-----
Dzięki temu mam wygenerowany taki klucz prywatny w pliku local.key:
Następnie warto sobie przygotować config do generowania CSR (certificate signing request), czyli żądanie podpisania certyfikatu, ja sobie zapisałem go w pliku o nazwie config.cnf. Istotne w tym szablonie są pola CN oraz DNS.1 – one muszą być adresem FQDN naszego hosta, na którym jest zainstalowany FSSO Collector (w sensie agent), w moim przypadku jest to fsso-collector.serba.local:
Takie coś musimy przesłać do naszego CA, a w wyniku tego dostaniemy certyfikat. Wchodzimy więc na stronę naszego urzędu certyfikacji (musimy się przedtem autoryzować naszym kontem administracyjnym):
Po tym wybieramy Żądanie certyfikatu.
Następnie zaawansowane żądanie certyfikatu.
Tutaj sprawa jest prosta – wklejamy naszą zawartość CSRki i wybieramy odpowiedni szablon certyfikatu. W skrócie jest kilka predefiniowanych w naszym CA, można je zmieniać z przystawki certification authority i szablon Serwer sieci Web jest do serwerów HTTP, więc w sam raz, bo jest właśnie ten nam tutaj potrzebny. Klikamy Prześlij >.
Tutaj musimy tylko pobrać sam certyfikat i musi być szyfrowany algorytmem Base-64. Często w certyfikatach potrzebne są nam certyfikaty CA (chain) oraz certyfikat serwera (certificate). W niektórych serwerach wystawia się je w jednym pliku, przy czym najpierw jest zawartość certyfikatu serwera, a potem certyfikat CA (takie pliki są określane mianem fullchain). Tutaj wystarczy sam certyfikat serwera, a plik certyfikatu CA musi być dodany na naszym FortiGate. Taki można wrzucić tutaj:
Następnie certyfikat serwera oraz klucz prywatny, który stworzyliśmy na samym początku musimy podać w ustawieniach zaawansowanych (przycisk Advanced Settings) FSSO collectora:
U góry wskazujemy plik certyfikatu, w środku plik klucza prywatnego oraz na dole podajemy hasło, jakie zdefiniowaliśmy dla tego klucza, po czym klikamy Test, a jak hasło jest prawidłowe to klikamy OK. Dodam, że warto odblokować na firewallu w Windowsie komunikację pomiędzy naszym FortiGate’m a hostem z agentem na porcie TCP 8001 w dwie strony, bo inaczej to nie zadziała.
Po stronie FortiGate musimy jeszcze w ustawieniach External Connectors zaznaczyć opcję Trusted SSL Certificate i wybrać CA, które podpisało ten certyfikat i teoretycznie wszystko powinno być okej…
…ale jednak nie. Okazuje się, że nawet w najnowszej wersji FortiOS po włączeniu tego FortiGate dalej próbuje się łączyć z wykorzystaniem SSLa do collectora po porcie 8000 zamiast 8001. Tego się dowiedziałem w trakcie troubleshootingu z supportem Fortinetu (który sam przyznał, że dodali taką funkcję, bo 1 klient o to poprosił, ale w sumie tego nie ma nigdzie opisanego), więc w skrócie taki port trzeba aktualnie zmienić w CLI:
anzena-forti (fsso) # show config user fsso
edit "serba.local"
set server "fsso-collector.serba.local"
set port 8001 <======== w tym jest problem, trzeba to zmienić z 8000 na 8001
set password ENC H7/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa==
set ssl enable
set ssl-trusted-cert "SERBA-CA"
next
end
Zmieniamy to poleceniami:
anzena-forti # config user fsso
anzena-forti (fsso) # edit serba.local
anzena-forti (serba.local) # set port 8001
anzena-forti (serba.local) # end
Po tym komunikacja FortiGate z FSSO Collectorem po SSLu będzie działać.
Na koniec dodam, że Pan z Fortinet TAC sprawdzał to za pomocą sniffera poprzez CLI wykonując polecenie:
diag sniff packet any "port 8000" 6 0 a
Poza tym włączał debug mode poleceniami:
di de en
di de authd fsso server-status
Update: po aktualizacji do wersji FortiOS 6.4.2 zauważyłem, że dodano wiele portów do profili FSSO:
anzena-forti (fsso) # edit serba.local
anzena-forti (serba.local) #
set Modify value.
unset Set to default value.
get Get dynamic and system information.
show Show configuration.
next Configure next table entry.
abort End and discard last config.
end End and save last config.
anzena-forti (serba.local) # set
type Server type.
*server Domain name or IP address of the first FSSO collector agent.
*port Port of the first FSSO collector agent.
password Password of the first FSSO collector agent.
server2 Domain name or IP address of the second FSSO collector agent.
port2 Port of the second FSSO collector agent.
password2 Password of the second FSSO collector agent.
server3 Domain name or IP address of the third FSSO collector agent.
port3 Port of the third FSSO collector agent.
password3 Password of the third FSSO collector agent.
server4 Domain name or IP address of the fourth FSSO collector agent.
port4 Port of the fourth FSSO collector agent.
password4 Password of the fourth FSSO collector agent.
server5 Domain name or IP address of the fifth FSSO collector agent.
port5 Port of the fifth FSSO collector agent.
password5 Password of the fifth FSSO collector agent.
ldap-server LDAP server to get group information.
group-poll-interval Interval in minutes within to fetch groups from FSSO server, or unset to disable.
user-info-server LDAP server to get user information.
ssl Enable/disable use of SSL.
ssl-trusted-cert Trusted server certificate or CA certificate.
source-ip Source IP for communications to FSSO agent.
source-ip6 IPv6 source for communications to FSSO agent.
interface-select-method Specify how to select outgoing interface to reach server.
Poniżej przykład mojej konfiguracji:
config user fsso
edit "serba.local"
set server "dc1.serba.local"
set port 8001
set password ENC 2ADfLnGWaMcPrHrwp8gIddCjZsNg9EsPidsh4Gdy+eWPIi0GC6Dycw74/LqRRZNgpZJT44X9X6EpZV4qE3gCI01pgo5xUk4B0sqQGd+6YObAZEBvwT2vBzNFNXNI9ZZX2Db+n0GmrNIUECD0bUhDUalmZeeIqa341M0YirrJAJ+bv9AAgsMB891F77JpX4QNqzV4Gg==
set server2 "dc2.serba.local"
set port2 8001
set password2 ENC BJJKjYuknd0U+rMXrzjS8DLcgENw8aE+kW2gKipuXxh+gJYHB1TAdpr4GNDXRWY7/gSe5K0lrl8Y7L7fS2EHTJMsJx/MZ1q8NL2qSbAk7sZpkXMmFlSOBwXUg9RKN9eH/6TT6f1CZLOHc6vqjT11XXbdrKNgy6y9wNCipuef+PKK9OMrlxxh/yQjJ2TvA7rrPvP+Bg==
set ssl enable
set ssl-trusted-cert "SERBA-CA"
next
end
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.
Przykład potencjalnego problemu
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:
W tym poradniku opiszę krok po kroku jak wykorzystać domenę
Active Directory w Fortigate, by móc tworzyć polityki bazowane na
użytkownikach/grupach AD. Porady są napisane w oparciu o urządzenie FortiWiFi
60E z systemem FortiOS 6.2.3.
Na samym początku należy zdefiniować serwer DNS w ustawieniach Fortigate’a po to, by Fortigate mógł rozwiązywać nazwy DNS w domenie, w moim przypadku serba.local. Zrobimy to w Network > DNS (w moim przypadku adres 192.168.30.2):
Po tym należy zdefiniować serwer LDAP w zakładce User & Device > LDAP Servers klikając przycisk Create New:
Następnie uzupełniamy pola w następujący sposób:
Name: nazwa profilu, dowolna,
Server IP/Name: adres IP/nazwa FQDN kontrolera domeny, można tutaj dodać jeden kontroler domeny (drugą można dodać w CLI),
Server Port: port, który używamy do komunikacji z LDAPem, dla LDAP to jest domyślnie 389, dla LDAP 636 (TCP),
Common Name Identifier: podajemy tutaj pole obiektu, na podstawie której wyszukujemy użytkownika w AD. Te pole jest wykorzystywane też przy logowaniu jeśli zintegrujemy np. logowanie administracyjne do Fortigate’a. Na przykład: cn w moim przypadku to by było Radosław Serba, sAMAccountName to rserba, a userPrincipalName to rserba@serba.local. Najlepiej korzystać z jednego z tych dwóch ostatnich pól.
Takie pole można sobie sprawdzić w przystawce Użytkownicy i komputery usługi Active Directory mając zaznaczoną opcje Widok > Opcje zaawansowane. Poniżej przykład z zaznaczonym polem userPrincipalName:
Distinguished Name: w tym polu określamy DN obiektu w Active Directory na podstawie którym szukamy obiektów znajdujących się gałąź niżej. W przypadku wskazania początku drzewka, czyli samej domeny, mamy możliwość wyszukiwania we wszystkich podfolderach typu Users i dowolnym OU znajdującym się w domenie. Zakładając, że domena się nazwa serba.local DN to DC=serba,DC=local. Każdy segment nazwy domeny jest oddzielany przecinkiem i wstawiany do osobnego elementu DC. Tutaj można znaleźć więcej przykładów konfiguracji.
Bind type: w tym polu określamy sposób wyszukiwania obiektów, to jak one działają jest dobrze opisane tutaj. W moim przypadku korzystam z opcji Regular.
Username: definiujemy użytkownika, który najlepiej jeśli będzie wykorzystywany do odpytywania AD pod kątem tego gdzie jakie obiekty się znajdują. Potem z tego samego konta możemy korzystać w agencie FSSO. Podajemy po prostu nazwę użytkownika w formacie domena\użytkownik, w moim przypadku SERBA\fsso.
Password: to jest raczej oczywiste.
Secure Connection: gdy zaznaczone, włączamy komunikację z LDAPS, w którym musimy załączyć certyfikat w polu Certificate oraz określić sposób protokół w polu Protocol.
Po wszystkim warto sobie sprawdzić czy mamy połączenie z serwerem poprzez kliknięcie Test Connectivity. Jeśli mamy status Successful to wszystko jest w porządku. Poprzez Test User Credentials możemy sprawdzić czy jeśli byśmy potem zintegrowali np. logowanie do strony konfiguracyjnej Fortigate’a czy nasz login by zadziałał poprawnie. Poniżej przykład:
Następnie, aby wykorzystywać FSSO należy zainstalować poszczególne komponenty w odpowiednich miejscach:
Domain Controller (DC) agent – musi być zainstalowany na każdym kontrolerze w domenie,
Citrix/Terminal (TS) agent – musi być zainstalowany na każdym terminalu jak ten od Citrix, VMware Horizon 7.4 czy Usługi pulpitów zdalnych w Windows Server,
Collector (CA) agent – zbiera dane z logowania z agentów DC lub poprzez bezpośrednie odpytanie z AD (z wykorzystaniem LDAP). Maksymalnie na urządzenie można podpiąć takich agentów 5. CA korzysta z portów 8000 TCP (komunikacja z Fortigate’ami) oraz UDP 8002 (komunikacja z agentami DC). W przypadku dużych instalacji można wykorzystać FortiAuthenticator zamiast CA. W przypadku instalacji z wieloma kontrolerami domeny najlepiej taki CA zainstalować na maszynie niebędącej kontrolerem domeny, lecz pracującym 24/7.
W przypadku posiadania Microsoft Exchange Server istnieje także możliwość analizowania logowania do takiego serwera, najprostszym rozwiązaniem jest przekierowanie logów z serwera Exchange na inny serwer na którym jest zainstalowany agent AD, który kontaktuje się z CA.
By pobrać potrzebne pliki, należy się zalogować na stronie https://support.fortinet.com, następnie przejść do zakładki Download > Firmware images:
Najlepiej ściągnąć plik zaczynający się na FSSO_Setup, bo zawiera on agenta DC i CA. W tym przypadku FSSO_Setup_5.0.0287_x64.exe. Znajdziemy to po wybraniu sekcji FortiGate, karty Download, a następnie wybierając ścieżkę /FortiGate/v6.00/6.2/6.2.3/FSSO/ (oczywiście w przypadku nowszych wersji najlepiej wybrać najnowszą).
Zanim zaczniemy instalację, warto utworzyć wcześniej wspomnianego użytkownika serwisowego, w moim przypadku jest to fsso. Możemy to zrobić w przystawce Użytkownicy i komputery usługi Active Directory:
Powinniśmy też dodać tego użytkownika do grupy Czytelnicy dziennika zdarzeń (na stałe, eng. Event Log Readers) oraz Administratorzy domeny (na czas instalacji agentów, eng. Domain Admins).
Następnie możemy przystąpić do instalacji. Klikamy Next.
Następnie akceptujemy warunki i postanowienia umowy licencyjnej.
Następnie zostawiamy ścieżkę instalacyjną programu bez zmian.
Na tym etapie wskazujemy wcześniej utworzone konto. Będzie ono wykorzystywane do uruchamiania usługi FSSO. Podajemy dane logowania według podanego w oknie schematu i przechodzimy dalej.
W następnym polu zostawiamy pola zaznaczone i wybieramy tryb Advanced, następnie przechodzimy dalej.
Na końcu klikamy dalej, by rozpocząć instalację agenta.
Po instalacji zostawiamy zaznaczoną opcję Launch DC Agent Install Wizard.
Tutaj wskazujemy adres IP maszyny, na której jest agent CA. W moim przypadku jest to kontroler domeny, bo ten przypadek zakłada 1 kontroler domeny i mam wszystkie agenty na jednej maszynie, stąd wskazany adres w polu Collector Agent IP address to 192.168.30.2. W Collector Agent listening port nie wykonujemy zmian i przechodzimy dalej.
Wskazujemy z listy domeny, w których chcemy monitorować logowania użytkowników. W moim przypadku jest tylko jedna, więc pozostawiam ją zaznaczoną i przechodzę dalej.
Następnie wybieramy użytkowników, dla których nie monitorujemy logowania. Są to po prostu konta do usług, takie jak np. krbtgt. Po zaznaczeniu przechodzimy dalej.
Teraz wskazujemy kontrolery domeny na których będziemy monitorować logowania. W tym przypadku mam 1 kontroler, więc też pozostawiam go jako zaznaczony. Monitorowanie może się odbywać na dwa sposoby: DC Agent Mode (wymaga instalacji agenta DC) i Polling Mode (odpytywanie bezpośrednio kontrolerów domeny o logowania). Osobiście odradzam z korzystania z Polling Mode szczególnie w dużych środowiskach, bo ta metoda nie jest dokładna i czasami nie wyłapuje logowań użytkowników, gdy ci się logują na konta w tym samym czasie (jeśli wszyscy w organizacji zaczynają pracę w tym samym czasie to właśnie tak jest). Polecam tryb DC Agent Mode i tutaj go zaznaczyłem. Przechodzimy dalej, przy czym warto wziąć pod uwagę to, że po tym etapie ten agent DC zostanie zainstalowany na wskazanych kontrolerach domeny.
Po instalacji należy zrestartować system na kontrolerze domeny, dlatego też zatwierdzamy monit.
Następnie musimy wykonać kilka zmian dla naszego konta serwisowego, by było ono skonfigurowane bezpiecznie, poza tym musimy odblokować porty w firewallu do umożliwienia komunikacji z Fortigate’m. Otwieramy Edytor rejestru (regedit).
Następnie przechodzimy do klucza Komputer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Fortinet\FSAE\collectoragent, klikamy na ten folder PPM i wybieramy Uprawnienia… i dodajemy naszemu użytkownikowi serwisowemu uprawnienia Pełna kontrola do modyfikacji tej gałęzi rejestru.
Po dokonaniu zmian klikamy OK.
W taki sam sposób zmieniamy uprawnienia temu użytkownikowi do zawartości katalogu instalacyjnego agenta: C:\Program Files (x86\Fortinet\FSAE tak, by ten miał uprawnienia Pełna kontrola.
Gdy mamy to za sobą, możemy temu użytkownikowi usunąć członkostwo w grupie Administratorzy domeny. Nadal trzeba o tym pamiętać, by był w grupie Czytelnicy dzienników zdarzeń (jest w ukrytym folderze Builtin).
Następnie tworzymy politykę GPO, która nie pozwala na logowanie tego konta na komputerach. Z faktu, że to konto ma być wykorzystywane tylko do usług, możemy zabronić takiego wykorzystywania. Tworzymy obiekt zasad grupy na początku drzewka klikając na niego PPM i wybierając Utwórz obiekt zasad grupy w tej domenie i umieść tu link….
Następnie definiujemy nazwę obiektu.
Po tym klikamy na niego PPM i wybieramy Edytuj….
Przechodzimy do opcji Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zasady lokalne > Przypisywanie praw użytkownika i w zasadzie Odmowa logowania lokalnego zaznaczamy Definiuj następujące ustawienia zasad oraz dodajemy naszego użytkownika serwisowego.
Następnie powinniśmy zrobić drugi obiekt zasad grupy dla kontrolerów domeny, w którym pozwalamy na logowanie jako usługa dla wspomnianego konta serwisowego. Po stworzeniu obiektu klikamy PPM na obiekt, następnie Edytuj….
Przechodzimy do opcji Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zasady lokalne > Przypisywanie praw użytkownika i w zasadzie Logowanie w trybie usługi zaznaczamy Definiuj następujące ustawienia zasad oraz dodajemy naszego użytkownika serwisowego.
Następnie tworzymy trzeci obiekt dla kontrolerów domeny, w którym zdefiniujemy polityki Zapory Windows Defender. Przechodzimy w edytorze zarządzania zasadami grupy do Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zapora Windows Defender z zabezpieczeniami zaawansowanymi > Zapora Windows Defender z zabezpieczeniami zaawansowanymi – LDAP://<adres obiektu> > Reguły przychodzące (lub Reguły wychodzące), klikamy na puste pole PPM i wybieramy Nowa reguła….
W kreatorze wybieramy regułę, w której definiujemy porty i definiujemy je następująco:
Reguły przychodzące: TCP 8000, TCP 8001, UDP
8002
Reguły wychodzące: TCP 8000, TCP 8001, UDP 8002
W następnym etapie wygląda to tak:
Następnie zezwalamy na połączenie.
W zastosowaniu reguły możemy zostawić ustawienia domyślne (wszystkie poziomy).
Na końcu definiujemy nazwę reguły i klikamy Zakończ.
Powtarzamy to dla portu UDP 8002, a potem powtarzamy obie reguły dla ruchu wychodzącego.
Po dodaniu reguł to powinno wyglądać mniej więcej tak:
Następnie musimy upewnić się, że FSSO Agent jest poprawnie skonfigurowany. Otwieramy Fortinet Single Sign On Agent Configuration i definiujemy hasło w przy zaznaczonym polu Require authenticated connection from Fortigate. Istotne jest to, że to nie jest te same hasło jak do konta serwisowego na prawach którego pracuje usługa dla agenta FSSO.
Teraz musimy podłączyć tego agenta w Fortigate’cie. Otwieramy stronę Security Fabric > Fabric Connectors, a następnie klikamy na Create New.
Następnie z listy connectorów w sekcji SSO/Identity wybieramy Fortinet Single Sign-On Agent.
Następnie w Name definiujemy nazwę profilu, w Primary FSSO Agent definiujemy FQDN/adres IP naszego serwera z agentem FSSO (w moim przypadku dc1.serba.local/192.168.30.2), potem w polu Password hasło, które definiowaliśmy w konfiguracji FSSO. W LDAP server wybieramy nasz zdefiniowany wcześniej profil serwera LDAP (w moim przypadku nazywa się serba.local), następnie User group source wybieramy opcję Collector Agent. Po tym można kliknąć Apply & Refresh.
W efekcie, gdy poczekamy chwilę i wejdziemy do ustawień
ponownie, zobaczymy, że liczba w Users/Groups zmieni się z 0 na ilość
naszych obiektów w AD (w moim przypadku 114). Poza tym, będąc w Security Fabric
> Fabric Connectors jeśli widzimy zieloną strzałkę do góry – to oznacza
poprawnie nawiązane połączenie. W moim przypadku miałem problem na początku z
firewallem, bo nie odblokowałem portów i z tego względu strzałka była w dół na
czerwono.
Sprawdzenie działania agenta FSSO w praktyce jest dosyć proste – wystarczy przejść do Monitor > Firewall User Monitor, a następnie na górze kliknąć Show all FSSO Logons i sprawdzić, czy są zalogowani jacyś użytkownicy (logowanie musi nastąpić po uruchomienia agenta FSSO na maszynie):
Mając to skonfigurowane możemy zrobić 2 rzeczy: dodać dostęp administracyjny administratorom domeny i stworzyć grupy lokalne w Fortigate’cie, które będą zawierały grupy z Active Directory, które docelowo będą wykorzystane w politykach bezpieczeństwa.
Dodanie dostępu administracyjnego do Fortigate bazującego na grupie w AD
Tutaj musimy stworzyć grupę bazującą na obiektach odczytywanych bezpośrednio przez LDAP (bez użycia agenta FSSO). W User & Device > User Groups klikamy Create New:
W Type zostawiamy zaznaczoną opcję Firewall, następnie w sekcji Remote Groups klikamy przycisk Add:
Następnie po otworzeniu karty po prawej stronie wybieramy w polu Remote Server nasz skonfigurowany obiekt serwera LDAP (w moim przypadku serba.local). Następnie w wyszukiwarce możemy wpisać frazę, która nas interesuje, nacisnąć Enter by uruchomić wyszukiwanie i kliknąć PPM na element listy i wybrać Add selected, a następnie kliknąć OK.
Po dodaniu wygląda to tak:
Klikamy OK. Następnie przechodzimy do System > Administrators i Create New i z listy wybieramy opcję Administrator:
W Username wpisujemy cokolwiek, w Type wybieramy Match all users in a remote server group, definiujemy profil administracyjny (definiuje uprawnienia administratora) w Administrator profile (maksymalne uprawnienia to grupa super_admin) i definiujemy w Remote User Group definiujemy grupę, którą przed chwilą stworzyliśmy. Po tym dajemy OK.
W przypadku, gdybyśmy chcieli korzystać z FortiTokenów dla tych użytkowników – musimy zdefiniować administratorów wpisując właściwą nazwę użytkownika w Username i wybierając w Type opcję Match a user on a remote server group.
Stworzenie polityk firewalla bazujących na obiektach AD
Na samym początku musimy utworzyć grupy bazujące na FSSO. W User & Device > User Groups klikamy Create New:
Definiujemy w Name nazwę grupy, następnie wybieramy w Type opcję Fortinet Single Sign-On (FSSO) i w Members klikając plusa, a następnie w wyszukiwarce wyszukujemy grupę, która nas interesuje i klikamy na nią LPM, a potem klikamy OK:
Dla przykładu utworzyłem 2 grupy bazujące na grupach w AD Administratorzy domeny (mają pełne uprawnienia administracyjne na wszystkich komputerach w domenie) i Użytkownicy domeny (wszyscy użytkownicy w domenie).
Następnie przechodzimy do Policy & Objects > IPv4 Policy i tam tworzymy polityki, w których definiujemy w polach:
Name: wedle uznania,
Source: wskazujemy podsieć, w której znajdują się użytkownicy AD oraz grupę AD względem której chcemy definiować dostęp np. domain admins LDAP z mojego przykładu,
Destination: lokalizacja, dla której chcemy wskazać dostęp, dla wszystkich adresów wybieramy obiekt all,
Schedule: always, bo chcemy by reguła działała cały czas,
Service: ALL, bo chcemy, by reguła działała względem wszystkich portów TCP/UDP/ICMP,
Action: ACCEPT, bo chcemy przepuścić ruch.
Następnie w sekcji Security Profiles defiinujemy konkretne polityki bezpieczeństwa, na przykład nie włączamy web filteringu, bo w końcu administratorzy muszą mieć możliwość, by testować połączenie 😉.
Potem w podobny sposób tworzymy politykę z użyciem drugiej grupy i tam dajemy jakiś filtr web filteringu. Potem z faktu, że wszyscy członkowie Administratorzy domeny są członkami grupy Użytkownicy domeny, ustawiamy politykę z administratorami wyżej. Jeśli ktoś nie jest adminem, wtedy względem jego ruchu zostanie zastosowana polityka poniżej.
Jak widać, dodałem też osobą politykę dla kontrolera domeny, bo jednak jeśli nie weźmiemy go pod uwagę (a z reguły nikt na nim nie jest zalogowany) to ten serwer nie będzie mógł się z niczym łączyć. Oczywiście to można skonfigurować lepiej niż na zrzucie ekranu, po prostu to jest szybki przykład działania w praktyce.
Troubleshooting FSSO
Jeśli macie brak połączenia w ustawieniach Fabric Connectora, problemy najczęściej są cztery:
Nieodblokowane porty na firewallu,
Nieprawidłowe hasło do agenta FSSO,
Niewystarczające uprawnienia dla konta
serwisowego, na prawach którego pracuje agent FSSO,
Niepoprawnie skonfigurowany adres DNS w
Fortigate prowadzący do domeny AD.
Linki do dobrych poradników do troubleshootingu można znaleźć tutaj i tutaj:
Do troubleshootingu najlepiej sobie uruchomić CLI i w nim wykonać 2 polecenia:
To spowoduje, że będziemy widzieli pojawiające próby połączenia się z agentem FSSO przez Fortigate’a. Warto po tym wykonać polecenie:
diagnose debug authd fsso server-status
Wynik wygląda tak:
supra-forti # diagnose debug application authd 8256
Debug messages will be on for 30 minutes.
supra-forti # diag debug enable
supra-forti # diagnose debug authd fsso server-status
Server Name Connection Status Version Address
----------- ----------------- ------- -------
serba.local connected FSSO 5.0.0287
Tutaj wszystko jest w porządku, ale jeśli Connection
Status nie jest connected, a w Version nie ma wersji agenta
FSSO – to oznacza, że firewall blokuje nam połączenie pomiędzy Fortigate’m a
agentem.
Jeśli otrzymujemy w konsoli regularnie coś wyglądającego jak to:
Server challenge:
7b 6e 93 2d 40 37 90 24 0a 00 0e 67 92 2a 82 06
MD5 response:
1b d7 74 10 cd 29 c5 e6 53 2b 6d de a0 c5 d1 1f
_process_auth[FSSO_collector]: server authentication failed, aborting
disconnect_server_only[FSSO_collector]: disconnecting
To oznacza, że albo hasło w agencie FSSO nie zgadza się z
tym w konfiguracji Fabric Connectora albo nasze konto serwisowe nie ma wystarczających
uprawnień na którymś z etapów, który jest opisany wcześniej.
Jeśli pojawia się coś takiego to wszystko jest w porządku z połączeniem z agentem:
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111010
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111011
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111012
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111013
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111014
fsae_io_ctx_process_msg[serba.local]: received heartbeat 111015
