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.
Nie wiem jak dużo ludzi słyszało o tym narzędziu, jedno jest pewne. Jakoś działa. Kiedy musimy z niego korzystać? Na pewno wtedy, jeśli dwie firmy czy dwa oddziały łączą się w jeden. To ogólnie może być spory problem – co jeśli na przykład jeden oddział pracuje na staruszku Windows Server 2003, a drugi śmiga na nowości, czyli Windowsie Server 2016 czy 2019? Sytuacja się komplikuje, a pomysłów może brakować. Często ludzie wtedy zastanawiają się na postawienie domeny od zera, lecz czy to ma sens? Trzeba podłączyć wszystkie systemy od zera. Tam, gdzie mamy skonfigurowane usługi powiązane z domeną – do piachu i od nowa.
Rozwiązaniem jest ADMT (Active Directory Migration Tool). Stare narzędzie od Microsoftu, które pozwala na migrację obiektów pomiędzy domenami. Pozwala nam na przenoszenie:
kont użytkowników (z profilami użytkowników i hasłami do kont),
grup użytkowników,
kont komputerów (z uprawnieniami),
kont wykorzystywanych do usług, np. konto serwisowe dla UTMa, które ma na celu sprawdzanie dziennika zdarzeń w poszukiwaniu informacji logowaniach użytkowników na konkretnych komputerach w domenie,
raportowania.
Ja akurat w tym poście przerobię przykład na nowszych kontrolerach domeny, to znaczy będę przenosił obiekty z Windowsa Server 2008 R2 na 2019. Jeśli macie starsze systemy (np. Windows Server 2003 czy 2003 R2), warto sobie w takiej sytuacji postawić taki Windows Server 2008 R2 tymczasowo. I tak będziemy go potrzebowali, bo nie zrobimy bezpośredniej migracji z Windowsa Server 2003 (brak obsługi DFSR, SMBv1)/2003 R2 (SMBv1). To akurat opisałem już tutaj – może się przydać.
Przygotowanie do pracy
Zanim zaczniemy, przedstawię środowisko, które mamy do dyspozycji:
Stara domena:
Nazwa domeny: nowadomena.local (tak, wiem, że nazwa jest myląca w tym poradniku)
W powyższym przykładzie zastosowałem pewne uproszczenia, mianowicie zwykle będzie tak, że oba serwery będą w dwóch różnych podsieciach. Do migracji elementów w domenie kontrolery (przynajmniej jeden po obu stronach) muszą mieć między sobą łączność, czyli np. muszą mieć umożliwiony routing i odblokowany ruch na firewallu. Aby nawiązać relację zaufania między kontrolerami domeny one muszą między sobą być w stanie rozwiązywać nazwy DNS, czyli kontroler ad-2008-r2 będący kontrolerem domeny nowadomena.local musi być w stanie rozwiązać nazwy z domeny supratest.local, a serwer ad-2019 będący kontrolerem domeny supratest.local musi być w stanie rozwiązywać nazwy w domenie nowadomena.local, stąd należy ustawić na tych hostach preferowane serwery DNS tak, by serwery wskazywały na siebie na wzajem. Z faktu, że są kontrolerami domeny, drugorzędnym serwerem DNS są one same, dzięki czemu rozwiązują nazwy we własnych domenach.
Instalacja narzędzi do migracji
Swoją drogą, nie wiem jak na Windowsie Server 2003 R2, ale na Windowsie Server 2003 nie byłem w stanie używać ADMT, więc w takich przypadkach trzeba instalować ADMT na Windowsie Server 2008 (R2). Na samym początku warto zacząć od instalacji Microsoft SQL Server 2008 (NIE R2), a po tym trzeba zainstalować Service Pack 1 do tej wersji SQLa. W instrukcji skorzystamy z darmowej wersji Express. Przejdźmy przez etap instalacji. Po odpaleniu instalatora wybieramy tylko funkcję Database Engine Services:
Następnie pozostawiamy nazwę instancji jako SQLEXPRESS (właściwie wszystkie te pola można zostawić bez zmiany i iść dalej).
Teraz musimy wskazać konto, które będziemy wykorzystywać jako konto obsługujące usługi serwera SQL. Ja wybrałem konto ZARZĄDZANIE NT\SYSTEM (w angielskim Windowsie NT AUTHORITY\SYSTEM).
Następnie wybieramy tryb uwierzytelniania Mixed Mode i definiujemy domyślne hasło do bazy danych. Dodałem też konto Administrator jako konto administracyjne dla SQLa.
Potem wystarczy jedynie klikać dalej i w ten sposób przejdziemy przez proces instalacji. Po tym musimy też zainstalować SQL Server 2008 Service Pack 1 (od niedawna odnośnik do niego na stronie Microsoftu jest niedostępny, więc jeśli tego potrzebujesz, spróbuj znaleźć plik o nazwie SQLServer2008SP1-KB968369-x64-ENU.exe (wersja 64-bitowa) lub SQLServer2008SP1-KB968369-x86-ENU.exe (wersja 32-bitowa) w Internecie):
Gdy mamy to za sobą, możemy przejść do instalacji ADMT. Pobierzemy je tutaj. Na samym początku musimy wskazać instancję bazy danych, z której chcemy korzystać. Wskazuję .\SQLEXPRESS. Ta kropka na początku oznacza, że to jest ta sama maszyna, na której pracujemy (po prostu maszyna lokalna).
Następnie wybieramy, że nic nie importujemy.
I to tyle, po tym powinien się ten program zainstalować. Poza tym musimy jeszcze zainstalować ADMT Password Export Server, ale do tego dojdziemy później.
Tworzenie relacji zaufania między domenami
Następnym krokiem jest stworzenie dwustronnej relacji zaufania między domenami. By to zrobić, należy w konfiguracji DNS obu domen stworzyć conditional forwarder na wzajem, czyli w DNSie nowadomena.local musi być conditional forwarder do supratest.local i w DNSie supratest.local musi być conditional forwarder do nowadomena.local. Ponadto musimy w obu domenach utworzyć strefy do wyszukiwania wstecz (rDNS). Warto zrestartować serwery po wykonaniu tych czynności – w moim przypadku dalszy etap nie dział dojść do skutku pomimo tego, że zrobiłem wszystko poprawnie, a po restarcie magicznie zaczęło działać.
By to zrobić, klikamy na drzewku serwera DNS w gałąź Strefy wyszukiwania wstecznego PPM i wybieramy Nowa strefa…
Na początku wybieramy strefę, którą chcemy utworzyć. Nas interesuje strefa podstawowa.
Następnie w pierwszym oknie kreatora wybieramy opcję Do wszystkich serwerów DNS uruchomionych na kontrolerach domeny w tym lesie: nowadomena.local:
Potem musimy wskazać, czy strefa będzie dotyczyć IPv4 czy IPv6. Wybieramy IPv4.
Następnie wskazujemy identyfikator sieci dla strefy rDNS, czyli w moim przypadku to 192.168.162.x:
Pod koniec, w ustawieniach aktualizacji dynamicznych wybieramy opcję Zezwalaj tylko na zabezpieczone aktualizacje dynamiczne (zalecane dla Active Directory).
W ten sposób mamy utworzoną strefę wyszukiwania wstecz i musimy to samo zrobić na drugim kontrolerze domeny. Następnie by utworzyć usługę warunkowego przesyłania dalej klikamy na gałąź Usługi warunkowego przesyłania dalej PPM i wybieramy Nowa usługa warunkowego przesyłania dalej….
Teraz w polu Domena DNS definiujemy nazwą domeny, do której przesyłamy zapytania DNS dalej, czyli na kontrolerze domeny supratest.local wskazujemy domenę nowadomena.local i poniżej w sekcji Adresy IP serwerów głównych wskazujemy adres serwera DNS tej domeny, czyli 192.168.162.11. Jeśli w waszej organizacji jest więcej niż jeden serwer DNS w domenie, należy wtedy zaznaczyć opcję Przechowaj tę usługę warunkowego przesyłania dalej w usłudze Active Directory i replikuj ją w następujące serwery: i wybieramy z listy Wszystkie serwery DNS w tym lesie.
Analogicznie robimy to samo dla domeny supratest.local na kontrolerze domeny nowadomena.local:
Mając to gotowe możemy w końcu nawiązać relację zaufania w przystawce Domeny i relacje zaufania usługi Active Directory klikając prawym na nazwę naszej domeny i Właściwości.
Następnie wybieramy zakładkę Zaufania i klikamy przycisk Nowe zaufanie….
Jeśli widzisz takie opcje w pierwszym oknie wyboru – to oznacza, że prawdopodobnie nie wykonałeś któregoś z poprzednich kroków. Ja tak miałem i zorientowanie się w czym popełniłem błąd zajęło mi tak z dobre 20 minut.
Jeśli wszystko jest okej, powinieneś zobaczyć takie opcje wyboru (wybieramy typ zaufania Zaufanie lasu):
Następnie wybieramy kierunek zaufania jako dwukierunkowy:
Teraz wskazujemy utworzenie zaufania dla tej domeny i określonej domeny.
Następnie musimy podać poświadczenia do konta administracyjnego w tej drugiej domenie. Zwróćcie uwagę, że ja tą czynność wykonuję z kontrolera domeny supratest.local!
Jako zakres uwierzytelniania dla użytkowników lasu nowadomena.local wybierzemy Uwierzytelnienie dla całego lasu.
Na końcu powinniśmy potwierdzić przychodzące i wychodzące zaufanie, więc tak też zaznaczamy.
Ostatnie machnięcia pędzlem przed rozpoczęciem migracji
I cyk, gotowe. Mamy relację zaufania pomiędzy dwoma domenami. Teraz przydadzą nam się jeszcze 3 rzeczy przed rozpoczęciem migracji:
dodane uprawnień do grup administracyjnych w domenach nawzajem,
zainstalowanie Password Export Server,
wyłączenie firewalla na stacjach końcowych.
W grupie Administratorzy członkami są:
użytkownik Administrator,
grupa Administratorzy domeny (Domain Admins),
grupa Administratorzy przedsiębiorstwa (Enterprise Admins).
W momencie pisania tego posta znalazłem posta, który dobrze opisuje do czego te grupy są, polecam zerknąć tutaj, by zaczerpnąć dobrej lekturki! Tak czy siak, musimy tych członków grupy dodać nawzajem z obu domen, dzięki czemu w moim przykładzie w obu grupach Builtin\Administratorzy (Builtin\Administrators) lista członków będzie wyglądała następująco:
Teraz warto zainstalować ADMT Password Export Server. Na początku musimy utworzyć plik klucza szyfrującego, bo będzie nam potrzebny w instalacji. Zrobimy to za pomocą następującego polecenia (oczywiście możemy zmienić ścieżkę pliku i hasło):
cd C:\Windows\ADMT
admt.exe Key /Option:Create /SourceDomain:NOWADOMENA.LOCAL /KeyFile:C:\FileMigPass.pes /KeyPassword:Pass@123
Po pobraniu instalatora i uruchomieniu go zostaniemy poproszeni o ten plik klucza, co zrobiliśmy wyżej i o podanie hasła do niego:
Następnie musimy wskazać konto, na którego prawach będzie pracowała usługa serwera haseł. Ja wskazałem tutaj konto [email protected] (jak sam zrzut ekranu sugeruje te konto musi móc pracować w trybie usługi):
Po instalacji serwera haseł musimy zrestartować serwer, na którym wykonaliśmy instalację, a następnie włączyć jego usługę w przystawce Usługi (services.msc), usługa nazywa się Password Export Server Service:
Na koniec polityką GPO wyłączymy firewall we wszystkich systemach w firmie (zakładając, że wykorzystują jedynie Zaporę systemu Windows. W przystawce Zarządzanie zasadami grupy tworzymy nowy obiekt GPO klikając PPM na Obiekty zasad grupy i wybieramy Nowe, następnie wpisujemy nazwę polityki i zatwierdzamy.
Możemy ją od razu przeciągnąć i upuścić pod OU Komputery zakładając, że tam są wszystkie komputery, które chcemy przenosić (tam jest nasz host ENDPOINT-1 do przeniesienia). Następnie klikamy na obiekt PPM i wybieramy Edytuj….
Następnie przechodzimy do Konfiguracja komputera > Zasady > Szablony administracyjne > Sieć > Połączenia sieciowe > Zapora systemu Windows > Profil domeny i wyłączamy opcję Zapora systemu Windows: chroń wszystkie połączenia sieciowe. To samo wykonujemy na kontrolerze domeny w drugiej domenie.
Domyślnie po 90 + od 0 do 30 minut polityka wejdzie w życie na stanowiskach końcowych. Możemy przyspieszyć ten proces wykonując na tych maszynach polecenie gpupdate /force. Jeśli masz innego firewalla w systemie (np. jeśli korzystasz z ESET Endpoint Security) – powinieneś do wyłączenia antywirusa wykorzystać dedykowane narzędzia do tego, czyli w przypadku ESETa jest to konsola ESMC (ESET Security Management Center). Dla ciekawskich, tutaj opisano z jakich portów korzysta ogólnie Active Directory.
W ten sposób firewall jest wyłączony i możemy zacząć prawdziwą migrację.
Migracja kont użytkowników, grup, komputerów, zabezpieczeń i haseł
Zaczynamy od uruchomienia ADMT (Active Directory Migration Tool). W nim, klikamy prawym na górę drzewka i wybieramy opcję, która nas interesuje. Z faktu, że musimy zrobić migrację komputera, musimy wykonać migracje (we wskazanej kolejności):
użytkowników,
grup użytkowników,
translację zabezpieczeń,
migrację haseł (to się robi już na etapie migracji użytkowników),
komputerów.
Zaczniemy więc od migracji użytkowników kreatorem User Account Migration Wizard. Musimy na początku wskazać źródłową i docelową domenę względem których wykonujemy migrację. Wskazałem w Source domenę nowadomena.local i w Targetsupratest.local.
Następnie wybieramy Select users from domain, ponieważ chcemy wybierać użytkowników do migracji z drzewa AD, a nie z pliku.
Następnie wskazujemy użytkowników dodając ich z drzewka. Ja już dodałem dwóch:
Potem wskazujemy OU do którego przenosimy użytkowników w docelowej domenie. Nie stworzysz OU w nowej domenie z tego kreatora, więc jeśli planujesz jakiś konkretny schemat drzewa to przygotuj sobie go przed migracją. Wystarczy kliknąć w odpowiedni element drzewka po kliknięciu Browse… w domenie i to spowoduje, że adres się sam uzupełni.
W następnej części kreatora zostaniemy spytani, czy chcemy też migrować hasła użytkowników. Z faktu, że mamy już wdrożony ADMT Password Export Server, skorzystamy z tego. Wybieramy opcję Migrate passwords. Wskazujemy też kontroler domeny z którego migrujemy takie hasła, w moim przypadku to jest ad-2008-r2.nowadomena.local.
Następnie musimy określić w jaki sposób ma być realizowana migracja kont użytkowników. Aby uniknąć problemów wybieram opcję Target same as source. To powoduje, że jeśli konto jest włączone to docelowo też będzie na drugiej domenie i odwrotnie. Wybieram też na dole Migrate user SIDs to target domain. To jest istotne przy migracji komputerów z tego względu, że profile użytkownika i uprawnienia plików (np. na udziałach sieciowych) są do takiego SIDa przypisane i z tego powodu chcielibyśmy, by ten SID użytkownika się nie zmieniał. Poza tym musimy dać Tak w obu monitach, bo bez tego migracja SIDów się nie wykona:
Potem, musimy zdecydować czy chcemy dokonać translacji profili mobilnych, zaaktualizować uprawnienia użytkownika i przenieść grupy, w których jest użytkownik. Opcji jest więcej, w skrócie zaznaczamy wszystkie:
Kolejna rzeczy to wybór właściwości obiektów, które przenosimy. W skrócie nie wykluczamy żadnych, więc przechodzimy dalej bez zmieniania czegokolwiek.
Ostatnią rzecz, którą wybieramy jest decyzja co ma zrobić kreator, gdy pojawią się problemy w postaci konflików (np. przenosimy obiekt, który już istnieje w domenie docelowej). Najlepszym rozwiązaniem jest przeniesienie bez migracji obiektów z konfliktami i przejrzenie ich ręcznie by zobaczyć co właściwie jest nie tak, czy obiekty dotyczą takiej samej osoby i potem można uruchomić ten sam kreator ponownie, gdy się rozwiąże problem (np. przez usunięcie starego obiektu w docelowej domenie).
W ten sposób dotarliśmy do końca kreatora. Po kliknięciu Zakończ rozpocznie się proces migracji (okienko po prawej). Kliknąłem też View Log, by pokazać Wam jak wyglądają logi z takiej migracji.
Okej, teraz przejdźmy do migracji zabezpieczeń, którą trzeba wykonać przed migracją komputerów. Na tym etapie musimy mieć przygotowane komputery, które przenosimy w taki sposób, że:
mają możliwość rozwiązywania nazw DNS w nowej domenie,
mamy możliwość korzystania z uprawnień administracyjnych z obu domen,
maszyny NIE mogą być uśpione/we wstanie wstrzymania,
tak jak wcześniej to zmienialiśmy komputery najlepiej gdyby miały wyłączony firewall na czas migracji tak, aby agenty ADMT mogły się szybko zainstalować i wykonać ich robotę,
taką translację powinniśmy robić na komputerach bez zalogowanych użytkowników. Dzięki temu nie mamy żadnych błędów przy translacji.
Jeśli jesteśmy pewni, że to jest zrobione i możemy odpalić kreator Security Translation Wizard:
W tym procesie przyzwyczaimy się do tego widoku…
Wybieramy opcję Previously migrated objects.
Tutaj zostawiamy tak samo jak poprzednio, bo przenosimy nadal z domeny nowadomena.local do supratest.local.
Wskazujemy komputery dla których translacja ma być wykonana poprzez drzewko z domeny wskazując opcję Select computers from domain, następnie wybieramy komputery, które nas interesują.
Poza wybraniem komputerów wskazujemy dodatkowo w polu Additional trusting domain domenę nowadomena.local.
Następnie zaznaczamy wszystkie pola. Po prostu.
W następnym polu zaznaczamy opcję Add, bo jeśli coś pójdzie nie tak to w żaden sposób nie zmodyfikujemy obiektów w naszej domenie.
Następnie po tym otworzy nam się okno Active Directory Migration Tool Agent Dialog, w którym taki proces migracji się odbywa. Jest on nieco bardziej rozbudowany, bo migracja nie odbywa się natychmiast, dzięki mamy czas po zakończeniu kreatora, by upewnić się, że komputery są gotowe do migracji. Na początku wybieramy Run pre-check dzięki czemu sprawdzimy, czy agent się poprawnie zainstaluje na maszynie końcowej. Dopiero po tym możemy wykonać translację.
Jeśli otrzymujesz po pre-checku następujący błąd:
ERR2:7666 Unable to access server service on the machine 'computer.domain.com'. Make sure netlogon and workstation services are running and you can authenticate yourself to the machine. hr=0x800706ba. The RPC server is unavailable
To oznacza, że firewall blokuje połączenie, ogólnie te błędy się sprawdza w View Migration Log. Po prostu wyłącz firewall i wtedy zadziała. Jeśli stan Pre-check jest Passed, możemy wybrać Run pre-check and start agent operation. Oczywiście wtedy Agent Dialog pominie test i zajmie się tym, czym właściwie ma. Jeśli mieliście zalogowanych użytkowników na danej stacji, to translacja zakończy się z ostrzeżeniami.
W innym wypadku nie powinno być problemu jak tutaj (po prostu uruchomiłem dla tego samego komputera kreator ponownie):
Okej, w takim razie w tym momencie doszliśmy do etapu przewodniego tego posta – migracji komputerów. Odpalamy kreator Computer Migration Wizard. Na samym początku wskazujemy domeny tak samo jak poprzednio:
Potem wskazujemy komputer(y) tak samo jak w kreatorze translacji zabezpieczeń (opcją Select computers from domain i wybierając je z drzewka):
Następnie wskazujemy DN dla docelowego OU, w którym ma się znajdować komputer po przeniesieniu do domeny (tak samo jak w migracji użytkowników/grup wskazujemy miejsce w drzewku, a adres się sam uzupełni):
Tak jak poprzednio, zaznaczamy wszystkie elementy do translacji.
Podobnie jak w poprzednim kreatorze, zaznaczamy opcję translacji zabezpieczeń Add (choć ja zaznaczyłem Replace na zrzucie).
Potem określamy czas, po jakim migracja się rozpocznie. Jeśli pracownicy pracują przy komputerach i są tego świadomi, że będzie wykonywana taka migracja lub ich po prostu nie ma, warto zaznaczyć 0 – po prostu migracja rozpocznie się natychmiast.
Podobnie jak w przypadku migracji użytkowników nie wykluczamy żadnych atrybutów obiektów ani nie migrujemy obiektów, jeśli pojawi się jakiś konflikt pomiędzy domenami (lecz teraz nie między obiektami użytkowników/grup, a obiektami komputerów).
Na koniec obiekt zostanie skopiowany i na maszynie powinien odpalić się ten sam proces przygotowania instalacji agenta ADMT jak w przypadku translacji zabezpieczeń.
Tutaj po zakończeniu migracji możemy zobaczyć, że komputer się restartuje…
i kończymy sukcesem, bo podłączył się do nowej domeny.
Co prawda nie mam screenshota z przeniesionego hosta, ale po zalogowaniu się do użytkownika, z którego korzystałem na tej przeniesionej maszynie mogłem się zalogować do tego samego profilu, lecz przy pierwszym logowaniu musiałem zmienić hasło (starym hasłem było hasło dotychczasowe ze starej domeny). I tyle, w ten sposób można zrobić migrację komputerów dzięki ADMT!
Sporo informatyków w różnych organizacjach ma jeden duży problem – jego organizacja nie ma lub nie chce przeznaczać środków na IT. Nie ma kasy na nowy serwer, nie ma kasy na Windowsa Server 2019 (Essentials lub Standard) i nie ma kasy na licencje CAL (w przypadku wersji Standard). W takiej sytuacji pojawia się pomysł: „hej, w końcu na QNAPie i Synology jest funkcja kontrolera domeny, postawmy domenę na tym”. Moja sugestia:
Nie rób tego.
Dlaczego? To, że ta funkcja w tych systemach tak się nazywa nie znaczy, że oferuje dokładnie to samo, co kontroler domeny w Windowsie z prawdziwego zdarzenia. By oszczędzić Ci włosów, które byś sobie wyrwał(a) z głowy w trakcie pracy na tym, postanowiłem samemu przekonać się na własnej skórze jak to działa w praktyce.
Przygotowanie do testów
Mam w domu QNAPa TS-453A z 8 GB RAMu z 4 dyskami 2 TB marki WD. klientami są maszyny wirtualne, które stawiałem w środowisku VMware Workstation Pro 15.x. Założenie jest proste – podłączyć do niego maszyny i próbować sprawdzić jak zachowuje się domena oraz jaka jest jej charakterystyka. Prędzej czy później w firmach znajdują się środki, więc pewnie kiedyś taka domena po jakimś czasie zostałaby przeniesiona na nowy kontroler domeny.
Praktyka
Na początek podłączyłem sobie Windowsa Server 2016 do tej domeny, bo chciałem przenieść domenę na drugi kontroler (zainstalowałem na tym Windowsie rolę Usługi domenowe Active Directory). Chciałem to zrobić w sposób, który opisałem tutaj. Nie wyszło, dlaczego? Przed startem podniesienia drugiego kontrolera domeny otrzymuję komunikat, że serwer RPC nie jest dostępny, ani, że serwer nie jest w stanie skontaktować się z aktualnym kontrolerem poprzez WMI.
Próba promocji Windowa Server 2016 do roli kontrolera domeny
Na tym etapie zrezygnowałem. Może inny Windows Server da radę? Sprawdziłem na 2019, to samo.
Próba promocji Windowa Server 2012 do roli kontrolera domeny
Powyżej zrzut ekranu z 2012 – też to samo, 2012 R2 – te same efekty. Sprawdziłem sobie poziom funkcjonalności lasu i domeny – Windows Server 2008 R2. To oznacza, że te hosty powinny się bez problemu podłączać.
Jak spróbowałem podłączyć system Windows Server 2008 R2 (ze starszymi nie próbuję, ten i tak już nie jest wspierany) do domeny to otrzymałem taki komunikat:
W dużym skrócie – nie podepniesz go do domeny. W takiej sytuacji myślę sobie – ale przecież możemy zrobić relację zaufania pomiędzy domenami i tak przenieść wszystkie obiekty w AD wraz ze wzorcami na nowy serwer. Z tym pomysłem też się przejechałem, bo jak otworzyłem DNSa na koncie Administratora to dostałem to:
W QNAPie jest zakładka do zarządzania DNSem, wygląda ona tak:
Opcje związane z zarządzaniem usługami do warunkowego przekierowania tu nie istnieją, a bez tego nie zrobimy dwustronnej relacji zaufania. Nie wiem jak, ale potem byłem już w stanie dostać się do ustawień DNSa z poziomu przystawki MMC, ale nadal przy wspomnianych ustawieniach dostaję to:
Dzięki temu możemy zapomnieć o przeniesieniu obiektów z tej domeny. Zobaczmy jeszcze jak wygląda zarządzanie politykami GPO:
Ustawienia kontrolerów domeny w domenie na QNAPie
Ustawienia kontrolerów domeny w domenie na Windowsie Server
Widzicie różnicę? Bo ja tak, nie ma wielu ustawień. Miałem też problem ze stworzeniem nowej polityki, właściwie tego nie byłem w stanie zrobić, ale nie zrobiłem z tego zrzutu ekranu. Trochę poszperałem w Internecie i znalazłem instrukcje do konfiguracji DNSa w Sambie: https://lists.samba.org/archive/samba/2018-December/219978.html Ponadto tutaj jest więcej informacji na temat konfiguracji DNS w Sambie: https://wiki.samba.org/index.php/DNS_Administration
Konkluzja
Nie jestem magikiem od AD póki co, ale to mi śmierdzi – sporo rzeczy, które działa normalnie w Windowsowym AD DS albo wymaga kombinacji jak niczym Justyna Kowalczyk w biathlonie, lecz przed komputerem i niektóre rzeczy po prostu nie działają tak, jak powinny. Czy pocenie się przed kolejnym wyzwaniem stawianym przez to, że Samba nie jest standardowym serwerem AD jest warte świeczki i pieniędzy, które można przeznaczyć na Windowsa Server? Moim zdaniem nie.
Ładny PowerShell w Windowsie i ładny zsh w Linuksie. O tak!
Wbrew pozorom nie trzeba wiele, by zacząć lubić korzystanie z shella. Kilka prostych czynności może sprawić, że możemy wykonywać zadania szybciej, bo często zamiast wyklikać parę okienek możemy wykonać 1 polecenie, które za wszystko załatwia sprawę, lecz decydujemy się na te okienka, bo w końcu już kiedyś to klikaliśmy, to może w trakcie się jakoś przypomni jak to się robiło…nie?
Zmiany, o których będę pisał niżej sprawią, że to, co widzimy w terminalu będzie też przyjaźniejsze dla oka. Niestety, czasami niektóre czynności czy dobór kolorów w tych oknach jest kiepski i to może sprawiać taki odpychający efekt od terminali. Niezależnie czy to jest Windows czy Linux.
Windows + PowerShell + oh-my-posh + PSReadLine = ❤
Tak, Windows też potrafi zaskoczyć obsługą terminala przez PowerShell. W sumie to piszę tego posta, bo właśnie zaskoczył mnie. Od lat korzystam z dobroci zsh i nie miałem okazji mieć takich pozytywnych wrażeń w Windowsie, aż do teraz.
Zacznijmy od Chocolatey – to jest darmowe otwarto-źródłowe narzędzie, które jest menedżerem pakietów dla Windowsa. Działa ono tak samo jak menedżery pakietów w Linuksie, a ich założenie jest proste, na przykład menedżer apt (występuje w Ubuntu, Debianie i pochodnych) instaluje pakiet poprzez polecenie apt install gparted (instaluje program GParted). W Chocolatey instaluje się programy tak samo, na przykład Notepad++ instaluje się poleceniem choco install notepadplusplus.
Instalacja jest prosta – wykonaj te polecenie w Windows PowerShell z uprawnieniami administratora:
I voilà – mamy zainstalowane Chocolatey. Zainstalujmy więc tego Notepada++ w ten sposób, co opisałem powyżej:
choco install notepadplusplus
Na dobrą sprawę to musiałem tylko kilka razy zatwierdzić i gotowe:
Sprawmy, by ten shell wyglądał trochę lepiej. Zainstalujemy do tego conemu i oh-my-posh, który jest odpowiednikiem oh-my-zsh z Linuksa wraz z najnowszą wersją Powershella:
choco install conemu oh-my-posh pwsh
Teraz możesz wykonać polecenie Set-Prompt i masz możliwość korzystania z oh-my-posh. Jeśli polecenie się nie wykonało, najprawdopodobniej nie masz zdefiniowanej polityki względem wykonywania skryptów powershellowych (Get-ExecutionPolicy daje wynik Undefined). Zmień tą politykę na Unrestricted poleceniem Set-ExecutionPolicy Unrestricted. Dzięki temu polityka zmieni się jedynie dla komputera z którego jest wykonywane te polecenie:
Moduł posh-git wymaga zainstalowanego gita, warto go zainstalować poleceniem choco install git:
C:\Users\Administrator> choco install git
Chocolatey v0.10.15
Installing the following packages:
git
By installing you accept licenses for the packages.
Progress: Downloading git.install 2.25.1... 100%
Progress: Downloading git 2.25.1... 100%
git.install v2.25.1 [Approved]
git.install package files install completed. Performing other installation steps.
The package git.install wants to run 'chocolateyInstall.ps1'.
Note: If you don't run this script, the installation will fail.
Note: To confirm automatically next time, use '-y' or consider:
choco feature enable -n allowGlobalConfirmation
Do you want to run the script?([Y]es/[A]ll - yes to all/[N]o/[P]rint): a
Using Git LFS
Installing 64-bit git.install...
git.install has been installed.
git.install installed to 'C:\Program Files\Git'
git.install can be automatically uninstalled.
Environment Vars (like PATH) have changed. Close/reopen your shell to
see the changes (or in powershell/cmd.exe just type `refreshenv`).
The install of git.install was successful.
Software installed to 'C:\Program Files\Git\'
git v2.25.1 [Approved]
git package files install completed. Performing other installation steps.
The install of git was successful.
Software install location not explicitly set, could be in package or
default install location if installer.
Chocolatey installed 2/2 packages.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Teraz zaimportujmy sobie polecenia z tych modułów, które zainstalowaliśmy i odpalmy w końcu nasz nowy shell:
Trochę to odbiega od tego, co widać na moim początkowym zrzucie ekranu, więc popracujemy nad tym, by wyglądem się to nie różniło. Na początku musimy zainstalować czcionki Nerd Font. Znajdziemy je w tym ogromnym repozytorium czcionek. Czcionki Nerd Font różnią się od swoich oryginalnych odpowiedników tym, że mają dodanych kilka znaków, które sprawiają, że ten schemat (nazywający się Agnoster) wygląda lepiej. Ja osobiście bardzo lubię czcionkę Ubuntu Mono w terminalu i z niej też skorzystam. Jeśli podoba Ci się wygląd terminala jak w screenshocie nagłówkowym, zrób to samo co ja (opisałem poniżej):
Wejdź na tą podstronę repozytorium, otwórz folder Regular, następnie complete, i pobierz czcionkę Ubuntu Mono Nerd Font Complete Windows Compatible.ttf. Powtórz to dla folderów Regular-Italic, Bold i Bold-Italic. Jak pobierzesz wszystkie, zaznacz czcionki, kliknij na jedną PPM i wybierz Zainstaluj dla wszystkich użytkowników.
Update 2024: te czcionki można zainstalować za pomocą:
Następnie w oknie Windows PowerShell klikamy na pole tytułowe PPM i Właściwości. W zakładce Czcionka wybieramy naszą nową czcionkę i rozmiar. W moim przypadku to jest UbuntuMono NF z rozmiarem 16.
W ten sposób shell już wygląda lepiej:
Nadal, on może wyglądać lepiej. Zmienimy nieco kolorystykę tego okna, bo jednak ten niebieski trochę razi w oczy. Jeden z najpopularniejszych tematów znalazłem tutaj, w tym repozytorium. My skorzystamy z tematu Solarized-Dark. Instalacja jest prosta: na samym początku klonujemy repozytorium (przed pójściem dalej zrestartowałem terminal, bo nie miał świadomości tego, że ja już zainstalowałem gita):
Okej, teraz otwórz PowerShella jeszcze raz. Voilà, kolory zmienione! Ale nie ma tego nowego wyglądu shella, dlaczego? Dlatego, bo nie zdefiniowaliśmy go w profilu shella. Profil shella to nic innego jak prosty skrypt, który wykonuje się, gdy otwieramy terminal. Zanim zapiszemy sobie do niego to, co potrzebujemy to chciałem pokazać jeszcze jedną rzecz, która moim zdaniem jest niezbędna.
W terminalu niesamowicie istotną rzeczą jest autouzupełnianie składni polecenia. Robi się to naciskając tabulator (przycisk Tab). Naciśnięcie powoduje autouzupełnienie polecenia jeśli, następne naciśnięcia zmienią nasze polecenie na następną opcję, np. jeśli jest polecenie Restart- i my wciśniemy tabulator to za pierwszym razem otrzymamy pierwszą propozycję uzupełnionego polecenia, za drugiem drugą opcję (jeśli istnieje) i tak dalej. Problem w tym, że w jednym czasie widzisz tylko 1 polecenie, bo to jest domyślne ustawienie w PowerShella. Wygodniej by było widzieć opcje i nawet sterować strzałkami, by wybrać interesujące dla nas rozwiązanie. Mało tego, jeszcze lepiej będzie jeśli od razu przy tym wszystkim będziemy mieli drobną podpowiedź jakie np. parametry są dostępne w danym poleceniu czy też jakie wartości oczekują dane parametry. Naszym remedium jest te polecenie:
Dzięki temu teraz już od razu uruchamia się nam ten nowy wygląd shella:
Zmienialiśmy czcionki w oknie PowerShella, ale powinniśmy je też zmienić w Wierszu polecenia. Klikamy prawym na tytuł okna, następnie Właściwości.
Następnie podobnie jak poprzednio w zakładce Czcionka zmieniamy czcionkę na tą, którą wybraliśmy z serii Nerd Font (w moim przypadku to UbuntuMono NF) i dajemy okej. W ten sposób możemy się cieszyć ładnym wyglądem terminala w Windowsie. Te zmiany dotyczą głównie wyglądu, ale myślę, że najważniejszym przy nauce jakiegokolwiek terminala jest nauka obsługi skrótów klawiaturowych. To one sprawiają, że piszemy w nim coraz szybciej dzięki czemu nasza efektywność rośnie.
Na koniec zostawię Wam w postaci zajawki ciekawy wykład na temat szybkiej obsługi PowerShella z użyciem PSReadLine, naprawdę mi się bardzo podobał:
Linux + zsh + oh-my-zsh = ❤
Co prawda mowa tutaj o Linuksie, ale nie każdego Linuksa obsługuje się z poziomu Linuksa – w końcu serwery często nie mają zainstalowanego interfejsu graficznego i obsługuje się je poprzez SSH (secure shell). Tam też warto sprawić, by pracowało nam się z nim wygodnie.
Domyślnym interpreterem poleceń w Linuksie w dzisiejszych czasach jest Bash (/bin/bash), a w tych starszych lub w okrojonych dystrybucjach sh (/bin/sh). Mają one pewne możliwości, ale też ograniczenia konfiguracyjne, przez co na codzień korzystam z zsh (/bin/zsh). Nie jest on w standardzie w systemach (przynajmniej nie spotkałem się z dystrybucją mającą ją jako domyślny shell, choć jest on dostępny w MacOS (na ten moment korzystałem tylko z 10.15 i tam był). Pokażę tutaj jak zainstalować zsh oraz w jaki sposób można z niego zrobić fajny użytek.
UWAGA: instrukcje poniżej są ogólne dla wszystkich dystrybucji Linuksa, ale są polecenia, które są specyficzne dla dystrybucji (np. w Debianie/Ubuntu menedżerem pakietów jest apt/apt-get, w Arch Linuksie jest pacman, w Red Hat/CentOS/Fedora yum/dnf, a w Gentoo…w sumie to, co chcesz, ale przeważnie Portage (polecenie emerge). Weź pod uwagę też to, że nazwy pakietów w repozytoriach mogą się różnić.
Zaczynamy od instalacji gita, zsh i podkreślania składni zsh
Okej, teraz odpalmy one-liner, którym zainstalujemy zsh:
sh -c "$(wget -O- https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
Następnie musimy zatwierdzić zmianę shella na zsh i jesteśmy w domu.
--2020-03-15 11:47:42-- https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh
Translacja raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.0.133, 151.101.192.133, 151.101.128.133, ...
Łączenie się z raw.githubusercontent.com (raw.githubusercontent.com)|151.101.0.133|:443... połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 8445 (8,2K) [text/plain]
Zapis do: `STDOUT'
- 100%[===================>] 8,25K --.-KB/s w 0s
2020-03-15 11:47:42 (215 MB/s) - zapisano na standardowe wyjście [8445/8445]
Cloning Oh My Zsh...
Cloning into '/home/supra/.oh-my-zsh'...
remote: Enumerating objects: 1137, done.
remote: Counting objects: 100% (1137/1137), done.
remote: Compressing objects: 100% (1102/1102), done.
remote: Total 1137 (delta 22), reused 926 (delta 17), pack-reused 0
Receiving objects: 100% (1137/1137), 750.06 KiB | 2.13 MiB/s, done.
Resolving deltas: 100% (22/22), done.
Looking for an existing zsh config...
Using the Oh My Zsh template file and adding it to ~/.zshrc.
Time to change your default shell to zsh:
Do you want to change your default shell to zsh? [Y/n] y
Changing the shell...
Hasło:
Shell successfully changed to '/usr/bin/zsh'.
__ __
____ / /_ ____ ___ __ __ ____ _____/ /_
/ __ \/ __ \ / __ `__ \/ / / / /_ / / ___/ __ \
/ /_/ / / / / / / / / / / /_/ / / /_(__ ) / / /
\____/_/ /_/ /_/ /_/ /_/\__, / /___/____/_/ /_/
/____/ ....is now installed!
Please look over the ~/.zshrc file to select plugins, themes, and options.
p.s. Follow us on https://twitter.com/ohmyzsh
p.p.s. Get stickers, shirts, and coffee mugs at https://shop.planetargon.com/collections/oh-my-zsh
➜ ~
Tak czy siak ten shell jeszcze wymaga drobnych poprawek (przynajmniej w moim przekonaniu). Dodałbym lub zmieniłbym następujące linijki:
export TERM=xterm-256color
Dzięki temu możemy wykorzystywać więcej kolorów (256 zamiast 8), gdy korzystamy z SSH. Naprawdę bardzo przydatne, przynajmniej ja dzięki temu mam ładnego Vima, a o tym później. Tej linijki nie ma, musimy ją dodać.
ZSH_THEME="agnoster"
W tym polu definiujemy styl terminala, czyli jak on wygląda. Możemy korzystać z motywów, które są w oh-my-zsh, możemy ściągać niestandardowe, a możemy też tworzyć własne.
Niżej mamy też sekcję pluginów, w której możemy po prostu wzbogacić nasz shell o dodatkowe polecenia (ja dodałem polecenia do systemd, ufw i dockera, bo od pewnego czasu z niego korzystam):
Dzięki temu shell zmienia kolor poleceń na czerwono, gdy są nieprawidłowe i usuwa podkreślenia ze ścieżek, gdy są nieprawidłowe:
Ponadto dodałbym to:
blk=$'\x1b[90m' # Sets text to black
red=$'\x1b[31m' # Sets text to red
grn=$'\x1b[92m' # Sets text to green
ylw=$'\x1b[93m' # Sets text to yellow
blu=$'\x1b[94m' # Sets text to blue
pur=$'\x1b[95m' # Sets text to purple
cyn=$'\x1b[96m' # Sets text to cyan
wht=$'\x1b[97m' # Sets text to white
rst=$'\x1b[0m' # resets to default terminal color
bindkey "\033[1~" beginning-of-line
bindkey "\033[4~" end-of-line
export EDITOR="/usr/bin/vim"
Te polecenia ustawiają kolor shella w terminalu graficznym (czyli pracując w trybie bez interfejsu graficznego bezpośrednio na maszynie), poza tym te polecenia bindkey są fixem na niedziałające przyciski Home/End w niektórych środowiskach. Na koniec dodałem zmienną EDITOR i wartością jest ścieżka do Vima, bo to jest edytor tekstu, z którego korzystam najczęściej. Poza tym możemy też ustawić na koncie root wykorzystywanie zsh wykonując polecenia:
Poprawa wyglądu terminala w interfejsie graficznym Linuksa
W efekcie końcowym nasz shell wygląda tak:
Niezbyt fajnie. By to poprawić musimy tak samo jak w Windowsie zainstalować odpowiednie czcionki. Możemy posłużyć się czcionkami, które też tam wykorzystaliśmy, czyli z repozytorium Nerd Font. Tak samo jak poprzednio posłużę się czcionkami dla Ubuntu Mono:
Sprawdźmy, czy czcionki się pojawiły w naszym systemie dzięki poleceniu fc-list | grep "Nerd":
/home/supra/.local/share/fonts/Ubuntu Mono Bold Italic Nerd Font Complete.ttf: UbuntuMono Nerd Font:style=Bold Italic
/home/supra/.local/share/fonts/Ubuntu Mono Bold Nerd Font Complete.ttf: UbuntuMono Nerd Font:style=Bold
/home/supra/.local/share/fonts/Ubuntu Mono Nerd Font Complete.ttf: UbuntuMono Nerd Font:style=Regular
/home/supra/.local/share/fonts/Ubuntu Mono Italic Nerd Font Complete.ttf.1: UbuntuMono Nerd Font:style=Italic
/home/supra/.local/share/fonts/Ubuntu Mono Bold Italic Nerd Font Complete.ttf.1: UbuntuMono Nerd Font:style=Bold Italic
/home/supra/.local/share/fonts/Ubuntu Mono Italic Nerd Font Complete.ttf: UbuntuMono Nerd Font:style=Italic
/home/supra/.local/share/fonts/Ubuntu Mono Nerd Font Complete.ttf.1: UbuntuMono Nerd Font:style=Regular
Jak widać jest wszystko okej, dlatego zmieńmy sobie czcionkę na nową w taki sposób, jak przedstawiłem na animacji:
Pozostają jedynie te kiepskie kolory. Te możemy zmienić za pomocą gotowych plików, które możemy znaleźć na tym blogu. Z faktu, że w różnych środowiskach graficznych są różne programy pełniące rolę emulatora terminala (w moim ulubionym Xfce4 jest to xfce4-terminal), metoda na zmianę jest inna i pokażę jak to się robi w Xfce. Skorzystamy z tematu Solarized Dark, jak w przykładzie z PowerShellem.
Następnie musimy w ustawieniach wybrać ten motyw i to tyle. Ja dodatkowo zmieniam sobie kolor zielonego na trochę bardziej przypominający zielony, bo tak po prostu lubię.
Poprawa wyglądu terminala w konsoli tekstowej Linuksa
Zsh działa per konto użytkownika, co oznacza, że będzie nam działać niezależnie czy połączymy się przez emulator terminala, fizyczny terminal czy SSH, lecz z drugiej strony my w motywie wykorzystujemy czcionki z niestandardowymi znakami, dlatego też pokażę Wam jak skorzystać z tych czcionek w terminalu i jak sprawić, by działały one z automatu.
Na początku musimy pobrać czcionki, które nas interesują. Ja korzystam z pogrubionych czcionek Terminus, bo po prostu takie mi się podobają. Możemy je też znaleźć w repozytorium Powerline. Warto zaznaczyć, że te czcionki muszą być w formacie .psf, a nie .ttf. Możemy pobrać i umieścić wszystkie czcionki za pomocą jednego prostego skryptu:
Teraz musimy wybrać czcionkę, która nam się podoba bardziej. Nic bardziej prostego, robimy to poleceniem setfont /usr/share/consolefonts/<nazwa-pliku>, na przykład:
W ten sposób pojawi nam się nowa czcionka (przy okazji tutaj pokazuję jak można łatwo uzupełniać opcję tabulatorem w terminalu, gdy ma się zsh):
Na samym końcu sprawimy, że taka czcionka będzie na każdym terminalu w naszym komputerze i to będzie się działo automatycznie po restartach. Musimy edytować plik /etc/default/console-setup, zmieniamy tutaj wartości pól CODESET, FONTFACE i FONTSIZE. Ogólnie pliki czcionek są wczytywane w składni pliku <CODESET>-<FONTFACE><FONTSIZE>.psf.gz, dlatego też w <FONTFACE> na końcu lub w <FONTSIZE> na początku trzeba dopisać myślnik. Poniżej uzupełniłem plik względem pliku czcionki, który wykorzystywałem powyżej.
# CONFIGURATION FILE FOR SETUPCON
# Consult the console-setup(5) manual page.
ACTIVE_CONSOLES="/dev/tty[1-6]"
CHARMAP="UTF-8"
CODESET="ter"
FONTFACE="powerline-"
FONTSIZE="v16b"
VIDEOMODE=
# The following is an example how to use a braille font
# FONT='lat9w-08.psf.gz brl-8x8.psf'
Po zmienieniu tego pliku można sprawdzić efekt wykonując polecenie setupcon. Jeśli czcionka się zmieniła poprawnie to po restarcie też się zmieni. Tutaj też chciałbym podziękować Tenebreosowi za znalezienie ominięcia problemu w poleceniu setupcon w nazwach plików, naprawdę to się przydało!
Poprawa wyglądu terminala w SSH
Na koniec część dla tych, którzy administrują serwerami Linuksa zdalnie, przez SSH. Pewnie większość z Was korzysta z PuTTY. Ja akurat korzystam z trochę bardziej wypasionej wersji, która nazywa się KiTTY i można ją pobrać tutaj.
Zaczniemy od zmiany kolorów terminala. Docelowo ma wyglądać jak te wszystkie poprzednie oraz będzie korzystał z tej samej czcionki (Ubuntu Font NF), co w sekcji z ustawianiem czcionek dla PowerShella. Zamiast wyklikiwać w opcjach wszystkie kolory, możemy zastosować ten jeden pliczek, który za nas zrobi całą robotę, poniżej zawartość:
Poza tym warto zmienić w profilu domyślnym czcionkę, więc otwierając ustawienia w sekcji Window > Appearance, w sekcji Font settings klikamy przycisk Change… i wybieramy czcionkę, którą chcemy ustawić. Na zrzucie poniżej macie jak to wygląda u mnie:
Następnie musimy taką zmianę zapisać, najlepiej to zrobić w domyślny profilu (Sekcja Session), klikamy nazwę sesji i przycisk Save:
Gotowe. W ten sposób mamy shell przygotowany do pracy:
Jeśli administrujecie domeną Active Directory w waszych organizacjach, pewnie wiecie, że czasami trzeba instalować różne programy pracownikom. Z faktu, że informatyk to leniwy zawód to by utrzymać swój stan warto spróbować instalować programy zdalnie. Dzięki temu nie musimy biegać po komputerach, by zainstalować jeden program. Jeden program, a co jeśli komputerów trzeba ogarnąć sporo?
W sumie to warto się zastanowić co się najczęściej instaluje na komputerze:
Przeglądarka internetowa (Chrome/Firefox),
Pakiet Office (MS Office/LibreOffice),
W niektórych firmach Adobe Reader/Foxit Reader,
7-Zip,
Program antywirusowy (w moim przypadku ESET Security),
Klient VPN (jeśli firma daje możliwość np. home-office),
Program do robienia kopii zapasowych komputera (w moim przypadku StorageCraft ShadowProtect),
Java Runtime Kit (niektóre aplikacje tego wymagają),
Z przydatnych, lecz niekoniecznie niezbędnych:
Everything (szybkie wyszukiwanie plików),
Klient chmurowy (w moim przypadku Nextcloud i OneDrive),
Narzędzie do robienia screenshotów (w moim przypadku Greenshot),
Menedżer haseł (w moim przypadku KeepassXC),
Programy potrzebne do konkretnego rodzaju pracy, np. księgowość będzie korzystała z programów pokroju Płatnika czy jakiegoś programu ERP typu Comarch Optima, Macrologic itd., administratorzy będą raczej mieli VirtualBoxa, VMware Workstation, Visual Studio Code/Notepad++, programiści mieliby np. Visual Studio, IntelliJ i tak mógłbym wymieniać be z końca.
Jak widać, robi się z tego dosyć pokaźna lista i pewnie gdyby trzeba było to zainstalować na komputerze pracownika ręcznie – możesz zapomnieć o godzinie w pracy co najmniej, a pracowników do obsłużenia czasami może być kilkadziesiąt czy kilkaset, więc prostszym rozwiązaniem jest skorzystanie z GPO (Group Policy Object).
Myślę, że warto to podzielić na dwa etapy – szybka organizacja użytkowników i komputerów w AD i stworzenie polityk GPO. GPM (Group Policy Management) pozwala nam ustawić dowolne ustawienie dotyczące działania systemu Windows jak i niektórych programów względem konkretnych komputerów czy użytkowników poprzez zarządzanie obiektami (tzw. GPO).
Inaczej mówiąc, dzięki temu możemy ustawić dla użytkownika, że na przykład ma mieć z góry ustawioną tapetę z logiem naszej firmy i nie może jej zmieniać czy np. to, że nie może korzystać ze sklepu Microsoft Store w celu instalowania dodatkowych aplikacji.
Dla komputera możemy zaś ustawić np. to, że nie wymagamy modułu TPM do szyfrowania komputerów BitLockerem, polityki firewalla w Windows Defender. Są rzeczy, które pojawiają się zarówno w części dla komputera jak i użytkownika jak na przykład instalowanie programów, ale tutaj raczej się skupię nad samym wykorzystaniem funkcjonalności w praktyce niż opisaniem co to jest.
Organizacja użytkowników i komputerów w AD
To jest prostsze, niż nam się wydaje, bo bardziej chodzi tutaj o poukładanie komputerów i użytkowników w odpowiednim schemacie drzewka. Tworzy się je w przystawce Użytkownicy i komputery usługi Active Directory. Myślę, że najsensowniejsze jest to rozwiązanie poniżej (jeśli są propozycje na lepsze to zachęcam do zostawienia komentarzy). Podzieliłem je tak dlatego, bo wdrażałbym osobno polityki dla użytkowników (np. ustawienia dotyczące montowania zasobów sieciowych automatycznie) byłyby per danych dział lub były wspólne (podpinam je do drzewka poziom wyżej, np. ustawienie wspólnego udziału sieciowego dla całej firmy byłoby podpięte do obiektu Użytkownicy, bo dotyczy wszystkich użytkowników w firmie).
Z drugiej strony chcę móc wybierać jak mają być skonfigurowane osobno komputery i osobno laptopy (np. chcę szyfrować wszystkie laptopy i nie szyfruję stacjonarek). Poza tym chcę, by konkretne programy były zainstalowane w konkretnych działach (np. ERP Optima w księgowości, VMware Workstation w IT), ale na przykład Chrome i Firefox powinny być zainstalowane u wszystkich bez względu na to, czy pracują na laptopach czy stacjonarkach.
Po co to wszystko? Po to, by móc konkretnie ustawić daną grupę komputerów, dzięki czemu czynności, które musimy wykonać po to, by ustawić wszystkie komputer są automatyzowane, czyli zamiast robić coś 10 razy zrobimy to raz by przetestować czy dobrze działa, a potem wskażemy daną grupę (np. dział IT) i niech się ten VMware Workstation instaluje na wszystkich komputerach od IT.
Następnie miejsce, gdzie ustawiamy polityki GPO jest tutaj, w przystawce Zarządzanie zasadami grupy.
Tworzenie polityk GPO i przypisywanie ich do grup
W tworzeniu konfiguracji założenie jest następujące:
tworzymy obiekty, które są szablonami konfiguracji komputerów lub/i użytkowników (przy czym warto im dać jakąś nazwę, która będzie mówiła nam jasno co ten szablon robi bez głębszego zerkania w szczegóły, np. browser install),
definiujemy jakie ustawienia chcemy mieć w konkretnym szablonie, na przykład instalację pakietu oprogramowania Google Chrome i Mozilla Firefox (by użytkownicy mieli jakiś wybór) czy automatycznie dodanie udziału sieciowego //fileserver/share,
przypisujemy taki obiekt do konkretnej jednostki organizacyjnej (OU – organisational unit), dzięki czemu definiujemy, że szablon instalacji Google Chrome i Mozilla Firefox ma być wdrożony na wszystkich komputerach w organizacji (przypinając obiekt do OU Firma/Komputery).
tworzymy obiekty, które są szablonami konfiguracji komputerów i użytkowników.
W przypadku zwykłych ustawień to jest kwestia wyklikania w szablonie tego, co chcemy, a potem przeciągnięcia szablonu do OU w ten sposób:
Przypisanie obiektu zasad grupy do konkretnego OU
Z faktu, że tutaj jest mowa o pakietach instalacyjnych, najpierw musimy te pakiety umieścić w miejscu, gdzie te komputery, na których wdrażamy programy będą mogły je wdrożyć. Po prostu trzeba zrobić udział sieciowy. Stwórz folder na przykład w C:\, ja akurat go nazwałem gpo. Następnie udostępnij ten folder poprzez przejście do zakładki Udostępnianie, wybierz poniżej Udostępnianie zaawansowane…, kliknij na górze okna Udostępnij ten folder, kliknij w Uprawnienia i upewnij się, że grupa Wszyscy ma dostęp tylko do odczytu. Dzięki temu nikt nam nic nie zmieni w tym katalogu.
Udostępnianie folderu jako zasób sieciowy, w tym przypadku UNC to \\ad-2019.domena.local\gpo
Poza tym przydaloby się dać dostęp komputerom do tych plików. Wybieramy zakładkę Zabezpieczenia i dodajemy dostęp do odczytu i wykonanie (domyślne ustawienie) grupie Użytkownicy uwierzytelnieni.
Okej, jak już mamy ten udział to umieśćmy pliki instalacyjne w nim. W moim przypadku będziemy instalować 7-Zipa i StorageCraft ShadowProtect SPX. Instalatory muszą być pakietami MSI, by dało się je zainstalować. Stworzymy dla nich 3 osobne polityki GPO. Aby stworzyć jedną, trzeba kliknąć Obiekty zasad grupy > Nowe, następnie podaj nazwę nowego obiektu i OK. W moim przykładzie nazwałem obiekt 7zip.
Następnie klikamy prawym na nowoutworzony obiekt i wybieramy Edytuj…, następnie otworzy nam się okno, w którym definiujemy szablon. W nim przechodzimy do Konfiguracja komputera > Zasady > Ustawienia oprogramowania > Instalacja oprogramowania i po prawej stronie klikamy PPM, następnie wybieramy Nowy > Pakiet….
Wybieramy z listy instalator 7-Zipa (mamy 2, więc proces musimy wykonać 2 razy dla systemów 32 i 64-bitowych), następnie musimy wybrać metodę rozmieszczenia oprogramowania. Przypisany – po prostu z domyślnymi ustawieniami ma się zainstalować. Założenie jest takie, że pakiet, który przypisujesz powinien się zgadzać językiem z systemem, na którym ma być zainstalowany i czasami po zostawieniu pakietu w taki sposób instalacja się w ogóle nie wykonuje, dlatego wybieram opcję Zaawansowane.
Otworzy nam się okienko z właściwościami tego instalatora. Dzięki niemu możemy zobaczyć na jaką platformę jest przygotowany program, jaki język jest domyślnym językiem programu i to mamy w zakładce Ogólne. To, co na ten moment nas interesuje to zakładka Rozmieszczanie.
Klikamy tutaj Zaawansowane…
Następnie zaznaczamy opcje Ignoruj język w czasie rozmieszczania tego pakietu i Udostępnij tę 32-bitową aplikację X86 komputerom Win64. Dzięki temu ta aplikacja zainstaluje się tylko na komputerach z systemem 32-bitowym bez względu na język systemu operacyjnego. Po tym można dać OK 2 razy i w ten sposób dodaliśmy pakiet instalacyjny dla 32-bitowej wersji 7-Zipa, teraz musimy to samo zrobić dla 64-bitowej wersji. Jedyna różnica tutaj będzie taka, że nie ma w Zaawansowane opcje rozmieszczania opcji Udostępnij tę 32-bitową aplikację X86 komputerom Win64, bo w końcu da się ją zainstalować tylko na 64-bitowych procesorach.
Po wszystkim szablon powinien wyglądać tak:
Jeśli klikniemy w oknie Zarządzanie zasadami grupy na nasz nowy obiekt i przejdziemy u góry do zakładki Ustawienia, będziemy mogli zobaczyć jak wyglądają wszystkie ustawienia zdefiniowane w tym szablonie. Po tym możemy przeciągnąć szablon do OU, tak jak na animacji wyżej i to tyle. W ten sposób mamy wdrożoną politykę GPO.
Drobna uwaga – warto mieć maszyny wirtualne na których możemy sobie testować takie polityki przed wdrożeniem ich produkcyjnie, na przykład jeśli mamy w organizacji pracowników pracujących na Windowsie 10 i Windowsie 8.1 to dobrze jest mieć wirtualki z takimi systemami – dzięki temu jesteśmy w stanie zobaczyć jak przejdzie proces instalacji na takich maszynach dzięki czemu unikniemy potencjalnych nieprzyjemnych niespodzianek na produkcyjnym sprzęcie.
Pakiety transformacji i wykorzystywanie Orca
Czasami niektóre pakiety MSI wymagają dodatkowych parametrów, by zadziałały. Skorzystam z przykładu programu StorageCraft ShadowProtect SPX. We wdrożeniach GPO wymaga on, by podać parametr IACCEPT=STORAGECRAFTEULA. W tej sytuacji rozwiązaniem jest stworzenie pakietu transformacji i dodanie go to pakietu instalacyjnego w momencie dodawania go do szablonu GPO.
Takie pakiety transformacji tworzy się w programie Orca. Jest on dostarczany w postaci instalatora razem z Windows ADK (Assessment and Deploment Kit). W moim przypadku był w katalogu C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86\Orca-x86_en-us.msi. W tym instalatorze na dobrą sprawę musimy go przeklikać dalej, dalej, dalej i mamy go na zainstalowanego. Następnie otwieramy go, wybieramy u góry w lewym rogu File > Open i wybieramy instalator, który nas interesuje.
Wedle wskazania w dokumentacji powinniśmy taki parametr podać w sekcji Property (wybieramy z listy po prawej stronie), potem w górnym panelu wybieramy Transform > New Transform.
Wybieramy teraz w Tables > Add Row… i tutaj dodajemy dane klikając w pole Property i wpisując IACCEPT, następnie klikamy pole Value i wpisujemy STORAGECRAFT.EULA. Po tym klikamy OK.
Zobaczymy po tym, że nowe pole jest obramowane na zielono. W ten sposób możemy zapisać nasz plik transformacji poprzez Transform > Generate Transform… i zapisując plik.
Tutaj widzimy wspomniane zielone obramowanie.
Mając to przy dodawaniu pakietu wybieramy kartę Modyfikację, klikamy przycisk Dodaj… i wskazujemy plik transformacji, przy czym nie zapomnijmy go umieścić na wcześniej utworzonym udziale sieciowym.
Zmiany można też zamieszczać wewnątrz pakietów MSI, dzięki czemu nie trzeba korzystać z pakietów transformacji, po prostu należy zapisać zmiany jako pakiet MSI:
Wdrażanie polityk GPO w życie
Nowa polityka wchodzi w życie w ciągu 90 minut + maksymalnie 30 minut. Jest to zrobione po to, by w przypadku dużych środowisk polityki były bez problemu wysłane i zastosowane na wszystkich wskazanych stanowiskach. Możemy ten proces przyspieszyć wykonując polecenie gpupdate /force na stanowiskach, gdzie taka polityka powinna być zaaktualizowana. W przypadku pakietów instalacyjnych jest potrzebny restart systemu, więc do polecenia dodajemy parametr /boot, czyli gpupdate /force /boot. Od Windowsa Server 2012 możemy takie wymuszenia wykonywać zdalnie (z samej przystawki i poprzez Windows PowerShell).
Zanim będziemy takie aktualizacje wykonywać zdalnie powinniśmy wdrożyć jedną politykę GPO odblokowującą porty w firewallu, bo domyślnie są zablokowane i otrzymamy błędy przy wykonaniu. Do tego trzeba stworzyć politykę, która odblokowuje ruch przychodzący, gdzie na dobrą sprawę możemy skopiować polityki bezpośrednio z lokalnych ustawień Zapory Windows Defender z zabezpieczeniami zaawansowanymi, a nazwy reguł, które musimy mieć to:
Instrumentacja zarządzania Windows (ruch przychodzący ASync),
Instrumentacja zarządzania Windows (ruch przychodzący DCOM),
Instrumentacja zarządzania Windows (ruch przychodzący WMI),
Część z reguł jest domyślnie wyłączona; należy na nie kliknąć prawym i wybrać Włącz regułę. Te ustawienia znajdują się w Konfiguracja komputera > Zasady > Ustawienia systemu Windows > Ustawienia zabezpieczeń > Zapora Windows Defender z zabezpieczeniami zaawansowanymi > Zapora Windows Defender z zabezpieczeniami zaawansowanymi – LDAP://CN={UUIDBARDZODLUGI},CN=POLICIES,CN=SYSTEM,DC=DOMENA,DC=LOCAL > Reguły przychodzące.
Wymuszenie takiej aktualizacji poprzez Zarządzanie zasadami grupy wygląda tak, że klikamy PPM na OU, w którym chcemy wykonać aktualizację polityk GPO, a następnie wybieramy Aktualizacja zasad grupy….
Następnie zostaniem spytani czy na pewno chcemy to zrobić, od razu widzimy ile komputerów otrzyma aktualizację. Klikamy Tak.
W efekcie widzimy też na jakich hostach taki proces się udał, a na jakich nie. W moim przypadku wszystko się udało.
Po restarcie jednego z desktopów widzimy efekt (w międzyczasie też dodałem na komputerze Google Chrome):
Drugą metodą na aktualizację polityk są polecenia (tzw. cmdlety (command-lety)) w Windows PowerShell. Odpowiednikiem polecenia gpupdate /force w PowerShell jest Invoke-GPUpdate, lecz te polecenie da się wykonać tylko z Windowsów Server. Tutaj mamy większe możliwości, bo możemy wskazywać nawet z jakim opóźnieniem ma być wykonywana aktualizacja. Same polecenie uruchomi aktualizację polityk GPO na maszynie, z której te polecenie jest wykonywane, więc warto wskazać komputery na których chcemy taką aktualizację przeprowadzić. Dam tutaj bardziej rozbudowany przykład polecenia. Dzięki niemu:
wymuszamy aktualizację bez potwierdzenia od strony użytkownika,
restartuje komputer przy wdrożeniu pakietów instalacyjnych,
wskazuje komputer endpoint-3 jako tą, na której ma być wykonana aktualizacja polityk,
wykonanie nastąpi natychmiast, bo określony losowy czas wykonania to 0.
Rozbudujmy to trochę bardziej – wskażmy wszystkie komputery z danego OU do aktualizacji.
W moim przypadku chcę zaaktualizować wszystkie komputery będące w OU Komputery będącym w OU FIRMA. Biorąc pod uwagę, że nazwa mojej domeny to domena.local, polecenie wygląda następująco:
W parametrze -SearchBase polecenia Get-ADComputer musimy określić Distinguised Name (jak bym miał to przetłumaczyć to byłoby to „wyróżniająca się nazwa”, choć słyszałem tłumaczenia nazwa dystyngowana, zbierało mi się na wymioty). To można znaleźć na dwa sposoby:
Pierwszą jest znalezienie DNa dla konkretnego OU. Możemy to zrobić włączając Opcje zaawansowane w przystawce Użytkownicy i komputery usługi Active Directory. O tutaj:
Następnie klikamy na OU, które nas interesuje PPM > Właściwości.
Wybieramy zakładkę Edytor atrybutów i szukamy pola distinguishedName. Klikamy na dole okna przycisk Wyświetl i kopiujemy zawartość.
Na dobrą sprawę druga metoda to wypisanie sobie schematów drzewka od samego dołu do góry i zapisanie ich w jednej linii oddzielając przecinkami:
OU=Komputery
OU=FIRMA
DC=domena
DC=local
W DN oddzielamy wszystkie segmenty drzewka przecinkami, poza tym wykorzystuje skróty CN (common name) dla nazw użytkownika i grup, OU (organisational unit) dla jednostek organizacyjnych i DC (domain component) dla nazwy domeny. Gdyby domena to było to.jest.testowa.domena.local to kompletna część DC byłaby: DC=to,DC=jest,DC=testowa,DC=domena,DC=local. W tym przypadku powyżej wynik jest widoczny na zrzucie ekranu.
