Notatki ze szkolenia Poznaj bezpieczeństwo Windows 3: Tajniki Group Policy

Group Policy (GP) oraz Group Policy Objects (GPO)

Infrastrukturę, która pozwala na centralne zarządzanie ustawieniami zarówno kont użytkowników, jak i komputerów (głównie w systemach z rodziny Windows) nazywamy Group Policy (GP). W polskojęzycznych opracowaniach możemy się też spotkać z określeniem Zasady Grupy. Jest to mechanizm, który został zaimplementowany wiele lat temu i jest wykorzystywany do dziś.

Mówiąc prościej: zamiast zmieniać i dostosowywać ustawienia w różnych obszarach systemu (głównie rejestru), możemy to zrobić w jednym miejscu, a mechanizmy GP automatycznie je zaaplikują. Jeśli pracujemy w środowisku lokalnym (lokalny komputer i lokalne konto użytkownika), możemy posłużyć się narzędziem Local Group Policy Editor (gpedit.msc). 

Prawdziwa siła GP tkwi jednak w możliwości scentralizowanego zarządzania przez sieć wieloma użytkownikami oraz komputerami, podłączonymi do domeny w ramach Active Directory Domain Services (AD DS). W tym przypadku administracja odbywa się zdalnie, za pośrednictwem Kontrolera Domeny (Domain Controller, DC), czyli serwera zarządzającego daną domeną i podłączonymi do niej systemami.

Do konfigurowania zasad grupy w środowisku AD służy narzędzie GUI o nazwie Group Policy Management Console (gpmc.msc). Konsolka jest domyślnie dostępna w systemie pełniącym rolę kontrolera domeny, ale należy zwrócić tutaj uwagę, że zdalne logowanie się bezpośrednio do systemu Domain Controller jest wbrew dobrym praktykom. Pamiętajmy, że serwer DC jest krytycznym elementem infrastruktury i bezpośredni dostęp z sieci powinien być jak najbardziej ograniczony (wyjątkiem jest dostęp fizyczny do DC, kiedy musimy coś zrobić w systemie bezpośrednio).

Na szczęście wspomniana konsola GPMC jest również dostępna w zestawie narzędzi Remote Server Administration Tools (RSAT), które możemy zainstalować na dedykowanej stacji roboczej (tzw. privileged access workstation) i stąd łączyć się z DC tylko  za pomocą wspomnianej konsoli.

Administratorzy bardzo często używają krótkiego terminu GPO (Group Policy Objects) w odniesieniu do ogółu mechanizmów Group Policy. Pamiętajmy jednak, że jest to umowne uproszczenie, ponieważ technicznie GPO jest elementem GP, a dokładnie jest to wirtualna kolekcja ustawień o unikatowej nazwie (takiej jak GUID).

Zarządzanie GPO

Skoro kwestie nazewnictwa mamy już wyjaśnione, przyjrzyjmy się technicznym aspektom zarządzania obiektami GPO. W dalszej części tego opracowania zakładamy, że pracujemy w środowisku sieciowym z jednym kontrolerem domeny Active Directory i przynajmniej jedną stacją roboczą, będącą częścią tej domeny.

W jednym miejscu określamy poszczególne zasady w postaci GPO, a zdefiniowane w ten sposób ustawienia są wymuszane na wszystkich (tj. objętych przez te GPO) komputerach podłączonych do domeny.

Najpopularniejszym obecnie narzędziem do centralnego zarządzania jest wspomniana wcześniej konsola Group Policy Management Console (gpmc.msc).

Group Policy Management Console 

Narzędzie oferuje UI z drzewkiem, gdzie możemy sprawdzić jakie polityki grupowe (GPO) są lub mogą zostać zaaplikowane do naszej domeny (w przykładzie jest to training.lab).

W każdej domenie mamy dwie domyślne polityki (GUID powinien być dla nich identycznych we wszystkich domenach):

• Default Domain Controllers Policy – polityka (tj. zestaw ustawień) aplikowana na kontrolerach domeny.
• Default Domain Policy – polityka dla całej domeny.

