Wyświetlanie listy przydziałów z DHCP w FortiGate (CLI)

Przeczytasz to w: < 1 minut
anzena-forti # anzena-forti # execute dhcp lease-list internal7
internal7
  IP            MAC-Address             Hostname            VCI                 SSID                AP                  Expiry
  192.168.30.102        00:0c:29:2e:9a:42       endpoint-3          MSFT 5.0                                                    Wed Jun 17 13:07:42 2020
  192.168.30.103        00:0c:29:23:aa:4a       xubuntu                                                                         Wed Jun 17 22:03:58 2020
  192.168.30.100        00:0c:29:c9:58:c6       ENDPOINT-1          MSFT 5.0                                                    Fri Jun 19 10:30:52 2020
  192.168.30.104        00:0c:29:7c:6a:73       gns3vm                                                                          Fri Jun 19 11:38:13 2020
  192.168.30.101        00:0c:29:27:fc:19       endpoint-4          MSFT 5.0                                                    Tue Jun 23 08:04:09 2020

Dodanie dodatkowych kontrolerów domeny w FortiGate do profilu LDAP, włączenie komunikatów o wygasających hasłach i opcja na odnowienie ich

Przeczytasz to w: < 1 minut

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

Zmiana nazwy certyfikatu CA w FortiGate

Przeczytasz to w: < 1 minut

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

Wake on LAN na FortiGate i Mikrotiku

Przeczytasz to w: < 1 minut

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.

Certyfikat w agencie FSSO dla FortiGate

Przeczytasz to w: 6 minut

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:

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIeJPiXvMmk/gCAggA
MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECGT+mYCIj3sOBIIEyKw37DJsFB6q
GzhFg4K8z71ffvVeEYJwpH5t6PdH5Scg8dV1yXMbKdEL3ZDzpk0sVnghjAb6Z/YW
dXXTeO8oAQqBCdt6B7a+6cA7+Gp3xHOEQlZKE/ijFkvBPPL4cFP3LQ+yQkfzI0i9
sZuuocF8srxtIuOYPbb6DVJZI0C+xB0/QWQnF4WdyncYNt4cXTaxU0kZrC7LDNnO
AIULHXAzhedntLUTViD26w2VhvqOxAwXxarVRNQuKevG0JLjvD/kK5AoufeIpusr
kfNhP3sT9ITPI5P9G7nJSLl8CaLRa8DO8WxxMN/UBppwXBg4BfWqtfQG4GyW+8Xw
pF4dnJrywOtAuVWY2bZnb6CBJGd3JCAqgt+c+ROGM9HjromsfYu1vMgBZ6d9iZ29
EeQhkLGeISjXWDI6t9D8WCNEcWD7Fs7wPq1jmSdo9Dx7GU2kcoEjHB1S38Kgy7u/
nXSb6YcwkRX7pZy5Or2ATL2i/yf2Pu93z8dP5v099gJqcSajeIAxvdLf9A5kdGsr
x6VWZWYldA4CN963jEG7e8vXorF8+QZe9W7M7sZ/K7xHRapklo4i7QExL/WcLOE5
5e7amAiesYjTzqaQKouTY+UXLm9EG/Czjc1tMIaYr3WCxX92RSB1GB1AP2U/epmh
oL9AqPtoe4jT+xQPnipCypxRSn1xnZV90rgNusEiVaC5nhVlOHSABE2BEHi/xjTr
t1v2yzxSXn+g4+olx6iKzHRxR0yTt2duU63LjD8eFj2WxDs07O+31uWZ9BEHyPmP
8bELgEg0H9IqK2AJRyCGN1SFLi7yt5hekbk0CixZryScjPT2C6HLeca7ghEuRmvL
L6dv1rRM2pKKdrX1FtDkVntj2Evt4ngYJnVoK3EbIxxwAxHpv35h5RHYFowyO8kO
uttBvbEqOz8KZpprPbT3g9qlITyuRqULT8Yi+0+X6JIEJ0ayEDz8+1226R6osoGe
w5kwT8POQTrkMuutyO5huPKWMgLR74XM18tUHI5k/x/698C1QLtSXACtheteH5x+
nUKJOVTraScoX5DOE+kQ7D7FnRR1uJyQdh5+XcF6mZ1tcZcsDiu9HiUHD12xP1dM
wEqMyd6mBl1AxJVuf72aXBpSi7A58zeqKc7CdMovdm/uRVHzXHPcKUYy8fAtrJFN
OVJ7nZGLBVpSKroKXuM06PgR7QYrs42HmXopkD8w5h7qRJV8zxCc0iUl1dU7511f
MspTboffXGOkj+3jp80aAoWTm4axMvsklUN6zzxoNgsGUBmdv/twxtJzv8TLFFTz
I+WldMQ4JUINrWEHYSbYcgbn7MycvwLv9+f8a+I3KHQglRMk+LTulQLcU/wwM36e
4/F11Cr0NqjMp0jNRC6D+P7up9FHD2McXaCvtcXopWgmpa4RoGRl/IdmJtC+q3oF
Qomt71wLsgiv4J84mt+XKPfJhbJeaAcLRJAka2zk7KmLGkAKQYu1yMb480H5eOwF
Yck1Eh39ciLpysIPNnk7ZQ+t2dX/r3VrrMwnbrsFXzl14VsPJd7vLuh9nH8Zx8gS
fNVFCt/hB1mJ+zeTP6qgJiSLzjCn5lg85NzGDWela3F8CsVR3+7Qms4m66yqSFm+
QemTVykHMDke5IP1mFj3OA==
-----END ENCRYPTED PRIVATE 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:

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C=PL
ST=SL
L=Tychy
O=it.supra.tf
OU=IT
emailAddress=radoslaw@serba.ovh
CN = fsso-collector.serba.local

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = fsso-collector.serba.local

