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 "[email protected],ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
adding new entry "[email protected],ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
adding new entry "[email protected],ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
adding new entry "[email protected],ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
adding new entry "[email protected],ou=Users,domainName=domain.com,o=domains,dc=domain,dc=com"
Możemy spotkać się z takim błędem:
adding new entry "[email protected],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 [email protected] 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 [email protected] powoduje wysłanie maili do [email protected] oraz [email protected].
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 [email protected] oraz [email protected].
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: [email protected],ou=Groups,domainName=mydomain.com,o=domains,dc=etf2l,dc=site
accountStatus: active
cn: demolist
enabledService: mail
enabledService: deliver
enabledService: displayedInGlobalAddressBook
mail: [email protected]
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 [email protected]) 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 [email protected] użytkownik supra będzie miał ustawioną grupę [email protected].
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 [email protected]
Password for [email protected]:
# /etc/sssd > klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
02.04.2020 21:04:52 03.04.2020 07:04:52 krbtgt/[email protected]
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:
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\ [email protected] 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\ [email protected] 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 [email protected]. 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
Tym razem postaram się opisać pokrótce jak krok po kroku sprawić, że możemy logować się kontami z AD do interfejsu konsoli do zdalnego zarządzania serwerem iRMC. iRMC jest narzędziem out-of-band management serwera, dzięki czemu możemy z poziomu takiej witryny sprawdzić, czy serwer jest włączony, czy jego wszystkie komponenty są sprawne lub też nie czy też zdalnie zainstalować system operacyjny lub też zdalnie go obsługiwać. Co ważne, taki interfejs daje nam taką przewagę nad RDP/VNC, że możemy mieć dostęp do serwera będąc np. w ustawieniach BIOS serwera, więc te rozwiązanie pracuje niezależnie od systemu operacyjnego, który pracuje na hoście.
EDIT: Zdecydowałem się rozszerzyć nieco ten post o certyfikat SSL i wykorzystanie LDAP over SSL. Staram się to teraz wdrażać wszędzie, więc tutaj też powiem o tym więcej.
Certyfikat SSL
Zanim zaczniemy, musimy mieć wcześniej wdrożony urząd certyfikacji (na przykład dzięki usłudze certyfikatów Active Directory) i to jest coś, czego tutaj nie będę omawiał. Zanim wygenerujemy żądanie podpisania certyfikatu, warto się zastanowić jaka będzie nasza nazwa hosta. W moim przypadku jest to irmc-vhost1.serba.local ze względu na to, że mogę zawsze mieć wiele serwerów z iRMC, przez co same irmc.serba.local mogłoby być kiepskim rozwiązaniem po kupnie drugiej maszyny. Na początku zdefiniowałem w DNS przypisany do adresu iRMC, by można go było potem używać zamiast adresu IP. Efekt widać poniżej:
Następnie za pomocą OpenSSL stworzyłem klucz oraz wygenerowałem żądanie certyfikatu. Nie będę się o tym rozpisywał – opisałem cały proces tutaj. W stosunku, co jest w podlinkowanym poradniku należy zmienić jedynie CN oraz DNS.1 na irmc-vhost1.serba.local. Po wygenerowaniu CSRki można bić do serwera i wygenerować certyfikat SSL. Jeśli mamy zainstalowaną funkcję urzędu certyfikacji o nazwie Rejestracja w sieci Web dla urzędu certyfikacji, możemy podpisać żądanie przez stronkę urzędu, co zalecam robić, bo jest po po prostu proste i przyjemne. Adres takiej strony to http://<adres-ca>/certsrv. W moim przypadku jest to https://dc1.serba.local/certsrv (zmieniłem kilka ustawień w IIS, by mieć połączenie po HTTPS ;))
Na początku należy się zalogować swoim kontem administracyjnym w AD:
Następnie należy wybrać Żądanie certyfikatu.
Następnie wybieramy zaawansowane żądanie certyfikatu.
Na tym etapie musimy otworzyć nasz plik CSR w jakimś edytorze tekstu, skopiować zawartość i wkleić w pole żądania. Ponadto, musimy wybrać szablon certyfikatu, dzięki czemu określamy przeznaczenie certyfikatu, który generujemy. To, co nasz interesuje to Serwer sieci Web. Po tym klikamy Prześlij >.
Po tym pobieramy certyfikat w formacie Base-64.
Ponadto, musimy pobrać certyfikat urzędu certyfikacji, co możemy zrobić na stronie głównej urzędu poprzez opcję Pobierz certyfikat urzędu certyfikacji, łańcuch certyfikatów lub listę CRL, a następnie mając zaznaczoną metodę kodowania Base 64, następnie klikając Pobierz certyfikat urzędu certyfikacji.
Następnie musimy się zalogować do interfejsu iRMC i wgrać certyfikaty urzędu certyfikacji oraz certyfikatu SSL wraz z kluczem prywatnym, który wykorzystaliśmy przy wygenerowaniu CSRki. W Tools > Certificates > Current CA Certificate for CAS and SMTP należy kliknąć Load from File (stronę trzeba rozwinąć i znajdziemy przycisk w dolnej części karty po prawej stronie.
Następnie należy kliknąć Select…, wybrać plik CA i po tym kliknąć Upload. W ten sposób mamy zainstalowany certyfikat CA. Następnie wrzucamy certyfikat w Certification Authorities for eLCM rozwijając opcje, klikając Add, następnie w From file wybierając plik i zatwierdzając przyciskiem Add:
Efekt końcowy wygląda tak:
Na końcu rozwijając Current SSL/TLS Certificate należy kliknąć Load from File, a następnie w polu SSL/TLS public key dodać plik wygenerowanego certyfikatu SSL, a w SSL/TLS private key należy umieścić klucz prywatny, którym wygenerowaliśmy CSRkę, to wygląda tak:
Po tym klikamy Upload. Jesteśmy ponadto informowani, że należy wykonać restart iRMC w celu zastosowania zmian, więc klikamy Reboot iRMC.
No i czekamy.
Przed restartem systemu strona była wyświetlana jako niezaufana:
Po restarcie mamy wynik osiągnięty:
Teraz można przejść do integracji.
Integracja SSO
Do integracji należy skorzystać z drugiej płyty ServerView, którą można ściągnąć na stronie producenta po wybraniu swojego modelu urządzenia pod tym linkiem.
Następnie po otwarciu pliku .iso znajdującego się w Archiwum należy odnaleźć plik SVS_LdapDeployer.zip w ścieżce <litera-obrazu>:\SVSSoftware\Software\RemoteView\iRMC_Tools\SVS_LdapDeployer. Kopiujemy go na komputer, na którym:
Jesteśmy zalogowani na konto administracyjne w domenie i mamy do niej dostęp (najlepiej nie logować się bezpośrednio na kontrolerze domeny),
Po rozpakowaniu archiwum otwieramy zawartość i kopiujemy plik Configuration_InitialDeploy_ActiveDirectory.xml do katalogu, w którym znajduje się plik SVS_LdapDeployer.jar.
Następnie edytujemy wspomniany plik .xml. W następującej linii poprawiamy adres na adres naszego kontrolera domeny. Jeśli na serwerze nie używa się SSLa do szyfrowania komunikacji, powinno się zmienić port na 389 i zmienić wpis SSLEnabled na false:
Dzięki temu programik do tworzenia drzewa OU ServerView spyta nas o hasło przed rozpoczęciem pracy. Następnie w sekcji Data mamy do zdefiniowania role:
<Roles>
<Role name ="Administrator" >
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="RemoteStorage" />
<Privilege name ="UserAccounts" />
<Privilege name ="VideoRedirection" />
<Privilege name ="CfgConnectionBlade" />
<Privilege name ="RedfishAdmin"/>
</Role>
<Role name ="Maintenance">
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="VideoRedirection" />
<Privilege name ="RedfishOperator"/>
</Role>
<Role name ="Operator">
<Privilege name ="IpmiLanOperator" />
<Privilege name ="IpmiSerialOperator" />
<Privilege name ="VideoRedirection" />
<Privilege name ="RedfishOperator"/>
</Role>
<Role name ="Monitor">
<Privilege name ="IpmiLanUser" />
<Privilege name ="IpmiSerialUser" />
<Privilege name ="RedfishReadOnly"/>
</Role>
<Role name ="CustomRole">
<Privilege name ="IpmiLanUser" />
<Privilege name ="IpmiSerialUser" />
<Privilege name ="VideoRedirection" />
</Role>
</Roles>
Z reguły nie ma potrzeby posiadania tylu ról, dlatego usuwam wszystkie poza adminem, docelowo wygląda to tak:
<Roles>
<Role name ="Administrator" >
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="RemoteStorage" />
<Privilege name ="UserAccounts" />
<Privilege name ="VideoRedirection" />
<Privilege name ="CfgConnectionBlade" />
<Privilege name ="RedfishAdmin"/>
</Role>
</Roles>
Potem, w sekcji Departments zmienam w Department name na nazwę domeny bez końcówki, więc w tym przypadku ustawiłbym serba, poza tym wyrzucam usunięte role poniżej:
<Departments>
<!--
# any number of departments possible
# !!! Name of Department and associated roles need to be changed !!!
-->
<Department name ="DeptX">
<!--
# List of associated roles.
# any number of roles, but only from roles defined above
-->
<Role name ="Administrator" />
<Role name ="Maintenance" />
<Role name ="Monitor" />
<Role name ="CustomRole" />
</Department>
</Departments>
Po zmianie:
<Departments>
<!--
# any number of departments possible
# !!! Name of Department and associated roles need to be changed !!!
-->
<Department name ="serba">
<!--
# List of associated roles.
# any number of roles, but only from roles defined above
-->
<Role name ="Administrator" />
</Department>
</Departments>
Po wykonaniu zmian zapisuję plik i otwieram konsolę PowerShell lub Wiersz poleceń z uprawnieniami administracyjnymi:
Po tym przechodzę do ścieżki z programem SVS_LdapDeployer i
odpalam polecenie:
Zostaniemy zapytani o hasło i podczas wpisywania jest ono widoczne.
Po wykonaniu tej czynności powinniśmy mieć gotowe drzewko w AD.
Teraz należy utworzyć konto, które będzie wykorzystywane w iRMC w celu sprawdzania kto jest członkiem tej grupy Administrator, a następnie należy dodać je do tej grupy wraz ze wszystkimi kontami użytkowników, które mają mieć dostęp do iRMC. Należy dodać konta użytkowników, a nie grupy ze względu na to, że iRMC nie obsługuje z jakiegoś powodu dziedziczenia członkostwa w grupach. Na potrzeby usługi utworzyłem konto serviceacc:
Nastęonie zanim zacznie się konfigurować profil domeny należy skonfigurować serwery DNS dla naszej domeny w Settings > Network Management > DNS:
Enable DNS: zaznaczone
DNS Configuration: Obtain from DHCP odznaczone
DNS Domain: po prostu nazwa naszej domeny
DNS Search Path: możemy też podać nazwę naszej domeny, dzięki temu dc1.serba.local == dc1. Nie wiem w sumie jak można to wykorzystać, ale ogólnie to jest najlepsza opcja konfiguracji.
DNS Server 1, 2 i 3: tutaj podajemy adresy DNS, z których korzystamy.
W moim przypadku efekt wygląda tak:
Po dodaniu kont do grupy musimy zdefiniować ustawienia w iRMC, dzięki któremu iRMC będzie wiedziało jak komunikować się z AD. Po zalogowaniu się do iRMC otwieramy u góry kartę Settings, następnie User Management po lewej stronie i z niej rozwijamy ustawienia Lightweight Directory Access Protocol (LDAP).
Następnie wpisujemy tutaj dane (Backup LDAP Server jest opcjonalny, jeśli posiadasz drugi kontroler domeny to warto go tu wpisać):
Global Configuration
Enable LDAP: zaznaczone
Enable LDAP SSL/TLS: wedle preferencji, w moim przypadku zaznaczone
Disable Local Login: ta opcja wyłącza możliwość logowania się z kont lokalnych, odradzam zaznaczanie jej
Directory Server Type: Active Directory
Primary LDAP Server
Server: dc1.serba.local
Network Port: 389
SSL/TLS Network Port: 636
Backup LDAP Server
Server: dc2.serba.local
Network Port: 389
SSL/TLS Network Port: 636
Directory Configuration
Authorization Type: ServerView LDAP Groups with Authorization Settings on LDAP Server
Department Name: serba
Domain Name: serba.local
Groups Directory as Sub-tree from Base DN: (puste)
W tej konfiguracji wyżej korzystam z FQDN serwerów – warto o tym pamiętać, by ustawić w konfiguracji serwer DNS tak, by wskazywał na nasze kontrolery domeny, dzięki czemu nazwy będą rozwiązywały się poprawnie. Potem przechodzimy do sekcji, w której określamy użytkownika, z którego korzystamy do komunikacji z AD i pole obiektu AD, z którego korzystamy:
Tutaj definiujemy:
Access Configuration
Authentication LDAP Username: serviceacc
Authentication LDAP Password: *********
Confirm Password: *********
Principal User DN: (puste)
Append Base DN to Principal User DN: odznaczone
Enable Enhanced User Login: zaznaczone (opcjonalne)
User Login Search filter: (&(objectClass=person)(sAMAccountName=%s))
Pole obiektu AD, po którym iRMC wyszukuje użytkownika domyślnie to cn, dlatego ja to zmieniam na sAMAccountName, bo wtedy korzystamy z takiego samego loginu jak do Windowsa. 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:
W ten sposób można się logować na konta z Active Directory. Warto sobie w takiej sytuacji zmienić hasło dla konta lokalnego admin na długie ze względów bezpieczeństwa.
Efekt końcowy wygląda następująco:
UPDATE: Dzisiaj w trakcie wdrożenia na Windowsie Server 2019 Essentials miałem taki problem, że po wykonaniu instrukcji powyżej nie byłem w stanie stworzyć sobie drzewka w AD i otrzymywałem błąd:
- The keystore location is not accessible.
- The keystore's password is not correct.
- The keystore you specified is not the one generated during encryption.
Please try again or reset the password.
Rozwiązanie jest takie, by podać login i hasło do konta, którym się autoryzujemy w parametrach w plaintext:
Zawsze polecam zmieniać hasło na takie, które można pokazać przed innymi, a potem zmienić z powrotem na bezpieczne; w innym wypadku róbmy takie operacje będąc w zaufanym gronie osób (to znaczy często w osobności).
Druga rzecz to jest to, że w katalogu z szablonami są pliki Configuration_InitialDeploy_ActiveDirectory.xml i Configuration_InitialDeploy_AD.xml. W tym poradniku korzystałem z tego pierwszego.