Warto zaznaczyć, że tych dwóch domyślnych obiektów nie można usunąć, a jedynie edytować. Możemy jednak tworzyć własne polityki GPO, które z kolei da się usunąć bez problemu.

Wybrane GPO można edytować, wybierając z menu kontekstowego opcję Edit, co uruchomi wizualny edytor Group Policy Management Editor (GPME) widoczny poniżej:

Group Policy Management Editor

Z tego poziomu możemy już definiować poszczególne ustawienia, które aplikują się do całego systemu (Computer Configuration) bądź do konta wybranego użytkownika (User Configuration).

Każde ustawienie może mieć jedno z trzech stanów:

• Not configured – wybrany element polityki nie został jeszcze skonfigurowany w sposób jawny.
• Enabled – ustawienie jest włączone. Tutaj warto zwracać uwagę na nazwę danego ustawienia, ponieważ jeśli ono czegoś zabrania (np. Disallow installation of printers using kernel-mode drivers) i chcielibyśmy jednak na to zezwolić, musielibyśmy użyć opcji Disabled (podwójna negacja).
• Disabled – ustawienie jest jawnie wyłączone.

Celem szkolenia nie było omówienie technik zarządzania politykami, a pokazanie jak ten mechanizm działa pod spodem. Jednak zanim zajrzymy do bebechów, omówmy sobie kilka podstaw, które pojawiły się na szkoleniu.

Najprostsze podejście do zarządzania politykami GPO powinno opierać się na dobrze przemyślanej strukturze jednostek organizacyjnych OU (Organizational Unit). Powinniśmy sobie rozpisać naszą domenę na odpowiednie jednostki, a następnie zdefiniować dla tych jednostek wymagane polityki.

Załóżmy, że nasza organizacja ma różne oddziały. Możemy utworzyć osobne OU dla każdego oddziału wraz z dedykowanymi politykami. Ustawienia na poziomie całej organizacji można określić w domyślnej polityce Default Domain Policy.

Dostęp do zarządzania poszczególną jednostką OU można nadać administratorowi będącego członkiem danej jednostki. Pamiętajmy jednak, że dostęp do polityk GPO wymaga określonych uprawnień, ale nie ma logowania, kto i co dokładnie zmienił w danym momencie.

Pamiętajmy też, że łatwiej jest zarządzać mniejszą liczbą polityk, które składają się z wielu ustawień, niż wieloma politykami z mniejszą liczbą ustawień.

Kolejna sprawa, na którą warto zwrócić uwagę, to możliwość dodania własnego filtrowania, które decyduje o tym, gdzie i do kogo określona polityka powinna trafić. W ustawieniach pojedynczego GPO (w konsoli GPMC) mamy do wyboru 2 sekcje:

• Security Filtering – pozwala zdecydować, dla jakiej grupy wdrożyć daną politykę (np. Authenticated Users).
• WMI Filtering – w uproszczeniu: pozwala na pisanie skryptów, które decydują o tym, czy wybraną aplikować, czy też nie. Należy przy tym pamiętać, że kiedy używamy takich skryptów, bardzo łatwo jest stracić rozeznanie, które GPO będą aplikowane, a które nie – szczególnie po dłuższym czasie.

Skoro jesteśmy przy filtrowaniu poszczególnych polityk, warto jeszcze wspomnieć o mechanizmie Loopback Processing, który pozwala na załadowanie określonych polityk dla danego komputera, niezależnie od tego, który akurat użytkownik jest zalogowany (mówiąc prościej: nadpisuje ustawienia użytkownika ustawieniami komputera). Jest to przydatne w stacjach roboczych, które mogą mieć wielu różnych użytkowników, np. w urządzeniach terminalowych czy kioskach multimedialnych.

Jeśli chcielibyśmy wykorzystać mechanizmy GPO do zarządzania aplikacjami na stacjach roboczych (instalacja/deinstalacja), możemy posłużyć się skryptami:

GPO Scripts

Podajemy tutaj ścieżkę do skryptu/aplikacji (wraz z ewentualnymi parametrami), która ma się wykonać zaraz po starcie systemu (Startup) i/lub przed wyłączeniem (Shutdown). Oczywiście ścieżka do pliku powinna być dostępna na docelowej stacji roboczej. 