Mając coś takiego gotowe tworzymy sobie CSR poleceniem:

openssl req -new -sha256 -key local.key -out fsso-collector.serba.local.csr -config config.cnf

W ten sposób otrzymujemy coś takiego:

-----BEGIN CERTIFICATE REQUEST-----
MIIDEzCCAfsCAQAwgZUxCzAJBgNVBAYTAlBMMQswCQYDVQQIDAJTTDEOMAwGA1UE
BwwFVHljaHkxFDASBgNVBAoMC2l0LnN1cHJhLnRmMQswCQYDVQQLDAJJVDEhMB8G
CSqGSIb3DQEJARYScmFkb3NsYXdAc2VyYmEub3ZoMSMwIQYDVQQDDBpmc3NvLWNv
bGxlY3Rvci5zZXJiYS5sb2NhbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALjPgatD84GPdQlt5GytCUSjs7Mr4k3yn7mUW2QbEr9zAQ5/uRWo/rep6ptr
N2HBP4vFzCTGA4c1OGwg0yzzkz3uGEVUiJ0qdudutHGYEfDpr2Hd0kH6eH7MIqGx
GBqhe9+XRugtSojE2jDPGL3UU2eDhx8fzzovbbi+IyuOsOEtCwGl2FvPP9AnT2/s
owTOxlU2ZqaAauL+72pa0ciSdDfWh9Lat2FeWIPD34qAt/n9yK4fXpSWgWm0y+zB
ackruljZxd6gw4x0KBKdUq+a8vPdz6RK2ODBnQEG02DkxvdjfgzkzX2aNbR9QWAC
HuPGB6FdzidIf+UoBUaUKrFabhMCAwEAAaA4MDYGCSqGSIb3DQEJDjEpMCcwJQYD
VR0RBB4wHIIaZnNzby1jb2xsZWN0b3Iuc2VyYmEubG9jYWwwDQYJKoZIhvcNAQEL
BQADggEBADa3+JoA0OjayAo2e9IX232mHrzgPtF4B4IY61xQACuIsqQW7IoLIaR5
h5HyPhRENecWws6ORwBcnKvIJykuXj4H1PaacUiTQgkOIAPnSltjGIkA8cnvtQYA
RrsKx4QTgbtr64+1E2xFRN+3Z6cOwyDB8yhOCS2k4UnyuC5XSJsQySI0GFqGdVGl
wLsT8IYQRcMkvlih3g+7hARb9C9TNW/se/UN/xL/q3ssWZfZ3QRuphDpn1zYo5au
XeuIXilt+R3bDvW3o5ThyKta/mGSt0Zr01KxviNalHvqLSYXSf4eHErstimNrqJp
+l05rq3qpcmbTp6Rq7IJ5F4j6hp2axI=
-----END CERTIFICATE REQUEST-----

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

Serwery terminalowe i drugi kontroler domeny Active Directory we współpracy z agentem FSSO FortiGate’a

Przeczytasz to w: 6 minut

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.

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:

Integracja FortiGate z Active Directory z wykorzystaniem FSSO

Przeczytasz to w: 12 minut

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.

Instalacja agenta CA i TS na kontrolerze domeny

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:

diagnose debug application authd 8256
diag debug enable

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