W tym edytuję configi. W sumie to cokolwiek. Visual Studio Code, polecam.
Sporo osób mnie pytało o to jak sobie z tym poradzić, niektórzy nawet sprzedają własne configi (XD), więc stwierdziłem, że postaram się trochę z tym pomóc raz na zawsze. Postaram się wyjaśnić jak ogólnie configi działają, co jeśli używacie MasterComfiga, jak ustawić configi na osobnych klasach i dam kilka przykładów z mojego setupu.
Czy Twój config jest najlepszy?
Odpowiedź jest prosta: nie. Dla mnie jest on najlepszy, ale to nie znaczy, że taki ma być dla każdego. Dostosowałem swój config do swojego sprzętu, dlatego mi tak pasuje. Nie każdy tak jak ja ma klawiaturę ze średnim rozmiarem (to znaczy mam strzałki i klawiaturę numeryczną połączoną razem) czy myszkę ze strzałkami back/forward (które wykorzystuję też w grze). Najlepszy config, który jest dla Ciebie to taki, który Ci samemu najbardziej odpowiada. Coś Ci nie pasuje? Zmień to i sprawdź, czy teraz jest lepiej. W ten sposób możesz własną drogą dotrzeć do najlepszego configu.
Tak to wygląda u mnie.
W czym najlepiej edytować configi?
W tym, co lubisz. Ja osobiście polecam Visual Studio Code – działa na Windowsie i na Linuksie (pozdro Kartky), najważniejsze w nim jest to, że podkreśla składnie i ma kilka tricków, które pozwala nam łatwiej znaleźć błędy w składni, szybko coś skopiować i podmienić. Niektórzy boomerzy używają Notepada++ i to jest okej – wszystko jest lepsze od Notepada, który nie ma podkreślania składni (syntax highlighting). Wiadomo, jak ktoś używa Linuksa to tam prawie każdy edytor tekstu ma podkreślanie składni i tam nie ma o co się martwić. Na dobrą sprawę w czymkolwiek można edytować configi. Kwestię macOSa przemliczę – od 10.15 Catalina nie da się odpalać aplikacji 32-bitowych natywnie, więc nie pogracie sobie tak łatwo w TFa (jest opcja Wine, ale to ponoć jest dramat).
Okej, no to jak to działa?
Działa to tak: Najczęściej operujemy na takich configach:
config.cfg – główny config gry, w nim są przechowywane aktualne ustawienia. Jeśli coś ustawiliście w grze (np. z konsoli) to takie rzeczy pewnie będą tutaj, nie wprowadzamy tutaj zmian, ten config jest odpalany w pierwszej kolejności. Jeśli mamy zdefiniowane jakieś ustawienia na konkretnej klasie i zamkniemy grę – one będą też w tym configu.
autoexec.cfg – ten config zawiera wszystkie nasze rzeczy, które chcemy mieć skonfigurowane i odpala się po config.cfg, tutaj wykonujemy wszystkie zmiany, które nas interesują.
scout.cfg – config z ustawieniami dla Skauta.
soldier.cfg – config z ustawieniami dla Żołnierza.
pyro.cfg – config z ustawieniami dla Pyro.
demoman.cfg – config z ustawieniami dla Demomana.
heavyweapons.cfg – config z ustawieniami dla Grubego.
engineer.cfg – config z ustawieniami dla Inżyniera.
medic.cfg – config z ustawieniami dla Medyka.
sniper.cfg – config z ustawieniami dla Snajpera.
spy.cfg – config z ustawieniami dla Szpiega.
inne configi, które wrzucimy sami, np. jump.cfg – to, co w nich jest zależy od nas.
Configi klas włączają się w momencie wybrania klasy, więc jeśli zmienimy klasę na Snajpera, po prostu załaduje się sniper.cfg i to, co w nim jest. Na dobry początek najłatwiej zacząć od obserwowania jakie configi mają inni – niby tutaj jest lista wszystkich ustawień w grze, ale komu by się chciało to przeglądać? Dlatego najlepiej jak zobaczycie, że ktoś używa jakiegoś innego celownika, ma np. podgląd klasy na dole w 3D itd. Potem połączcie to razem ze sobą i voilà – macie swój config. Tutaj znajdziecie więcej info o moim setupie.
Na wstępie powiem, że będę używał słowa zmienna (ang. variable). Te słowo określa jakieś konkretne ustawienie. Możemy je określać na różne sposoby, na przykład są ustawienia, w których musisz podać jakąś wartość (np. fov_desired 90) i im większa/mniejsza wartość tym ustawienie jest bardziej widoczne (w tym przykładzie większa wartość daje większe pole widzenia i maksymalna wartość to 90). Są też zmienne, w których określamy czy dane ustawienie ma być włączone czy nie. Jeśli jest włączone to dajemy 1, jeśli wyłączone to dajemy 0. Przykład: cl_autoreload 1 (w ten sposób mamy włączone automatyczne przeładowywanie broni). Wartości ustawień warto podawać w cudzysłowie, czyli np. zamiast fov_desired 90 dajemy fov_desired "90". Po co? W tym przypadku akurat to nic nie zmienia, ale jeśli wartość zawiera spację to wtedy polecenie może nie działać poprawnie (nie chcę dokładnie wyjaśniać dlaczego, chcę by ten poradnik był możliwie jak najprostszy do zrozumienia), więc można być trochę takim pedantem i dawać te cudzysłowie za każdym razem. Wtedy unikniemy problemów. W configach ustawiamy trzy rzeczy:
zmienne,
bindy,
aliasy.
Zmienne przedstawiłem już na samej górze. To jest coś, co oferuje nam gra jako ustawienie. Bind jest przypisaniem danej funkcji do przycisku, a alias alternatywną nazwą funkcji. Funkcja to jest w uproszczeniu coś, co wykonujemy – na przykład funkcja slot1 powoduje, że wybieramy broń pierwszorzędną dla naszej klasy. Alias jest alternatywną nazwą jakiegoś ustawienia lub zestawu kilku ustawień – np. możemy przypisać zmianę broni na pierwszorzędną oraz wyłączenie modelu w jednym poleceniu, przykład:
alias first "slot1; viewmodel_fov 0; r_drawviewmodel 1"
W ten sposób jak przypiszę taki alias do przycisku 1 (tego nad przyciskiem Q):
bind 1 "first"
Listę wszystkich przycisków można znaleźć tutaj. Ogólnie warto też przeczytać sobie tę stronkę w całości – jest tam mnóstwo podstawowych porad dotyczących robienia configów.
Jeśli chcemy mieć jakieś konkretne ustawienia, które mają działać na wszystkich klasach – wrzucamy do autoexec.cfg, jeśli takie ustawienia mają być na konkretne klasy – wrzucamy te same ustawienie do configu konkretnej klasy, np. ten sniper.cfg. Jeśli ustawiamy jakieś specyficzne ustawienie na konkretną klasę, na przykład przypisujemy ustawienie do prawego przycisku myszki to powinniśmy ustawić takie ustawienie na każdej klasie. Dajmy przykład tego prawego przycisku myszki – ja na skaucie i soldzie mam zmianę broni na ostatnią. Jeśli chcemy, by ten prawy przycisk myszki działał nam tak jak działał dotychczas to powinniśmy sprawdzić co mamy ustawione na tych klasach i wpisać to do configów tych klas. Prawy przycisk myszki to MOUSE2 na każdej myszce, więc sprawdza się to, co tam jest poleceniem bind MOUSE2:
] bind MOUSE2
"MOUSE2" = "+attack2"
Ostatnią broń wybiera funkcja lastinv. W takiej sytuacji na poszczególnych klasach dodajemy:
scout.cfg
bind MOUSE2 "lastinv"
soldier.cfg
bind MOUSE2 "lastinv"
pyro.cfg
bind MOUSE2 "+attack2"
demoman.cfg
bind MOUSE2 "+attack2"
heavyweapons.cfg
bind MOUSE2 "+attack2"
engineer.cfg
bind MOUSE2 "+attack2"
medic.cfg
bind MOUSE2 "+attack2"
sniper.cfg
bind MOUSE2 "+attack2"
spy.cfg
bind MOUSE2 "+attack2"
Tutaj te zmiany dla skauta i solda można zrobić lepiej. Prawy, lewy przycisk myszki i spacja mogą sterować kamerą jak się jest obserwatorem i warto je przypisać zamiast tak:
bind MOUSE2 "lastinv"
zrobiłbym to tak:
alias "attack2linv" "lastinv; spec_prev"
bind "MOUSE2" "attack2linv"
Warto do tej funkcji na prawym przycisku myszki dodawać spec_prev, bo w ten sposób nie odbieramy sobie możliwości przesuwania na tym przycisku. W przypadku lewego przycisku myszki dodaje się przycisk spec_next. W przypadku spacji dodaje się spec_mode.
Jak na danym przycisku chcecie mieć przycisk, który nie robi nic, np. na F4 nic nie potrzebujecie, dodajcie na tej klasie linijkę:
unbind F4
Po co te wszystkie przypisania na każdej klasie? Powiedzmy, że w configu pootisa nie wrzucimy takiego przypisania do prawego przycisku myszki. Jeśli zmienimy klasę to będzie na takim pootisie działało ustawienie z poprzedniej klasy i wtedy mogą wystąpić dwa przypadki:
jeśli poprzednia klasa, na której graliśmy miała bind bind MOUSE2 "+attack2" (na przykład Snajper) to nic się nie stanie,
jeśli poprzednia klasa miała inny bind na tym przycisku (np. sold i skaut w naszym przypadku ma bind MOUSE2 "lastinv" to pootis zamiast rozkręcać miniguna prawym będzie zmieniał broń. To jest słabe.
Jeszcze co do funkcji z + i - na początku, np. +forward – o co chodzi? Funkcje z plusem są wykonywane, gdy przycisk jest wciśnięty, a z minusem, kiedy go puszczamy, więc +forward powoduje, że idziemy do przodu, a -forward powoduje, że przestajemy iść do przodu. To można wykorzystać np. przy tzw. winger jumpie, czyli skoku, w którym wykorzystujemy właściwość Wingera (pol. Skrzydłowy) na skaucie po to, by podskoczyć wyżej i z powrotem zmienić broń na Scatterguna (pol. Dubeltówka). Wtedy trzeba zrobić dwa aliasy: z plusem i minusem, a potem do przycisku przypisać alias z plusem, a gra sama będzie wiedziała, że ta z minusem też istnieje, przykład:
alias +wjump "slot2; +jump; +duck"
alias -wjump "lastinv; -jump; -duck"
bind MOUSE5 "+wjump"
Jak testować configi?
To dosyć proste. Wpisujecie w konsoli exec naszconfig i w ten sposób sprawdzacie wyniki. Zmiany są najczęściej widoczne natychmiast. Mało tego exec naszconfig może być umieszczony w innym configu, więc jeśli ktoś w tym widzi jakieś rozwiązanie to też z tego można skorzystać.
Gdzie te całe configi są?
W dwóch miejcach:
C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\cfg – zakładając, że nie używacie MasterComfig,
C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\cfg\user – zakładając, że używacie MasterComfig (w najnowszej wersji, starsze wersje wymagały dziwnych zmian z postfiksem _c.cfg na końcu nazwy pliku oraz zmianę autoexec.cfg na custom.cfg, teraz to już przeszłość.
tl;dr jak ustawić nagrywanie demek?
Wszystkie composzczury compowcy tego muszą używać na meczach czy tego chcą, czy nie. Są dwie opcje jak można nagrywać demka:
P-REC (plugin napisany przez pewnego Ukraińca) – poradnik jest napisany tutaj i nie chcę mi się go przepisywać na polski, bo on jest naprawdę banalnie prosty. Jeśli go używacie to nie możecie wchodzić na gierki competitive wbudowane w grę (z których i tak nikt nie korzysta, więc w sumie żadna strata).
Demo Support, czyli wbudowany w grę mechanizm do nagrywania demek. Powstał po to, by ludzie nie używali P-RECa, ale w rzeczywistości ludzie z Valve nawet to potrafili spierdolić. Z tego aktualnie korzystam.
Oba programy mają swoje wady i zalety. W przypadku P-RECa zaletą jest to, że demka są nagrywane od początku gry do końca, poza tym P-REC sam robi screenshoty statusu (polecenia status, to jest potrzebne na meczach ETF2L). DS nagrywa demka od wejścia na serwer, więc całą naszą rozgrzewkę też nagra (wiadomo, przecież wtedy strzela się najpotężniejsze airshoty to trzeba się jakoś pochwalić, c’nie?). Z drugiej strony w DSie nie trzeba nic instalować – kilka poleceń i działa, poza tym nie psuje gry.
Wszystkie polecenia do DSa:
ds_autodelete "0" //wyłączone automatyczne usuwanie nagranych demek, usuwajmy je ręcznie dzięki czemu na offi nie będzie sytuacji, że zapomnieliśmy nagrać i kapa
ds_dir "suprademos" //wrzuca wszystkie nagrane demka do folderu suprademos, który jest w folderze tf (w moim przypadku "C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf")
ds_enable "3" //0 wyłącza DS, 1 nagrywa gierki z compa wbudowanego w tfa, 2 nagrywa wszystko (casual/community serwery też), 3 nagrywa te prawdziwe mecze comp
ds_kill_delay "10" //w tym przypadku po 10 sekundach od niezabicia fraga killstreak się nie nalicza
ds_log "1" //ta opcja włącza zapisywanie wszystkich bookmarków (automatycznych i ręcznych) do pliku tekstowego
bind F6 "ds_mark" //dzięki temu po wciśnięciu F6 robi się nam bookmark w trakcie gry
ds_min_streak //minimalny killstreak, jaki musimy osiągnąć, by DS sam zrobił nam bookmarka
ds_notify 2 //wyświetla info o poprawnym zrobieniu bookmarka, 0 powoduje wyświetlanie w konsoli, 1 w konsoli i na czacie, 2 w konsoli i na środku ekranu (HUD)
ds_prefix "" //można zostawić puste, to co wpiszemy tutaj będzie na początku każdego pliku demka czy zrzutu ekranu
ds_record //bezużyteczne, po prostu odpala nagrywanie demka
ds_screens 1 //robi screenshota po końcu gry, jeśli wyjdziemy wcześniej z meczu to zapomnijcie o screenie
ds_sound 1 //jak się zaczyna nagrywanie demka to słyszymy dzięki temu dźwięk
ds_status //bezużyteczne, wyświetla w konsoli czy demko nam się nagrywa
ds_stop //bezużyteczne, zatrzymuje nagrywanie demka (robi to samo co polecenie stop)
Tutaj na przykład możemy dać inne killstreaki na inne klasy, np. na medyka dałbym 1, a na snajpera na przykład 3. Wszystko jest kwestią własnego gustu. Najważniejsze jest to, by samemu przetestować czy nagrywanie demek/robienie screenshotów działa.
Udało mi się też wykopać mój stary config do P-RECa:
Ogólnie z tym autousuwaniem demek są dwa rozwiązania: albo mamy włączone automatyczne usuwanie i zawsze robimy bookmark na początku każdego nagrywanego demka (jak w środku meczu nas wywali i wrócimy na serwer to znowu musimy zrobić bookmark, inaczej można dostać bana jak MattJ za nagranie niecałej mapy) albo mamy wyłączone automatyczne usuwanie i usuwamy niepotrzebne demka ręcznie. Sami się zastanówcie co jest lepszym rozwiązaniem dla Was.
Aliasy na przyspieszenie zmian
Prosta sprawa, dodajecie to do autoexec.cfg i efekt jest taki, że żeby zmienić mapkę na zarezerwowanym przez Was serwerze (zakładam, że macie wpisane hasło do rcona w konsoli) wystarczy wpisać nazwę mapy, na przykład granary.
alias "reckoner" "rcon changelevel cp_reckoner_rc2"
alias "badlands" "rcon changelevel cp_badlands"
alias "prolands" "rcon changelevel cp_prolands_b6"
alias "process" "rcon changelevel cp_process_final"
alias "snake" "rcon changelevel cp_snakewater_final1"
alias "gully" "rcon changelevel cp_gullywash_final1"
alias "granary" "rcon changelevel cp_granary_pro_b8"
alias "product" "rcon changelevel koth_product_rcx"
alias "metalworks" "rcon changelevel cp_metalworks"
alias "sunshine" "rcon changelevel cp_sunshine"
alias "bwater" "rcon changelevel pl_badwater"
alias "bwaterpro" "rcon changelevel pl_badwater_pro_v12"
alias "coalplant" "rcon changelevel koth_coalplant_b8"
alias "warmtic" "rcon changelevel koth_warmtic_b6"
alias "upward" "rcon changelevel pl_upward"
alias "lake" "rcon changelevel koth_lakeside_final"
alias "swift" "rcon changelevel pl_swiftwater_final1"
alias "ash" "rcon changelevel koth_ashville_rc1"
alias "barnblitz" "rcon changelevel pl_barnblitz_pro6"
alias "steel" "rcon changelevel cp_steel"
alias "borneo" "rcon changelevel pl_borneo"
Innym fajnym aliasem jest:
alias "tv" "rcon tv_delaymapchange_protect 0"
Często po skończeniu się mapy chcemy od razu zmienić ja na następną, ale domyślnie SourceTV to blokuje, więc mając taki alias w naszym autoexecu wpisujemy w konsoli tv oraz nazwę nowej mapy i jest po temacie.
Zmiany klas (to sobie skopiowałem od thaza) – klikasz odpowiedni przycisk na klawiaturze numerycznej i zmieniasz na klasę, której potrzebujesz + informujesz ludzi na czacie o tym, bardzo przydatne na 6v6:
bind "KP_END" "join_class scout; say_team is scout"
bind "KP_DOWNARROW" "join_class soldier; say_team is soldier"
bind "KP_PGDN" "join_class pyro; say_team is pyro"
bind "KP_LEFTARROW" "join_class demoman; say_team is demoman"
bind "KP_5" "join_class heavyweapons; say_team is vladimir pootis"
bind "KP_RIGHTARROW" "join_class engineer; say_team is engineer"
bind "KP_HOME" "join_class medic; say_team is medic"
bind "KP_UPARROW" "join_class sniper; say_team is sniper"
bind "KP_PGUP" "join_class spy; say_team is spy"
Bindy do serwerów – przydatne jeśli chcę wejść szybko na konkretny serwer, na którym często gram:
alias "mge" "connect melkor.tf:27030"
alias "mge2" "connect melkor.tf:27035"
alias "dm" "connect melkor.tf:27050"
alias "bball" connect supra.tf:27025"
alias "supra" "connect supra.tf; password dupa69"
Jeśli macie jakieś ciekawe bindy czy aliasy to podeślijcie mi je w wiadomościach prywatnych lub w komentarzach – jeśli uznam, że są naprawdę przydatne to dodam je na końcu tego posta.
Nie chodzi mi o przedmioty, lecz o konfigurację. Sporo osób mnie pyta o to z czego korzystam, więc postaram się odpowiedzieć raz na zawsze tym postem na te pytanie.
MasterComfig
Aktualnie (w 2020) najlepsze configi pod kątem optymalizacji gry. Wystarczy wejść tutaj, wybrać odpowiedni preset i dodatkowe modyfikacje. Ja używam presetu Low.
Następnie wybieram takie dodatki:
Potem wystarczy kliknąć Download Low preset and selected addons VPKs (wystarczy kliknąć w przeglądarce zgodę na pobranie wielu plików). Jeśli to nie działa, pobierz po prostu wszystkie pliki po kolei poniżej.
Potem wystarczy te pliki wkleić do folderu C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\custom:
HUD
Korzystam z Hypnotize Huda, który można pobrać tutaj. Jest całkiem ładny, nie ma oczojebnych kolorków i jest czytelny. Po ściągnięciu rozpakowujemy katalog z HUDem i w folderze customizations znajdziemy mnóstwo opcji ustawienia innej opcji HUDa. Na przykład Pause Menu, możemy sobie zobaczyć w Pause Menu Background.png jak wyglądają opcje, a w Pause Menu Background.res można te opcje przestawić.
Ja włączam transparent background, big team status, full stats scoreboard, i quake font. Pliki po zmianie wyglądają tak:
//#base "../resource/ui/HudMatchStatus_SmallHealth.res" // SMALL HEALTH BAR TEAM STATUS
#base "../resource/ui/HudMatchStatus_BigHealth.res" // BIG HEALTH BAR TEAM STATUS
Scoreboards.res
//#base "../resource/ui/Scoreboard_NoStats.res" // SHORT STATS SCOREBOARD
#base "../resource/ui/Scoreboard_FullStats.res" // FULL STATS SCOREBOARD
Poza tym dodaję też tło do numerków z HP i amunicją. W folderze Health & Ammo Box Overrides znajduje się folder resource i scripts. To musimy skopiować i wkleić w głównym katalogu HUDa:
No explosion smoke script
Znalazłem to tutaj. Wystarczy, że wkleicie wszystkie pliki .txt do folderu scripts wewnątrz folderu swojego HUDa (na przykład tego, co przygotowaliście wcześniej). Ułatwiłem szukanie w tym poście, bo wystarczy, że ściągniecie sobie paczkę stąd i jej zawartość rozpakujecie tutaj:
Działanie tych skryptów jest takie, że usuwają fragment splasha (rozprysku) rakiety oraz dym po wybuchu. Poniżej pokażę jak to wygląda:
Bez skryptów
Ze skryptami
Niestandardowy hitsound i killsound
Używałem tego hitsounda i tego killsounda, teraz używam tego hitsounda i killsounda. Hitsound to dźwięk, który słyszymy jeśli trafimy przeciwnika, a killsound to ten, kiedy kogoś zabijemy. By z nich skorzystać, należy w folderze HUDa stworzyć sobie folder sound, następnie w nim ui i w nim umieścić pliki.
Na samym końcu wrzucamy folder hypnotize hud do folderu C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\custom:
Przy pierwszym uruchomieniu dodajcie -dxlevel 81 – to zmieni wersję używanego DirectXa na 8.1. Po tym pierwszym uruchomieniu usuńcie ten parametr z listy. Korzystam z -dxlevel 81, bo dzięki temu nie występuje bug z nakładką Mumble, w którym cała nakładka jest biała.
Ustawienia znajdziemy tutaj:
I na dole Ustaw opcje uruchamiania…
Ostatnia i najważniejsza rzecz – configi!
Tutaj chyba się trochę rozpiszę. Pozostawiłem komentarze w blokach, poniżej fragment pliku autoexec.cfg:
cl_interp_ratio "1"
fps_max 0 //powinno się ustawiać 2x częstotliwość odświeżania ekranu + 1, więc mam 2x144+1=289, ale w moim przypadku lepiej było wyłączyć lock, warto potestować
tf_use_match_hud "1"
unbind numlock
bind "KP_END" "join_class scout; say_team is scout" //zmienia klasę na skauta i pisze na czacie teamowym "is scout" klasy są od skauta do spy na przyciskach na przyciskach numerycznych od 1 do 9
bind "KP_DOWNARROW" "join_class soldier; say_team is soldier"
bind "KP_PGDN" "join_class pyro; say_team is pyro"
bind "KP_LEFTARROW" "join_class demoman; say_team is demoman"
bind "KP_5" "join_class heavyweapons; say_team is vladimir pootis"
bind "KP_RIGHTARROW" "join_class engineer; say_team is engineer"
bind "KP_HOME" "join_class medic; say_team is medic"
bind "KP_UPARROW" "join_class sniper; say_team is sniper"
bind "KP_PGUP" "join_class spy; say_team is spy"
bind KP_ENTER "taunt_by_name Shred Alert; say gj bruh"
bind KP_MULTIPLY "taunt_by_name Taunt: The Schadenfreude; say ha ha h a h a"
alias "mge" "connect melkor.tf:27030" //wpisujesz mge w konsoli i jesteś na melkor #1 MGE
alias "mge2" "connect melkor.tf:27035" //wpisujesz mge w konsoli i jesteś na melkor #2 MGE
alias "dm" "connect melkor.tf:27050" //wpisujesz mge w konsoli i jesteś na melkor DM
alias "tutajpomarancza" "connect supra.tf:27020; password supersecretpassword"
snd_mute_losefocus "1" //jak zminimalizujesz grę to nie ma dźwięku
cl_hud_playerclass_use_playermodel "1" //włącza sylwetkę gracza w 3d w miniaturce postaci, dzięki temu można na 6v6 sprawdzać jakie klasy ma przeciwnik na spaju
cl_use_tournament_specgui "1" //dzięki temu jak oglądasz comp gierkę ze spectów to widzisz po lewej i prawej stronie punkty życia graczy
sv_lan "0"
closecaption "1" //dzięki temu są teksty w stylu scout bleeding po prawej stronie ekranu
crosshair "1"
voice_enable "1" //włącza czat głosowy
bind "h" "+use_action_slot_item"
bind F11 explode //killbind
r_drawdecals "0" //wyłącza spraye
hud_combattext "1" //włącza info o zadawanym dmg
hud_combattext_healing "1" //włącza info o leczeniu
tf_dingalingaling "1"
tf_dingaling_volume "1.000000"
tf_dingaling_pitchmindmg "128.529999"
tf_dingaling_pitchmaxdmg "20.110001"
tf_dingalingaling_lasthit "1"
tf_dingalingaling_last_effect "0"
tf_dingaling_lasthit_volume "1.000000"
tf_dingaling_lasthit_pitchmindmg "100.000000"
tf_dingaling_lasthit_pitchmaxdmg "100.000000"
tf_dingalingaling_repeat_delay "0.008"
cl_crosshair_red "0.000000"
cl_crosshair_green "255.000000"
cl_crosshair_blue "0.000000"
cl_crosshair_file "crosshair3"
cl_crosshair_scale "48.000000" //dzięki tych linijkom z cl_crosshair zawsze mam ten sam hud, czyli duże, zielone kółko
tf_remember_activeweapon "0"
tf_remember_lastswitched "0"
m_rawinput "1" //bezpośredni odczyt z myszki, dzięki temu unikamy efektu akceleracji myszki
cl_playerspraydisable 1
r_spray_lifetime 0
alias shit "say 0 ...; bind F10 shit2" //śmieszny bind
alias shit2 say "|\_ .` `.; bind F10 shit3"
alias shit3 say "/\ open; bind F10 shit"
bind "F10" "shit"
bind "F12" "say www.wikihow.com/Deal-With-Your-Teenage-Anger try using it"
alias "tv" "rcon tv_delaymapchange_protect 0" //wpisujesz w konsoli tv i od razu możesz zmienić mapkę
alias "change" "bind space +jump"
alias "mixvote" "rcon sm_votemap" "cp_prolands_b6" "koth_product_rcx" "cp_snakewater_final1" "cp_gullywash_f2a" "cp_sunshine"
alias "reckoner" "rcon changelevel cp_reckoner_rc6"
alias "badlands" "rcon changelevel cp_badlands"
alias "prolands" "rcon changelevel cp_prolands_b6"
alias "process" "rcon changelevel cp_process_f7"
alias "snake" "rcon changelevel cp_snakewater_final1"
alias "gully" "rcon changelevel cp_gullywash_f2a"
alias "granary" "rcon changelevel cp_granary_pro_b8"
alias "product" "rcon changelevel koth_product_rcx"
alias "metalworks" "rcon changelevel cp_metalworks"
alias "sunshine" "rcon changelevel cp_sunshine"
alias "bwater" "rcon changelevel pl_badwater"
alias "prowater" "rcon changelevel pl_prowater_b12"
alias "coalplant" "rcon changelevel koth_coalplant_b8"
alias "warmtic" "rcon changelevel koth_warmtic_b6"
alias "upward" "rcon changelevel pl_upward"
alias "lake" "rcon changelevel koth_lakeside_final"
alias "swift" "rcon changelevel pl_swiftwater_final1"
alias "ash" "rcon changelevel koth_ashville_rc1"
alias "barnblitz" "rcon changelevel pl_barnblitz_pro6"
alias "steel" "rcon changelevel cp_steel"
alias "borneo" "rcon changelevel pl_borneo"
//p-rec support
//prec_mode 3
//prec_dir demos
//prec_notify 2
//prec_screens 1
//prec_delete_useless_demo 1
//prec_tag demkasupry
//bind F6 prec_mark
//built-in demo support
ds_enable 3
ds_min_streak 25
ds_kill_delay 5
ds_notify 2
ds_prefix "supra_demo_"
ds_screens 1
ds_sound 1
ds_autodelete 1
ds_dir "suprademos"
ds_log 1
rcon_address supra.tf:27015
rcon_password hahahahaha
Poniżej są zmienne, które i tak ustawiają jakość obrazu na niską i mam to dlatego, bo jestem leniwy i się przyzwyczaiłem to tych kiepsko wyglądających tekstur 😉
Configi można pobrać tutaj. Wystarczy wkleić zawartość tego zipa do folderu C:\Program Files (x86)\Steam\steamapps\common\Team Fortress 2\tf\cfg i to tyle. Będzie działać. W przypadku używania MasterComfiga należy przechowywać configi klas oraz autoexec.cfg w folderze user będącym w cfg. Jeśli nie macie MasterComfiga, po prostu wrzućcie configi z user do folderu cfg i będzie działało.
autoexec.cfg jest ładowany w momencie uruchomienia gry. Pliki klas takie jak np. scout.cfg są ładowane w momencie wybrania takiej klasy. Na każdej klasie oprócz inżyniera możemy sobie zmieniać loadouty dla danej klasy: F1 – daje set A, F2 – set B, F3 – set C, F5 – set D. Nie używam F4 w configu, bo używa się go do kliknięcia Ready up w przypadku serwerów competitive/MVM.
W przypadku inżyniera te przyciski dają: F1 – działko, F2, dispenser, F3 – teleport (wejście), F5 – teleport (wyjście).
Medyk też jest na swój sposób wyjątkowy, bo u mnie loadouty są przygotowane pod konkretne mediguny: F1 – medigun, F2 – kritzkrieg, F3 – quickfix, F5 – vaccinator. Configi, które są w katalogu wyżej od user są do załadowania ustawień. Na przykład w przypadku Vaccinatora nie używam informacji na czacie, że użyłem, bo spamowałbym tym non-stop w trakcie normalnej gry.
Na soldzie i skaucie na prawym przycisku myszy mam zmianę broni. Pewnie kiedyś tam ustawię na soldzie skok, bo to jest lepsze rozwiązanie, ale póki co jestem leniwy.
Poza tym, jak możecie zauważyć na niektórych klasach jest włączony model broni na niektórych broniach, a na niektórych nie. Włącza/wyłącza się model przyciskiem danej broni, czyli np. na soldzie wciśnięcie 1 da nam zmianę na wyrzutnię rakiet + wyłączy nam model broni. W niektórych klasach działa to dosyć specyficznie, ponieważ na pyro i medyku mam wyłączony model mediguna, ale mam wyłączony strumień by widzieć czy kogoś leczę lub palę na pyro. Ten strumień pozwala mi łatwiej określić, czy ktoś jest w moim zasięgu (przynajmniej ja mam takie wrażenie).
Ponadto, w tym configu jest włączone automatyczne nagrywanie demek z competitive z usuwaniem demek bez bookmarków i demka są zapisywane do folderu suprademos (w folderze tf). Na F6 jest przypisany bind do robienia bookmarków.
Ktoś się mnie też pytał o zmienną, która powoduje, że grając medykiem nad każdym wyświetla się chmurka, dzięki czemu można tak jakby widzieć swoich kumpli z teamu za ścianami i robić prefire z kuszy, by kogoś szybko podleczyć. Ta zmienna to hud_medicautocallersthreshold "150".
Fajne skrypty specyficzne dla klas
Winger jump: powoduje, że skaczemy wyżej wykorzystując właściwość Wingera na moment. Naciskasz przycisk i postać sama zmienia broń i podskakuje. Skrypt wygląda tak (ja mam ten jump przypisany pod mouse5).
alias +wjump "slot2; +jump; +duck"
alias -wjump "lastinv; -jump; -duck"
bind "mouse5" "+wjump"
Bez winger jumpa
Z winger jumpem
Detonator jump:
To jest skrypt, który pozwala pod jednym przyciskiem robić jumpa na racy z detonatora. Naciskasz przycisk i za Ciebie robi cały jump, jedynie musisz odpowiednio kierować celownikiem, by lecieć tam, gdzie chcesz.
alias +detonatorjump "+jump;+duck;+attack;+attack2"
alias -detonatorjump "-jump;-duck;-attack;-attack2"
bind "mouse5" "+detonatorjump"
Nakładka (overlay) Mumble
Dzięki temu widzę, kto do mnie mówi na czacie głosowym lepiej. Ten domyślny jest w górnym, prawym rogu i wygląda kiepsko. Tło zasłania grę. Dlatego ja mam własną ścieżkę, własne kolory i ustawienie. Ustawiam nakładkę po prawej stronie na środku i działa ona tak, że mówiące osoby wyświetlają się tekstem na czerwono, jeśli przestaną mówić to mają taki szarawy kolor i po kilku sekundach od ciszy znikają z overlaya. W ten sposób też nie wyświetla mi zawsze wszystkich osób na kanale. Do tego mam przygotowany gotowy layout i konkretną czcionkę, którą używam.
Po prawej widać ten overlay.
By wgrać ten overlay, po pobraniu najlepiej wcześniej zainstalować sobie taką czcionkę, jaką jak mam i należy otworzyć ustawienia Mumble i w zakładce Nakładka (Overlay) kliknąć Wczytaj… w sekcji Opcje. Następnie za pomocą kropek trzeba ustawić w odpowiednim miejscu nakładkę. Aktualnie jej ustawienie wyrównuje nazwy użytkowników do lewej strony i to można sobie zawsze zmienić.
Następnie, jeśli chcemy zmienić czcionkę, robimy to tak, jak na animacji poniżej. Po tym można zapisać ustawienia.
Wyłączenie nakładki Steam w grze i przeglądarki w Steamie
Ten numer mi sprzedał wonszu i szczerze powiedziawszy to nawet z moim sprzętem zmiana jest zauważalna na plus. Po pierwsze, trzeba wyłączyć nakładkę Steam podczas gry (klikając prawym na grę -> Właściwości…:
Następnie należy sobie utworzyć skrót do Steama na pulpicie wchodząc do folderu ze skrótami (oczywiście to nie jest jedyne rozwiązanie, ale moim zdaniem jest najprostsze):
Otworzy nam się okno, stąd kopiujemy skrót na Pulpit:
Następnie klikamy na niego PPM -> Właściwości i w sekcji Element docelowy dodajemy parametry -console -no-browser. Zakładając, że macie zainstalowanego Steama w domyślnej lokalizacji to powinno wyglądać tak: "C:\Program Files (x86)\Steam\Steam.exe" -console -no-browser
Ten post nie będzie do końca taki, jak wcześniej, bo niestety nie mam tyle czasu, by opisać całą instalację iRedMaila i tego, co robiłem. Ogólnie udało mi się zmigrować u klienta serwer pocztowy. Klient miał Debiana 6, trochę stary, użytkownicy lokalni, a nie w SQLu czy LDAPie (OpenLDAP lub AD) i trzeba było coś z tym zrobić. Był to jakiś pakiet, który bazował na Postfixie/Dovecot z interfejsem webowym Squirrel. Trzeba było coś z tym zrobić, więc ostatecznie zdecydowaliśmy się na migrację serwera na nowy, z Debianem 10 i celem był iRedMail – prosty pakiet z Postfixem i Dovecotem z podstawowym panelem administracyjnym. Wdrożyłem go z LDAPem z prostego powodu: jest szansa na to, że w przyszłości taki użytkownik będzie mógł wykorzystać logowanie z Active Directory jeśli przepnie się query z LDAPa do AD oraz każdemu użytkownikowi w AD doda się odpowiedni atrybuty, z których korzysta iRedMail.
Dlatego też jeśli chcecie się nauczyć stawiać iRedMaila – polecam sobie poczytać ich dokumentację. Jest tam naprawdę sporo ciekawych materiałów. Pomimo to są rzeczy, które nawet jeśli są w tej dokumentacji przykuły moją uwagę.
Migracja użytkowników do OpenLDAPa
Użytkownicy byli przechowywani lokalnie, więc mogłem znaleźć ich nazwy użytkowników, nazwy wyświetlane (Gecos) itd w pliku /etc/passwd. Ogólnie ten plik wygląda tak:
Tutaj znalazłem informację jak tworzyć użytkowników w LDAPie z odpowiednimi atrybutami. Z tego pliku wyciągnęliśmy listę wszystkich użytkowników oraz Gecos. Wystarczy do tego Excel lub inny program pracujący z arkuszami kalkulacyjnymi, który jest w stanie zczytywać dane z plików, które mają oddzielone wartości za pomocą jakiegoś znaku (np. CSV). Na początku klikamy Z pliku tekstowego/CSV, następnie wskazujemy plik i wybieramy ogranicznik (znak oddzielający wartości, ang. delimiter), powinien być nim dwukropek.
Korzystam z Excel 2019 i on sam wykrył ten znak (musiałem jedynie zmienić kodowanie pliku na UTF-8), zmieniłem też pole Wykrywanie typu danych na Nie wykrywaj typów danych:
Jak widać, wszystko ładnie się zaimportowało:
Następnie należy trochę przerobić te dane. Składnia to:
mydomain.com, user2, plain_password, Michael Jordan, group1:group2,
W praktyce to powinno wyglądać tak:
Jak widać w stosunku do zrzutu ekranu wyżej, usunąłem przecinki po w nazwie wyświetlanej oraz poprzenosiłem wartości w kolejności. Kolumna F jest pusta, bo nie mam zdefiniowanych żadnych grup. W takiej sytuacji trzeba na końcu każdej linii po wyeksportowaniu pliku CSV dopisać spację i przecinek. Dodałem też te liczby i 5368709120 to jest quota (przydział rozmiaru skrzynki) w bajtach. 5368709120 daje nam 5 GB.
Zapisujemy plik w postaci CSV UTF-8 (w ogóle to jest dostępne tylko w Excel 2019, nie wiedzieć czemu):
Otrzymujemy to (otwieram takie pliki w Visual Studio Code):
Podmieńmy sobie najpierw średniki ; na przecinki ze spacją , :
Teraz musimy jakoś dodać te puste pola grup. Z faktu, że przypisałem wszystkim użytkownikom taką samą wielkość skrzynki, wykorzystam to, by dodać dodatkową wartość:
W ten sposób możemy wykorzystać taki plik CSV do zaimportowania użytkowników. Jak widać, nie przenoszę tutaj haseł tylko generuję nowe. Skorzystałem z random.org do wygenerowania hasełek, które wkleiłem do arkusza:
iRedMail dostarcza skrypty, które przygotowują za nas plik LDIF, który potem musimy wykorzystać do dodania użytkowników za pomocą polecenia ldapadd. Powinny być w folderze instalacyjnym iRedMaila, w folderze tools. Są dwa skrypty: create_mail_user_OpenLDAP.py i create_mail_user_OpenLDAP.sh. Ja skorzystałem z tego pierwszego, bo we wdrożeniu chciałem mieć katalogi użytkowników w konkretnym katalogu, a ten bashowy skrypt chyba na to nie pozwalał.
LDAP_URI – adres serwera LDAP, do którego się łączymy (jest on na serwerze localnie),
BASEDN – DN domeny, każdy element oddziela się przecinkiem w miejscu, gdzie jest kropka w nazwie, np. super.domena.com dzieli się na dc=super,dc=domena,dc=com, dopisujemy na początku o=domains wyjątkowo w tym polu,
BINDDN – użytkownik, na prawach którego wykonujemy operację, przy czym Manager jest kontem, które ma pełne prawa do modyfikowania wszystkiego, co jest w LDAPie, w dużym uproszczeniu to jest nazwa użytkownika + nazwa domeny, którą przedstawiałem wyżej, w tym polu trzeba poprawić domenę
BINDPW – hasło do konta Manager, znajdziemy je w katalogu instalacyjnym w pliku iRedMail.tips,
STORAGE_BASE_DIRECTORY – katalog bazowy, w którym znajdują się wszystkie skrzynki, ścieżka do katalogu użytkownika to STORAGE_BASE_DIRECTORY/<domena>/<folder-użytkownika>
APPEND_TIMESTAMP_IN_MAILDIR – jeśli true, foldery użytkownika wyglądają tak: supra-2020.04.22.17.19.56
HASHED_MAILDIR – tutaj ładnie jest opisane w skrypcie, w praktyce jak mamy włączony hash z ścieżką katalogu bazowego jak w skrypcie oraz dopisanie daty do nazwy folderu użytkownika to pełna ścieżka do skrzynki mailowej przykładowego użytkownika supra wygląda tak: /var/vmail/vmail1/domain.com/s/u/p/supra-2020.04.22.17.19.56
Jak mamy to, możemy sobie wrzucić plik CSV na serwer i go po prostu zaimportować. Warto sobie sprawdzić czy nazwy wyświetlane dobrze nam się czytają, by nie mieć żadnych znaków z niespodzianką (np. moje imię ma znak, który jest polski):
Traceback (most recent call last):
File "create_mail_user_OpenLDAP.py", line 303, in <module>
ldif_writer.unparse(dn, data)
File "/usr/lib/python2.7/dist-packages/ldif.py", line 194, in unparse
dn = dn.encode('utf-8')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position 11: ordinal not in range(128)
Żeby rozwiązać to, należy wykorzystać program dos2unix, by przekonwertować plik:
$ dos2unix import.csv
dos2unix: konwersja pliku import.csv do formatu uniksowego...
Ewentualnie to można zrobić w Vimie poleceniem :set nobomb i zapisując plik. Teraz wynik dostaję taki:
< INFO > User data are stored in /home/supra/import.csv.ldif, you can verify it before importing it.
< INFO > You can import it with below command:
ldapadd -x -D cn=Manager,dc=example,dc=com -W -f /home/supra/import.csv.ldif
Taki plik możemy zaimportować do iRedMaila za pomocą polecenia (parametr -w pozwala na podanie hasła w parametrze, -W powoduje, że wpisywane hasło nie jest widziane na ekranie):
adding new entry "mail=mmarecki@etf2l.site,ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
adding new entry "mail=dwarynska@etf2l.site,ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
adding new entry "mail=adarecka@etf2l.site,ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
adding new entry "mail=tf2serv@etf2l.site,ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
adding new entry "mail=bots@etf2l.site,ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
Możemy spotkać się z takim błędem:
adding new entry "mail=supra@etf2l.site,ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
ldap_add: Already exists (68)
To po prostu oznacza, że dany użytkownik istnieje i jeśli wcześniej mieliśmy jakieś linijki o powodzeniu dodania użytkownika, to musimy usunąć wszystko wyżej wraz z użytkownikiem, który istnieje tak, że pierwszą linią będzie pierwsze pole następnego użytkownika. Każdy wpis jest oddzielony pustą linią i powinniśmy zachować takie odstępy, lecz na początku tego nie trzeba mieć.
Wyszukiwanie użytkowników w LDAPie w konsoli i w GUI
W konsoli jest to proste, wystarczy polecenie ldapsearch:
-D – konto, które ma prawa do wykonania tego typu zapytań w postaci DN
-w – hasło do tego konta
-s – nasze zapytanie
Zapytanie wyżej wyświetla daje w wyniku konta, które mają dowolną wartość wpisaną w atrybucie mailMessageStore (ścieżka do skrzynki pocztowej użytkownika) oraz wartość postmaster wpisaną w atrybucie cn (common name, z reguły jest unikalne). Poniżej zapytanie, które pyta tylko o konta z cn o wartości postmaster:
Jeśli chodzi o GUI to tutaj trzeba trochę pokombinować. Widziałem komentarze na forach odradzające korzystania z phpLDAPadmin, więc skorzystałem z LAM (LDAP Account Manager).
Na początku ściągamy pakiet na naszą dystrybucję, w moim przypadku nie było w repozytorium, więc ściągnąłem sobie plik .deb z sieci i go zainstalowałem:
W ten sposób LAM będzie zainstalowany. Następnie musimy go wystawić poprzez stronę i to ułatwia LAM samo w sobie, bo w /etc/ldap-account-manager/nginx.conf znajdziemy szablon lokalizacji, który możemy dodać do strony:
Trzeba tutaj poprawić linijkę, którą zaznaczyłem, bo pewnie nie używacie już takiej wersji PHP (OBY!). W domyślnej konfiguracji PHP aktualnej wersji pracuje pod adresem 127.0.0.1:9999, więc ta linijka powinna mieć fastcgi_pass 127.0.0.1:9999;. Ponadto dodałbym w tej lokalizacji takie dwie linijki, by ograniczyć dostęp do tej przeglądarki tylko z sieci, w której mamy możliwość administrowania wszystkim (w przykładzie będzie 192.168.10.0/24). Na lenia wrzuciłem konfigurację do /etc/nginx/sites-available/00-default-ssl.conf i dzięki temu dostanę się do strony wpisując w przeglądarce adres https://mail.domain.com/lam:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name mail.domain.com;
location /lam {
allow 192.168.10.0/24;
deny all;
index index.html;
alias /usr/share/ldap-account-manager;
autoindex off;
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass 127.0.0.1:9999;
fastcgi_param SCRIPT_FILENAME $request_filename;
}
location ~ /lam/(tmp/internal|sess|config|lib|help|locale) {
deny all;
return 403;
}
}
root /var/www/html;
index index.php index.html;
include /etc/nginx/templates/misc.tmpl;
include /etc/nginx/templates/ssl.tmpl;
include /etc/nginx/templates/iredadmin.tmpl;
include /etc/nginx/templates/roundcube.tmpl;
include /etc/nginx/templates/sogo.tmpl;
include /etc/nginx/templates/netdata.tmpl;
include /etc/nginx/templates/php-catchall.tmpl;
include /etc/nginx/templates/stub_status.tmpl;
}
Po otwarciu strony musimy nieco zmienić konfigurację pod kątem logowania:
Następnie wybieramy Edytuj profile serwerowe:
W tym polu wpisujemy hasło lam i warto je zmienić:
W Ustawieniach głównych, sekcji Server settings ustawiamy odpowiedni DN domeny, do której się łączymy, przy okazji można zmienić język i strefę czasową:
Dodatkowo w Ustawieniach bezpieczeństwa definiujemy w polu Lista uprawnionych użytkowników definiujemy DN konta Manager:
Na końcu hasło do profilu warto sobie zmienić po to, by nikt nam tego profilu nie zmieniał:
Następnie możemy się zalogować wklejając hasło do konta Manager:
Ponadto warto sobie przejść do karty Typy kont i zmienić ustawienia Aktywuj rodzaje kont. Na tym etapie dałem sobie spokój z ukrywaniem mojej domeny, bo i tak do strony dostęp jest zablokowany:
Po zmianach zapisujemy i logujemy się do konta Manager:
W ten sposób otrzymujemy ładną przeglądarkę kont:
Może nie tak ładną, wszystko przez pole enabledservice.
Tak czy siak mi lepiej się tego interfejsu używa poprzez Widok drzewa, który można znaleźć u góry, po prawej. W aktualnym interfejsie jest lepiej wyszukać coś, ale w tym drzewku łatwiej modyfikować i dodawać.
Dodajemy atrybuty poprzez pole Dodaj nowy atrybut po prawej stronie, następnie wybieramy z listy atrybut, który nas interesuje:
Potem jedynie wpisujemy, co chcemy i zapisujemy (przycisk jest na samym dole, Zaktualizuj obiekt). Tutaj przykład jeśli chcielibyśmy dodać użytkownikowi grupę po to, by po wysłaniu maila przez jakiegoś użytkownika na newsletter@etf2l.site otrzymywał wiadomości (inaczej mówiąc dodajemy użytkownika do wewnętrznej listy mailingowej):
Dodawanie aliasów
Na starym serwerze aliasy były przechowywane w pliku /etc/aliases, którego format był następujący:
suprovsky: supra
a.darecka: adarecka
ad: adarecka
admin: supra, adarecka
Po lewej znajduje się alias, po dwukropku znajduje się lista użytkowników, którzy mają otrzymywać wiadomości po odebraniu przez serwer wiadomości na alias, czyli np. wysyłka maila na admin@etf2l.site powoduje wysłanie maili do supra@etf2l.site oraz adarecka@etf2l.site.
W przypadku iRedMaila z OpenLDAP są dwie opcje, by to sobie dodać taki alias: przez LAM i przez polecenie ldapmodify z przygotowanym plikiem LDIF. W przypadku LAMa wystarczy, że dodamy nowy atrybut o nazwie shadowaddress i podamy po prostu pełny adres aliasu, czyli np. dla konta supra wartości atrybutu to suprovsky@etf2l.site oraz admin@etf2l.site.
Postać LDIF dla supra i adarecka wyglądałby następująco (trzeba pamiętać o dodaniu pustej linii pomiędzy wpisami):
To akurat jest dosyć upierdliwe, bo jeśli chcemy dodać 1 grupę 500 użytkownikom to póki co nie znalazłem na to jakiejś magicznej sztuczki.
Ogólnie grupę tworzy się takim LDIFem (można go znaleźć tutaj):
dn: mail=all@etf2l.site,ou=Groups,domainName=mydomain.com,o=domains,dc=etf2l,dc=site
accountStatus: active
cn: demolist
enabledService: mail
enabledService: deliver
enabledService: displayedInGlobalAddressBook
mail: all@etf2l.site
objectClass: mailList
accesspolicy: domain
W tym LDIFie warto zwrócić uwagę na accesspolicy i poczytać w linku, który podałem wyżej. Wartość domain powoduje, że można na taką grupę wysyłać maile tylko z tej samej domeny. Dodajemy go tak:
Potem musimy do każdego obiektu, który ma należeć do wybranej grupy mailingowej (w tym przypadku all@etf2l.site) dodać atrybut z adresem mailowym takiej listy. Tutaj LDIF wygląda tak:
To też sobie zapisałem, bo przydało mi się. ldapmodify można też używać w trybie interaktywnym, gdy się nie poda w argumencie -f pliku LDIF. Wtedy dane z w takim formacie podaje się wpisując je ręcznie i oddzielając enterami. Po wpisaniu całego wpisu należy zrobić linijkę przerwy i wykonać skrót Ctrl+D. To spowoduje wyjście z trybu interaktywnego i wykonanie zapytania do LDAPa. Przykład:
W ten sposób z poprzednio ustawionego pola memberOfGroup na all@etf2l.site użytkownik supra będzie miał ustawioną grupę newsletter@etf2l.site.
Usunięcie domeny z pola logowania dla iRedMail (konkretnie SOGo)
Jest to tutaj opisane, ale nie dla SOGo. Do tego się odniosę. Trzeba edytować 1 plik, mianowicie /etc/sogo/sogo.conf, lecz przed tym trzeba sobie umożliwić jego modyfikację:
sudo chmod o+w /etc/sogo/sogo.conf
W pliku modyfikuję takie pola (podaję wartości, które ustawiam, nie wszystko dotyczy samego usunięcia z domeny, bo część to po prostu dobre praktyki):
SOGoLanguage = Polish;
SOGoForceExternalLoginWithEmail = NO;
SOGoTimeZone = "Europe/Warsaw";
SOGoUserSources = (
///zmieniamy tylko te pola///
bindDN = "cn=vmail,dc=etf2l,dc=site"; //usunąłem 'o=domains,' stąd
bindFields = (uid); //domyślna wartość to mail
)
Po zmianach restartujemy usługę poleceniem systemctl restart sogo i sprawa załatwiona.
Autokonfiguracja klientów pocztowych
Zbawienie dla administratorów. Wpisujesz nazwę użytkownika, maila i hasło. To wszystko. Brzmi zbyt pięknie, by było prawdziwe? Niekoniecznie musi! Są 2 gotowe formatki, które można wykorzystać i one są dla Microsoft Outlook oraz Mozilla Thunderbird. Sytuacja jest prosta: należy ustawić odpowiednie wpisy w DNSie i wystawić pliki na serwerze WWW.
Tutaj można zauważyć 2 wpisy CNAME autoconfig i autodiscover kierujące połączenia na domenę mail.etf2l.site, która jest innym CNAME, który kieruje na etf2l.site, a ten już kieruje na odpowiedni adres IP (to jest wpis A). To będzie nam potrzebne. Te dwa CNAME mają po prostu wskazywać serwer, na którym są formatki, które ma pobierać klient pocztowy. W dodatku nie musi być to bezpośrednio nasz serwer mailowy, ale zrobiłem tak, bo tak po prostu mi było łatwiej. Ponadto powinniśmy mieć wpis SRV _autodiscover._tcp, który kieruje na adres serwera, na którym jest taka formatka. W wartości powinniśmy wpisać 0 1 443 mail.etf2l.site, przy czym zmieniamy adres naszego serwera formatki na właściwy.
Wyjaśnimy sobie po co są te domeny. Domena autodiscover.etf2l.site (konkretnie adres https://autodiscover.etf2l.site/autodiscover/autodiscover.xml jest wykorzystywna przez Outlooka do wykrycia konfiguracji poczty. W sumie to nie musimy mieć nawet do tego subdomeny, bo na dobrą sprawę moglibyśmy wystawiać to na domenie etf2l.site bezpośrednio – to jest kwestia czysto seperacji konfiguracji. Strona autoconfig.etf2l.site jest zaś dla Thunderbirda – on łączy się na adres https://autoconfig.etf2l.site/mail/config-v1.1.xml i z niego zaciąga sobie konfigurację. Tutaj subdomena akurat jest potrzebna.
Outlook widząc domenę etf2l.site sprawdza wpis SRV, o którym wspomniałem by sprawdzić pod jakim adresem jest plik konfiguracyjny, następnie wysyła na adres wspomniany wyżej w POST taką zawartość:
Jak można zauważyć, w polu EMailAddress jest adres użytkownika, który próbuje sobie skongurować Outlooka. Dla Outlooka nie wystawiamy autodiscover.xml w postaci gołego XMLa – możemy do tego wykorzystać skrypt w PHP, który wpisuje nam adres mailowy użytkownika w XML, a następnie nam go zwraca (musimy ten XML edytować podając prawidłowe dane do naszego serwera pocztowego):
Warto wziąć pod uwagę, że jako SMTP określiłem połączenie SSL/TLS na porcie 465 – w większości użytkownicy będą woleli korzystać ze STARTTLS na porcie 587. Korzystałem z 465 w ramach testu, bo UPC nie blokuje tego portu 😂
W praktyce ze STARTTLSem na 587 powinniśmy podmienić w ten sposób sekcję Protocol:
W naszym przykładzie będziemy przechowywać te formatki w katalogu /var/www/autodiscover (może być to dowolna inna lokalizacja, po prostu przyjęło się, że w /var/www z reguły są pliki wystawiane przez serwer HTTP). Ten plik będzie nazwany jako autodiscover.php. Do tego config, który jest potrzebny dla nginxa, by wystawiał dostęp dla tej domeny i do tego pliku (umieściłem go w /etc/nginx/sites-available/autodiscover.etf2l.site:
server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
server_name autodiscover.etf2l.site;
root /var/www/autodiscover;
index index.php;
include /etc/nginx/templates/ssl.tmpl;
error_log /var/log/nginx/autodiscover-error.log;
access_log /var/log/nginx/autodiscover-access.log combined;
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
location ~ /(?:a|A)utodiscover/(?:a|A)utodiscover.xml {
root /var/www/;
try_files /autodiscover/autodiscover.php =404;
fastcgi_pass 127.0.0.1:9999; #w tym miejscu jest prawidłowa wartość dla serwera z iredmailem
fastcgi_index index.php;
include fastcgi.conf;
fastcgi_param SERVER_ADDR "";
fastcgi_param REMOTE_ADDR $http_x_real_ip;
}
}
Następnie należy dodać sobie symlink takiego configa do /etc/nginx/sites-enabled, by był wykorzystywany przez nginxa i warto też wykonać test konfiguracji, by sprawdzić, czy nie wkradł nam się do configa jakiś błąd przed restartem usługi. Jeśli taki będzie i zrestartujemy usługę, ta się nie uruchomi po zatrzymianiu i to może dla nas być problem. Test wykonuje się poleceniem nginx -t. Taki jest poprawny wynik testu:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Koniec końców linkuję konfig, wykonuję test i restartuję usługę tak:
cd /etc/nginx/sites-enabled
ln -s ../sites-available/autodiscover.etf2l.site
nginx -t
systemctl restart nginx
Następnie możemy sobie przetestować, czy taka formatka nam działa wykonując ręczny test za pomocą cURLa. Musimy zapisać sobie wspomniany na początku request do pliku. Nazwijmy go req.xml, następnie wykonujemy następujące polecenie:
curl -X POST file:/home/supra/req.xml https://autodiscover.etf2l.site/autodiscover/autodiscover.xml
To oznacza, że wszystko się zgadza. Z poziomu Outlooka wygląda to tak:
W przypadku Thunderbirda jest podobnie, lecz nie trzeba robić sztuczek z PHPem – wystarczy w odpowiedni sposób przygotować plik XML (umieszczając go w /var/www/autodiscover) oraz umieścić do niego pasujący plik konfiguracyjny do nginxa (oczywiście na Apache’u też to można zrobić, ale dla mnie Apache śmierdzi i nie będę go używał):
W tym XMLu kolejność protokołów ma znaczenie, wiec jeśli chcemy w pierwszej kolejności używać portu 587 zamiast 465 to musimy zamienić sekcje outgoingServer miejscami. Następnie config do nginxa wygląda tak:
Po zrobieniu symlinka do tego configa w /etc/nginx/sites-enabled, zrobieniu testu i zrestartowaniu nginxa możemy zobaczyć jak nasz Thunderbird się sam konfiguruje:
Jest też opcja, by móc automatycznie konfigurować sprzęt Apple’a, ale jestem zbyt leniwy, by to przetestować. Jest to opisane tutaj.
Zabezpieczenie się przed niepowołanym dostępem do administracji
Jest kilka rzeczy, które powinno się zrobić z mojego punktu widzenia, by zminimalizować ryzyko, że ktoś niepowołany wejdzie na jakąś stronę. Po pierwsze, należy obciąć dostęp do LDAP Account Managera/phpLDAPadmin (jeśli zainstalowany) w nginxie, następnie to należy powtórzyć dla lokalizacji w plikach:
Po zmianach wiadomo, restarcik nginxa się przyda: systemctl restart nginx.
Poza tym powinno się nasłuchiwać połączenia serwera SSH tylko i wyłącznie z podsieci administracyjnej, powinno się wyłączyć logowanie na roota po SSH oraz wyłączyć logowanie za pomocą haseł i przerzucić się na klucze publiczne zmieniając plik /etc/ssh/sshd_config (zamieszczam tylko istotny fragment):
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
PermitRootLogin no
PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no
Dostęp z innych podsieci możemy załatwić za pomocą iptables:
Warto też się upewnić, że domyślna polityka INPUT dla iptables to DROP (to oznacza, że dla każdego ruchu niezdefiniowanego w regułach iptables w sekcji INPUT jest wykonywany DROP, czyli brak odpowiedzi):
sudo iptables -L -v
[sudo] password for supra:
Chain INPUT (policy DROP 1803K packets, 167M bytes)
Do iptables warto mieć opcję zapisywania konfiguracji i można znaleźć o tym fajny poradnik tutaj.
Niektóre strony nie mają wbudowanego trybu ciemnego (aka dark mode) i przez mój światłowstręt cierpię o 2 w nocy. Z pomocą przychodzi plugin Stylish, który można wykorzystywać w przeglądarkach Google Chrome (i wszystkich innych bazujących na Chromium) i Mozilla Firefox. Dzięki temu strona zamiast wyglądać tak:
Google Chrome (i inne przeglądarki oparte o Chromium)
Na początku trzeba wejść na tę stronę i kliknąć Dodaj do Chrome, a następnie w komunikacie kliknąć Dodaj rozszerzenie.
Mozilla Firefox
Wchodzimy na tę stronę i klikamy na Dodaj do Firefoksa, a następnie zatwierdzamy klikając Dodaj.
Opera
Wchodzimy na tę stronę i klikamy na Dodaj do Opery. Na Operze akurat instalujemy program, który bazuje na Stylishu, lecz docelowo działa tak samo.
Następne kroki
Po dodaniu należy wejść na stronę, której wygląd chcemy zmienić, kliknąć ikonkę Stylisha i zaakceptować warunki korzystania wtyczki.
Potem możemy zainstalować skin dla danej strony, ale aktualnie nie ma żadnych opublikowanych, więc po prostu dodamy nowy. Klikamy na przycisk opcji u góry okienka wtyczki i Create New Style.
W przypadku Opery ze Stylusem należy kliknąć na ikonkę wtyczki, a następnie na link pod Napisz styl dla. Wtedy otworzy nam się to samo, co w innych przeglądarkach.
Otworzy nam się nowe konto, w którym musimy zdefiniować wygląd skina. Na górze, po lewej wpisz nazwę skina (w moim przypadku tf2pickup.pl), następnie zaznacz Enabled pod nazwą. Teraz w sekcji *Code 1 wklej kod, którym zmieniasz wygląd strony (mój kod poniżej):
Akurat to użycie integracji nie daje aż takich korzyści w stosunku do integracji AD na przykład z FortiGate’m, ale nadal można to wykorzystać w ciekawy sposób niespecjalnie pocąc się przy konfiguracji. Założenie jest dosyć proste – umożliwić logowanie się na konta z domeny Active Directory (najnornalniejszej na świecie, żadne udziwnienia w postaci AD na QNAPie czy tym podobne) oraz umożliwić konkretnej grupie w AD korzystanie z uprawnień administracyjnych (aka korzystanie z polecenia sudo).
Moje środowisko składa się z dwóch kontrolerów domeny, ad1.serba.local (192.168.30.2) i ad2.serba.local (192.168.30.3). Do tego są inne hosty w sieci, które są totalnie nieistotne. Jak FQDNy wskazują, moja nazwa domeny to serba.local. Grupa, której damy uprawnienia administracyjne w Linuksach to wbudowana grupa AD Administratorzy domeny. Adres sieci to 192.168.30.0/24 i pierwszy użyteczny adres to adres routera. Przykład integracji opieram na Windowsach Server 2019 v. 1809, Xubuntu 19.10 i Red Hat Enterprise Linux 8.0. Dobrałem takie 2 dystrybucje Linuksa ze względu na to, że one i ich pochodne (przy czym Ubuntu jest pochodną Debiana te podobieństwo działa w drugą stronę) są bardzo podobne w konfiguracji, więc w jednym poradniku będzie można zobaczyć jak zrobić taką integrację na większości dystrybucji. W praktyce powinniśmy być w stanie zintegrować dowolną dystrybucję Linuksa posiadając zainstalowane w systemie odpowiednie pakiety.
Integracja AD na (X)ubuntu
Na początku zaczynamy od instalacji potrzebnych pakietów:
Następnie edytujemy plik /etc/samba/smb.conf w sekcji [global] (ta sekcja zaczyna się pod tym nagłówkiem, a kończy się z miejscem kolejnego):
workgroup = SERBA #tutaj nazwa NETBIOS domeny
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = SERBA.LOCAL #koniecznie dużymi literami
security = ads
idmap config *: range = 10000-20000 #bez dodania tego parametru nie przechodził test cfg
Po wykonaniu zmian warto przetestować, czy wszystko w tym pliku konfiguracyjnym jest OK, w innym wypadku sługi smbd i nmbd nie uruchomią się po restarcie. Robimy to poleceniem sudo testparm:
Następnie edytujemy /etc/sssd/sssd.conf (ten plik domyślnie nie istnieje, więc nie zdziwcie się, jeśli pliku nie będzie):
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[sssd]
domains = serba.local #tutaj nazwa domeny małymi literami
config_file_version = 2
services = nss, pam
default_domain_suffix = SERBA.LOCAL #tutaj domena dużymi literami
full_name_format = %1$s #dzięki tej linijce nie musimy wpisywać `użytkownik@domena` tylko wystarczy `użytkownik`
[domain/serba.local] #małymi literami domena
ad_domain = serba.local #ponownie domena małymi literami
krb5_realm = SERBA.LOCAL #tym razem domena dużymi literami
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash #definiujemy shell dla logujących się użytkowników AD, może być inny
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u #składnia: /home/<nazwa-domeny>/<nazwa-uzytkownika>
access_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_schema = ad
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
Po stworzeniu konfiguracji musimy zabezpieczyć plik w ten sposób, by inni poza rootem nie mieli do niego dostępu:
[active-directory]
os-name = Linux Ubuntu
os-version = 19.04
[service]
automatic-install = yes
[users]
default-home = /home/%d/%u
default-shell = /bin/bash
[serba.local]
user-principal = yes
fully-qualified-names = no
[providers]
samba = no #bez tej linijki są problemy z logowaniem ze wskazaniem uprawnień grup do logowania poprzez realm
Mając to zrobione musimy zrestartować usługi, które konfigurowaliśmy:
# systemctl restart smbd nmbd sssd realmd
Następnie możemy sprawdzić, czy mamy połączenie z domeną pobierając „bilecik” z KDC poprzez polecenie kinit określając nazwę użytkownika@domenę, z której się logujemy:
# kinit rserba@SERBA.LOCAL
Password for rserba@SERBA.LOCAL:
# /etc/sssd > klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: rserba@SERBA.LOCAL
Valid starting Expires Service principal
02.04.2020 21:04:52 03.04.2020 07:04:52 krbtgt/SERBA.LOCAL@SERBA.LOCAL
renew until 09.04.2020 21:04:49
Po tym możemy dołączyć naszym Linuksowym hostem do domeny AD. Najpierw sprawdźmy, czy jesteśmy w stanie wykryć domenę w naszej sieci poleceniem realm discover -v NAZWA.DOMENY:
I teraz już na serio dołączamy do domeny poleceniem realm join NAZWA.DOMENY -U konto_admina -v:
# realm join SERBA.LOCAL -U rserba -v
* Resolving: _ldap._tcp.serba.local
* Performing LDAP DSE lookup on: 192.168.30.3
* Performing LDAP DSE lookup on: 192.168.30.2
* Successfully discovered: serba.local
realm: Już dołączono do tej domeny
Powtarzamy poleceniem net ads join -k:
# net ads join -k
Using short domain name -- SERBA
Joined 'SUPRA-VM' to dns domain 'serba.local'
Następnie musimy ograniczyć logowanie do tego hosta poprzez wskazanie grupy, która może się logować oraz reszty, która tego robić nie może. Pierwszym poleceniem blokujemy dostęp wszystkim użytkownikom, a następnie dodajemy grupę, która może się logować do tego systemu. Wszyscy członkowie tej grupy mogą się zalogować.
# realm deny -a
# realm permit --groups 'serba.local\Administatorzy domeny'
Przed zalogowaniem się musimy też umożliwić automatyczne tworzenie katalogów dla użytkowników (w innym wypadku na dobrą sprawę użytkownicy AD nie będą w stanie normalnie funkcjonować w systemie na własnych prawach):
# pam-auth-update
Po otwarciu okna zaznaczamy Create home directory on login i dajemy OK:
Warto też sprawdzić plik /etc/nsswitch.conf, w sekcjach passwd, group i shadow, netgroup, services i sudoers powinno być dopisane na końcu sss:
Po tym powinniśmy dodać do /etc/pam.d/common-account linijkę na samym dole pliku:
I teraz instalujemy winbind po to, by móc wykorzystać konta AD w ekranie logowania:
# apt install winbind
Usługa winbind.service powinna się uruchomić od razu po instalacji. Sprawdźmy, czy możemy pobrać użytkowników i grupy z AD poleceniami wbinfo -u i wbinfo -g:
# wbinfo -u
SERBA\administrator
SERBA\gość
SERBA\krbtgt
SERBA\fsso
SERBA\rserba
SERBA\smatuszczyk
SERBA\serviceacc
SERBA\mblaszczyk
SERBA\dkania
# wbinfo -g
SERBA\komputery domeny
SERBA\kontrolery domeny
SERBA\administratorzy domeny
SERBA\użytkownicy domeny
SERBA\goście domeny
SERBA\twórcy-właściciele zasad grupy
SERBA\kontrolery domeny tylko do odczytu
SERBA\klonowalne kontrolery domen
SERBA\protected users
SERBA\administratorzy kluczy
SERBA\dnsupdateproxy
SERBA\wydawcy certyfikatów
SERBA\serwery ras i ias
SERBA\grupa z replikacją haseł na kontrolerach rodc
SERBA\grupa bez replikacji haseł na kontrolerach rodc
SERBA\dnsadmins
SERBA\administratorzy schematu
SERBA\administratorzy przedsiębiorstwa
SERBA\kontrolery domeny tylko do odczytu na poziomie organizacji
SERBA\administratorzy kluczy przedsiębiorstwa
Jak widać, działa. Sprawdźmy, czy jesteśmy sprawdzić informacje o użytkowniku rserba:
# sudo getent passwd rserba
rserba@serba.local:*:599001107:599000513:Radosław Serba:/home/serba.local/rserba:/bin/bash
# id rserba
uid=599001107(rserba@serba.local) gid=599000513(użytkownicy domeny@serba.local) grupy=599000513(użytkownicy domeny@serba.local),599000512(administratorzy domeny@serba.local),599000572(grupa bez replikacji haseł na kontrolerach rodc@serba.local)
Na końcu dodamy grupę Administratorzy domeny do /etc/sudoers i umożliwimy na logowanie poprzez interfejs graficzny (wykorzystując menedżer wyświetlania LightDM). Edytujemy /etc/sudoers (plik określający kto w tym systemie może korzystać z polecenia sudo) poleceniem visudo (jak root) i dodajemy linijkę:
#%SERBA\\administratorzy\ domeny ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
#%administratorzy\ domeny@serba.local ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
%administratorzy\ domeny ALL=(ALL:ALL) ALL
Potem edytujemy plik /usr/share/lightdm/lightdm.conf.d/60-xubuntu.conf (na dobrą sprawę możemy sobie nawet sami utworzyć nowy plik w katalogu /usr/share/lightdm/lightdm.conf.d i upewnić się, że będzie miał prawidłową składnię) i dodajemy:
Dzięki temu trzeba będzie wpisać w pole logowania nazwę użytkownika i hasła i w ten sposób będzie można się logować na pulpit tak samo, jak lokalni użytkownicy. Zmiany są widoczne po restarcie usługi lightdm.service, więc możemy po prostu uruchomić system ponownie i wszystko powinno już wejść w życie.
Przy okazji próbując zmienić konto poprzez polecenie su - nazwa_usera_ad możemy sprawdzić czy ograniczenia na logowanie działają:
supra@supra-vm > ~ > su - rserba
Hasło:
rserba@supra-vm:~$ exit
wylogowanie
supra@supra-vm > ~ > su - smatuszczyk
Hasło:
su: Uwierzytelnienie się nie powiodło
W ten sposób wszystko działa poprawnie, przetestujmy sudo:
Okej, na tym etapie musimy też edytować plik /etc/krb5.conf:
# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
udp_preference_limit = 1
rdns = false
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
spake_preauth_groups = edwards25519
default_realm = SERBA.LOCAL #tak, domena musi być z dużej litery
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
SERBA.LOCAL = { #tutaj podobnie
kdc = serba.local #nie wpisujemy poszczególnych kontrolerów domeny, jeśli discovery działa to nie ma sensu podawać tutaj FQDNa kontrolera
admin_server = serba.local #podobnie, w obu przypadkach podajemy z małych liter nazwę domeny
}
[domain_realm]
.serba.local = SERBA.LOCAL #w obu przypadkach z dużej litery domena
serba.local = SERBA.LOCAL
Okej, mając to ustawione zastosujmy konfigurację poleceniem authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update:
[root@rhel8 ~]# authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update
Running authconfig compatibility tool.
The purpose of this tool is to enable authentication against chosen services with authselect and minimum configuration. It does not provide all capabilities of authconfig.
IMPORTANT: authconfig is replaced by authselect, please update your scripts.
See man authselect-migration(7) to help you with migration to authselect
Warning: These options are not supported anymore and have no effect:
--enablelocauthorize
Executing: /usr/bin/authselect check
Executing: /usr/bin/authselect select sssd with-mkhomedir --force
Executing: /usr/bin/systemctl enable sssd.service
Executing: /usr/bin/systemctl stop sssd.service
Executing: /usr/bin/systemctl start sssd.service
Executing: /usr/bin/systemctl enable oddjobd.service
Executing: /usr/bin/systemctl stop oddjobd.service
Executing: /usr/bin/systemctl start oddjobd.service
Dobra, teraz upewnijmy się, że /etc/sssd/sssd.conf wygląda mniej więcej tak (jeśli nie, warto to nieco skorygować):
Jeśli zmienimy cokolwiek, restartujemy usługę (od razu sobie warto ustawić ją tak, by uruchamiała się wraz ze startem systemu):
# systemctl start sssd //w dokumentacji jest service sssd start
# systemctl enable sssd //w dokumentacji jest chkconfig sssd on
Po tym zrestartowałbym system. Na końcu musimy zdefiniować kto może faktycznie się logować do swoich kont administracyjnych:
sudo realm deny -a
sudo realm permit --groups 'serba.local\Administratorzy domeny'
Na końcu dodamy grupę Administratorzy domeny do /etc/sudoers za pomocą visudo:
#%SERBA\\administratorzy\ domeny ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
#%administratorzy\ domeny@serba.local ALL=(ALL:ALL) ALL #nieadekwatny do przykładu
%administratorzy\ domeny ALL=(ALL:ALL) ALL
Na dobrą sprawę to tyle. GDM (menedżer wyświetlania w RHEL 8) nie wymaga dodatkowych modyfikacji, by umożliwić użytkownikom z AD logowanie się na swoje konta w interfejsie graficznym. Wspominając o Fortigate – z pewnego powodu agent FSSO nie widzi logowań na hostach z Linuksem, więc jeśli ktoś by wiedział jak to rozwiązać – zostawcie komentarz.
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