Analogicznie, skrypty można zdefiniować na poziomie ustawień konta użytkownika. Wykonują się one zaraz po zalogowaniu (Logon) lub tuż przed wylogowaniem (Logoff).

Jak to działa?

Co się dzieje, kiedy zapisujemy przygotowaną konfigurację, którą chcemy wymusić na komputerach i użytkownikach w domenie:

1. Ustawienia polityki są zapisywane w specjalnych plikach *.pol, które zawierają instrukcje, w jaki sposób należy zmodyfikować rejestr systemu, żeby wspomniane polityki zaczęły obowiązywać.
   1. Są to pliki binarne i ich format jest częściowo opisany w oficjalnej dokumentacji: Registry Policy File Format. Podgląd w postaci tekstowej przeważnie pozwala odczytać tę część rejestru, która zostanie zmodyfikowana.
2. Wszystkie pliki z ustawieniami GPO trafiają do współdzielonego zasobu share, z którego zostaną później pobrane przez docelowe stacje robocze znajdujące się w domenie.
   1. Gdzie dokładnie znajduje się ten zasób na DC, można sprawdzić za pomocą komendy net share i będzie to najprawdopodobniej C:\Windows\SYSVOL\sysvol. Kiedy wejdziemy w folder o takiej samej nazwie jak nazwa domeny, a następnie do folderu Policies, ujrzymy katalogi z GUID-em w nazwie. Właśnie tam znajdują się definicje ustawionych polityk. GUID to tak naprawdę identyfikator (ang. Unique ID) wybranej polityki, który możemy podejrzeć w jej szczegółach.
   2. Po wejściu w folder korespondujący z daną polityką zobaczymy kolejne 2 foldery: MACHINE (zawiera pliki *.pol dla ustawień dotyczących komputera) oraz USER (ustawienia dotyczące konta użytkownika).
3. Ustawienia zapisane w plikach są co jakiś czas pobierane przez klienta GP (gpsvc), działającego na komputerach podłączonych do domeny, a następnie aplikowane zgodnie z przechowywanymi tam instrukcjami. W większości przypadków będzie to modyfikacja rejestru z użyciem pobranych plików *.pol (które działają na podobnej zasadzie jak pliki z zapisanymi ustawieniami rejestru *.reg).
   1. Pobranie ustawień Group Policy następuje podczas każdego uruchomienia systemu będącego członkiem domeny, a automatyczna synchronizacja odbywa się domyślnie co 90 minut (+/- 30 minut). Dla kontrolera domeny jest to domyślnie 5 minut (kiedy sam sobie aplikuje ustawienia). Oczywiście te interwały można zmienić: How can I modify Group Policy’s refresh interval?
   2. Warto tutaj wspomnieć, że klient GP nie weryfikuje w żaden sposób sensu zapisanych tam instrukcji, więc wszystko co jest tam zapisane trafia do rejestru. Jeśli akurat jakiegoś klucza brakuje, to zostanie on automatycznie utworzony.
   3. Klient aplikujący politykę GPO nie tylko zmienia ustawienia, ale jednocześnie blokuje możliwość ich zmiany zwykłym użytkownikom. Lokalni administratorzy mogą to wprawdzie obejść, ale dopóki system jest w domenie, wymuszona konfiguracja zostanie przywrócona po kolejnej synchronizacji.

Opisany powyżej mechanizm wydaje się być prosty, ale pamiętajmy, że jest to tylko fragment całego mechanizmu związanego z Group Policy.

Klient Group Policy był kiedyś częścią procesu Winlogon, ale od pewnego czasu jest samodzielnym procesem, a dokładnie usługą systemową o nazwie gpsvc. Możemy to sprawdzić za pomocą polecenia sc query gpsvc. 

Kiedy spojrzymy na uprawnienia tej usługi (sc sdshow gpsvc), zobaczymy, że nie da się jej w prosty sposób zatrzymać, nawet przez administratorów. Jeśli jednak mocno się uprzemy, możemy to zrobić pożyczając uprawnienia LocalSystem. Jak takie uprawnienia uzyskać, zostało wyjaśnione w poprzedniej części szkolenia.

Rozszerzenia

Do tej pory skupiliśmy się na ustawieniach ściśle związanych z rejestrem systemu, ale warto wiedzieć, że GPO ma trochę szersze możliwości. Przykładowo, ustawienia związane z AppLocker (Computer configuration -> Policies -> Windows Settings -> Security Settings -> Application Control Policies -> AppLocker) bądź LAPS, nie ograniczają się tylko do ustawień w rejestrze (można to zobaczyć po innych plikach innych niż *.pol, które są udostępnione po zmianie tych ustawień).

Mamy wtedy do czynienia z rozszerzeniem GPO po stronie klienta, które może zawierać dodatkowe instrukcje do wykonania. Kiedy polityka z rozszerzeniem jest zaaplikowana po stronie klienta, można to zobaczyć w rejestrze systemowym pod kluczem Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions (Group Policy Client był kiedyś częścią Winlogon, stąd pozostałość w ścieżce).

Tutaj znajdziemy wszystkie rozszerzenia GPO. Klient GP przeszukuje te wpisy, sprawdzając czy wartość GUID ma poprawny format (jeśli nie, to taki wpis jest zwyczajnie ignorowany). Następnie odczytuje wartość DllName wskazującą na bibliotekę DLL zawierającą kod aplikujący dane rozszerzenie, a także wartość ProcessGroupPolicy, będącą nazwą funkcji wywoływaną przez proces związany z usługą gpsvc.

Niektórzy mogą się się teraz zastanawiać, czy to nie jest dobre miejsce na ukrycie złośliwego kodu – przecież można hipotetycznie można wrzucić tutaj dowolną bibliotekę DLL, która udaje rozszerzenie GPO. Na szczęście nie jest to takie proste!

Nawet jeśli uda nam się podstępem dodać do rejestru systemu klienta wpis udający rozszerzenie (poza mechanizmem GP), to i tak nie zostanie on wykonany. Pamiętajmy, że Group Policy to nie tylko współdzielenie plików, ale także komunikacja protokołem LDAP. Żeby rozszerzenie zadziałało, to (w uproszczeniu) Active Directory musi powiadomić o tym klienta GP.

Szablony ADM(X)

Lista dostępnych ustawień GPO nie jest zdefiniowana na sztywno w systemie i może być modyfikowana. Microsoft udostępnia aktualne zestawienie dostępnych opcji w postaci arkusza Excel: Group Policy Settings Reference Spreadsheet. Znajdziemy tutaj nazwy ustawień widocznych w wizualnym edytorze GPME; nazwy szablonów *.admx, w których poszczególne ustawienia są zdefiniowane (o tym za chwilę) oraz mapowania na powiązane klucze rejestru.

Jeśli zestaw domyślnie dostępnych opcji, widocznych w edytorze GPME, jest dla nas niewystarczający, możemy go sobie teoretycznie rozszerzyć za pomocą szablonów/plików *.admx (dawniej *.adm), których budowa jest udokumentowana:

• Administrative Template File (ADM) Format – do Windows Server 2003 włącznie.
• Administrative Template File (ADMX) Format – od Windows Server 2008 (format oparty na XML).

Kiedy mamy przygotowany szablon, możemy go importować w konsoli GPMC z użyciem opcji Add/Remove Template. Jeśli chcemy wiedzieć, jakie pliki ADMX są obecne w naszym systemie, możemy je sobie łatwo wyszukać: dir c:\*.admx /a/s/b.

Użyłem sformułowania teoretycznie, ponieważ dziś już raczej nikt sam nie pisze takich plików. Jedną z możliwości jest użycie gotowców, udostępnianych przez zewnętrznych dostawców. Na przykład, możemy sobie ściągnąć szablony, które definiują ustawienia GPO dla przeglądarki Firefox.

Group Policy Management Editor: Preferences

Inną ciekawą opcją, z której możemy skorzystać, żeby wyjść poza listę domyślnych ustawień, jest skorzystanie z narzędzia firmy trzeciej, które zostało zakupione przez Microsoft i zintegrowane z edytorem UI od wersji Windows Server 2008.

Drzewo po lewej stronie interfejsu GPME, zawiera węzeł Preferences (oprócz Policies), co jest widoczne poniżej:

Group Policy Management Editor -> Preferences

Jak widać, możemy tutaj zarządzać rzeczami, których domyślnie nie ma w definicji GPO. Jedną z takich rzeczy, jest zarządzanie rejestrem, czyli zamiast pisać swój własny szablon ADMX, możemy po prostu skonfigurować rejestr według naszych potrzeb. Oprócz tego możemy modyfikować m.in. pliki na dysku, więc to narzędzie daje nam sporo możliwości.

Oczywiście pod spodem są to rozszerzenia GPO w postaci bibliotek DLL, omówione wcześniej, ale ze stosunkowo przyjaznym i trochę nostalgicznym interfejsem :).

Pułapki

Początkujący administratorzy, którzy pracują z GPO, często popełniają grzech nadgorliwości, który może ich drogo kosztować. Przechodzą oni przez wszystkie dostępne polityki oraz ustawienia i na oko wyłączają bądź włączają określone przywileje.

Jest to proszenie się o kłopoty, ponieważ GPO nie weryfikuje w żaden sposób spójności wybranych ustawień i jeśli nie wiemy co robimy, możemy doprowadzić do sytuacji, w której zaaplikujemy sprzeczne ze sobą polityki. Kiedy takie ustawienia zostaną rozpropagowane na stacje robocze w domenie, możliwe, że będziemy zmuszeni naprawiać rejestr systemowy na każdej z nich (w trybie offline).

Dużo lepszym podejściem jest świadome określenie profilu bezpieczeństwa (czyli co dokładnie chcemy osiągnąć) i konfiguracja dedykowanej polityki zawierającej tylko niezbędne ustawienia. 

Poważną wadą mechanizmu GPO jest brak możliwości przywrócenia stanu poprzedniego. Możemy co prawda sprawdzić w historii, kto i kiedy zastosował wybraną politykę, ale nic ponadto.

Wyobraźmy sobie następującą sytuację: administrator włącza policy wymuszające ustawienie określonej tapety na pulpicie na wszystkich stacjach roboczych w domenie. Kiedy konfiguracja jest zaaplikowana na wszystkich komputerach, to użytkownicy nie mogą już ustawić swojego ulubionego zdjęcia.

Po jakimś czasie okazuje się, że to policy było jednak zbyt restrykcyjne i administrator nie chce już wymuszać na użytkownikach ustawień tapety. Wyłącza więc tę politykę, umożliwiając tym samym wybór dowolnej tapety, ale nie spowoduje to przywrócenia ustawień poprzednich, które miały miejsce przed zaaplikowaniem polityki wymuszającej. Mówiąc krótko: GPO nie ma opcji cofnij.

Mając to na uwadzę, powinniśmy sami zadbać o zarządzanie zmianami w miarę naszych potrzeb. Możemy na przykład robić regularne kopie zapasowe rejestrów systemowych, na zarządzanych przez domenę stacjach roboczych.

Weryfikacja ustawień

Poznaliśmy już ograniczenia Group Policy i pułapki czyhające na nieuważnych administratorów, ale pozostaje pytanie: w jaki sposób można zmitygować ryzyko popełnienia błędu? Na szczęście jest kilka możliwości:

• gpresult /h policy.htm – to polecenie wydajemy na kliencie. Jako wynik jego działania otrzymamy raport w postaci pliku HTML, pokazujący jakie ustawienia polityki zostały zaaplikowane na lokalnej stacji roboczej, wraz ze statystykami (np. czasem potrzebnym do wprowadzenia pobranych ustawień).
• rsop.msc – Resultant Set of Policy. Podobnie jak wyżej, również pokazuje ustawienia zaaplikowane na tym konkretnym kliencie, ale wyniki pokazywane są w formie edytora UI, podobnego do tego, którego używamy do konfigurowania GPO. Z tą różnicą, że ten jest tylko do odczytu.
• Group Policy Modeling – opcja dostępna z poziomu Group Policy Management Console, pozwalająca na weryfikację, w jaki sposób polityki zostaną wdrożone jeszcze zanim trafią do klientów. Jest to szczególnie przydatne, kiedy zarządzamy znaczną ilością polityk i chcemy sprawdzić jakie ustawienia będą potencjalnie zastosowane. Skorzystanie z tej opcji polega na uruchomieniu wizarda, który nas przepyta odnośnie docelowej konfiguracji, a następnie wygeneruje stosowny raport na podstawie udzielonych przez nas odpowiedzi.
• Advanced Group Policy Management (AGPM) – dodatkowe narzędzie będące częścią Microsoft Desktop Optimization Pack (MDOP), rozszerzające możliwości GPMC. Ma już swoje lata, ale dalej jest wspierane przez najnowsze systemy. Działa trochę na zasadzie środowiska staging, co pozwala nam przetestować poprawność ustawionych polityk zanim zostaną wdrożone.
  • Zasada działania opiera się na wprowadzeniu pośredniej bazie danych z ustawieniami GPO, zamiast bezpośrednio na kontrolerze domeny (DC). Aplikowanie ustawień z tej bazy na prawdziwym DC (po uprzednim zatwierdzeniu) należy do zadań aplikacji agenta, będącego częścią tego rozwiązania.
• Wspomniana baza danych ma śledzenie zmian, więc ułatwia sprawdzanie historii oraz pozwala na separację ról, np. zanim ustawienia trafią z bazy na DC, mogą zostać zweryfikowane przez innego administratora.

Kiedy dalej borykamy się z niewyjaśnionym problemem, a wspomniane wyżej techniki nie przyniosły odpowiedzi, zostaje nam jeszcze ostatnia deska ratunku w postaci przeglądu szczegółowych logów powiązanych z Group Policy: Applying Group Policy troubleshooting guidance – Windows Server | Microsoft Learn.

Przydatne narzędzia

Jeśli zepsujemy w sposób nieodwracalny polityki, które sami wcześniej utworzyliśmy, w najgorszym przypadku zwyczajnie je usuniemy i utworzymy na nowo. Kiedy jednak problem dotyczy dwóch domyślnych GPO, wspomnianych wcześniej (Default Domain Controllers Policy oraz Default Domain Policy), to może nie być tak łatwo. Pamiętamy przecież, że akurat tych dwóch polityk nie można usunąć.

Na szczęście jest i na to rozwiązanie. Nie można ich usunąć, ale można je odtworzyć za pomocą narzędzia dcgpofix.exe.

Autoruns – narzędzie, którego zadaniem jest identyfikacja i wylistowanie wszystkich procesów, które uruchamiają się automatycznie wraz ze startem systemu. Jedną z jego możliwości jest pokazanie rozszerzeń GPO (w postaci bibliotek DLL), w dostępnej zakładce WinLogon. Wcześniej należy jednak wyłączyć ukrywanie wpisów Windows: Options -> Hide Windows Entries.

Autor szkolenia (Grzegorz Tworek) również napisał kilka pomocniczych skryptów, którymi chętnie się dzieli. Część z nich może wymagać instalacji dodatkowych modułów PowerShell (np. RSAT):

• flatten-gpo.ps1 – kopiuje wszystkie pliki związane z GPO do jednego katalogu. Dzięki temu nie musimy przechodzić przez całą strukturę drzewa katalogów, żeby znaleźć interesujące nas pliki.
• Parse-PolicyFile.ps1 – czytnik plików *.pol.
• Parse-GPO.ps1 – oprócz plików *.pol próbuje odczytać pozostałe pliki wygenerowane przez GPO. Grupuje ustawienia polityk w obszary tematyczne, których one dotyczą i wyświetla w formie tabel (np. tabela zawierająca wszystkie ustawienia wpływające na uprawnienia do plików na dysku).
• GPOPermissionsCollector.ps1 – pokazuje uprawnienia do poszczególnych GPO w domenie.

~Łukasz Mieczkowski