BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki

Baza wiedzy











[Artykuł] Determinowanie celów zasad grup

08-01-2013 07:00 | Marcin Krzanowicz
Artykuł ma na celu przybliżenie procesu przetwarzania zasad grup w architekturze klient-serwer, ze szczególnym uwzględnieniem aspektów związanych z metodami określania celów, do których mają odnosić się wprowadzane zasady grup. Dodatkowo przybliżony zostanie proces zdalnego wywoływania odświeżania zasad grup.

Obiekty zasad grup – (GPO, ang. Group Policy Objects) mają na celu ułatwienie administratorom zarządzania, konfiguracji, monitorowania, wdrażania i wielu innych, codziennych, a jakże żmudnych czynności, gdy muszą one być wykonywane na dziesiątkach lub setkach hostów.
Pozwalają na znaczne zwiększenie wydajności i bezpieczeństwa, przy jednoczesnym zmniejszeniu nakładów pracy, kosztów i czasu reagowania na zaistniałe sytuacje. Wyobraźmy sobie sytuację, że jesteśmy administratorem, który pod swoją opieką ma setki stacji klienckich i serwerów. Właśnie wychodzi istotne z biznesowego punktu widzenia zagrożenie, na które musimy zareagować, ewentualnie helpdesk przekazuje nam powtarzające się skargi użytkowników, na działanie ich systemów, związane z tymi samymi niedogodnościami. Oczywiście zareagować musimy natychmiast, jednak bez centralnego miejsca, z którego możemy zarządzać zmianami w systemach, czy instalacją oprogramowania, zmuszeni bylibyśmy do przejścia po wszystkich hostach i monotonnego powtórzenia setki razy, tych samych czynności – zgroza! Na szczęście Microsoft, już jakiś czas temu, dał nam do ręki potężny oręż, dzięki któremu jesteśmy w stanie szybciej i niezwykle wydajnie zarządzać naszym środowiskiem IT. Przyjrzyjmy się mu więc bliżej.

Zasady grup są jedną z funkcjonalności systemu Windows, która umożliwia administratorom konfigurację i zarządzanie ustawieniami urządzeń oraz użytkowników, z wykorzystaniem centralnego punktu administracyjnego. Najbardziej elementarną częścią zasad grup jest pojedyncze ustawienie zasad grup, nazywane czasami po prostu zasadą. Definiuje ona pojedyncze ustawienie/zmianę, które ma zostać wprowadzone na określonym hoście. Te atomowe składniki są częścią większego zbioru, nazywanego Obiektem zasad grup (GPO). Pojedyncze GPO mogą składać się z jednego lub wielu ustawień, które mają mieć zastosowanie w odniesieniu do konkretnych użytkowników lub urządzeń.

Tak naprawdę zasady grup można przechowywać w formacie xml (od Windows Server 2008 pliki ADM zostały zastąpione przez ADMX i pliki językowe ADML). Przykładowa zasada grup przedstawiona została na Rys.1.

 Rys.1. Przykładowa zawartość zasady GPO.

Rys.1. Przykładowa zawartość zasady GPO.

Zasady grup najczęściej* przetwarzane są według następującej kolejności:

  • Lokalne obiekty zasad grup.
  • Obiekty zasad grup przypisane do lokacji.
  • Obiekty zasad grup przypisane do domeny.
  • Obiekty zasad grup przypisane do jednostki organizacyjnej.

* - najczęściej, ponieważ administrator może mieć wpływ na blokowanie lub wymuszanie stosowania określonych zasad.

W najprostszej wersji, dana zasada może posiadać jeden z trzech stanów:

  • Włączona.
  • Wyłączona.
  • Nieskonfigurowana.

O ile włączona i wyłączona są pojęciami na tyle intuicyjnymi, że chyba nikomu nie trzeba tłumaczyć, co oznaczają, o tyle stan „nie skonfigurowano” wymaga dobrego zrozumienia. Powiedzenie, że stan „nie skonfigurowano” skutkuje tylko zastosowaniem ustawień domyślnych nie odzwierciedla celu, w jakim stosuje się owo ustawienie. Istotą zagadnienia jest proces dziedziczenia zasad grup. Wygląda on tak, że zgodnie z podaną wyżej kolejnością, przetwarzane są obiekty zasad grup na kolejnych poziomach. Jeżeli na pierwszym poziomie Zasada A będzie miała stan „włączona” i żaden z obiektów zasad grup na niższych poziomach jej nie nadpisze (owa zasada w nich nie będzie ustawiona na „wyłączony”), to Zasada A zostanie wdrożona. Podobnie sytuacja będzie wyglądać gdyby ta zasada miała stan „wyłączona” i żadne inne obiekty nie byłyby z nią w konflikcie. Wielu początkujących (i nie tylko) administratorów w tym momencie zadaje pytanie – skoro domyślnie zasady mają status „nie skonfigurowano”, to koniec końców i tak nie są wdrażane zmiany, po co więc jest obecny stan „wyłączony”? Aby to wyjaśnić musimy wyobrazić sobie sytuację, w której mamy kilka obiektów zasad grup definiujących w różny sposób tę samą zasadę. Przykładowo – Zasada B zabrania użytkownikowi zmiany tła pulpitu (włączona). Gdy ta zasada w GPO na niższym poziomie również będzie miała stan włączonej, to użytkownik nie będzie mógł zmienić tła pulpitu. Gdybyśmy natomiast pozostawili zasadę w GPO na niższym poziomie w stanie „nie skonfigurowano”, to odziedziczy ona ustawienia z wyższego poziomu i użytkownik również nie będzie mógł zmienić swojej tapety. Chyba odpowiedź na pytanie zaczyna się już klarować? Jak więc nadać użytkownikowi prawo do dokonywania zmiany tła pulpitu? Na niższym poziomie należy ustawić Zasadę B w stan „wyłączona” i wtedy nadpisze ona wcześniejsze ustawienia dotyczące tejże zasady. Mam nadzieję, że idea stosowania tej trzy-stanowej logiki jest zrozumiała oraz umiemy rozróżnić cel i sens stosowania trzech różnych stanów prostych zasad grup. W najprostszych słowach można zagadnienie podsumować, jako: „bliższa koszula ciału, niż sukmana”, co należy rozumieć tak, iż GPO przypisane bliżej miejsca, gdzie znajduje się obiekt Active Directory, będzie ważniejsze niż GPO bardziej oddalone od tegoż miejsca, pod warunkiem, że sami nie zaburzymy kolejności przetwarzania GPO, o czym w dalszej części publikacji.

  1. Uruchomienie komputera. Następuje uruchomienie komputera i sieci. Uruchamiane są również usługi RPCSS (zdalne wywoływanie procedur) oraz MUP (Multiple Universal Naming Convention Provider). Uruchomiony zostaje klient zasad grup.
  2. Klient otrzymuje od serwera uporządkowaną listę GPO, lista jest uporządkowana zgodnie z zasadami kolejności opisanymi we wcześniejszym rozdziale, z tą różnicą, że ewentualne wymuszone GPO są przetwarzane na samym końcu. W przypadku wielu wymuszonych GPO na różnych poziomach, ich przetwarzanie następuje w kolejności odwrotnej tzn. najpierw wymuszone GPO na poziomie OU, potem wymuszone GPO na poziomie domeny i na końcu GPO wymuszone na poziomie lokacji, a więc wymuszony GPO na poziomie lokacji będzie dopisany na samym końcu tejże listy.
  3. Rozszerzenia po stronie klienta zasad grup przetwarzają synchronicznie otrzymaną wcześniej listę. Podczas przetwarzania każdego obiektu zasad grup host określa, czy jego ustawienia z węzła ustawień dotyczących komputera powinny być zastosowane (np. czy ustawienia komputera w GPO są włączone) oraz czy host ma prawo odczytu i zastosowania tychże zmian. W przypadku istnienia nałożonego filtra WMI, po stronie klienta zostaje wykonana kwerenda określona w filtrze.
  4. Rozszerzenia po stronie serwera rozpoczynają przetwarzanie obiektów GPO wobec ustawień, które powinny być zastosowane wobec klienta. Wprowadzane w życie zostają ustawienia z GPO (Nadpisywanie poprzednio stosowanych zasad).
  5. Podczas logowania się użytkownika zostają powtórzone kroki 2-4 z tą różnicą, że zamiast ustawień dotyczących komputera, są przetwarzane zasady dotyczące użytkownika (proces ulegnie lekkiej modyfikacji, jeżeli zastosowane zostanie przetwarzanie w sprzężeniu zwrotnym, ale nie jest to bezpośrednio związane z niniejszym artykułem).
  6. Co 90-120 minut od uruchomienia hosta następuje odświeżenie zasad grup związanych z komputerem (kroki 2-4 dla komputera).
  7. Co 90-120 minut od uruchomienia hosta następuje odświeżenie zasad grup związanych z użytkownikiem (kroki 2-4 dla użytkownika).

Należy mieć na uwadze, że niektóre zamiany w zasadach grup nie zostaną odświeżone zgodnie z cyklicznym planem odświeżania zasad grup, ponieważ wymagają ponownego zalogowania użytkownika lub uruchomienia hosta.

Najczęściej w środowisku produkcyjnym nie wystarczy wdrożenie jednej polisy. Aby spełnić cele biznesowe, stosowane są dziesiątki a czasami setki różnych GPO. Dzieje się tak, chociażby ze względu na stosunkowo łatwą możliwość czasowego wyłączenia lub usunięcia obiektu GPO, w którym zastosowaliśmy zbiór konkretnych zasad odnoszących się do jednej funkcji lub wykorzystywanej technologii. W obliczu takiej sytuacji stajemy zazwyczaj przed kolejnym problemem – Wiele Obiektów zasad grup jest przypisanych do danego poziomu. Niektóre z nich w różny sposób definiują te same funkcje i nie można już polegać tylko i wyłącznie na schemacie obrazującym kierunek przetwarzania zasad grup. Co więc robić? Wykorzystywać zasady pierwszeństwa przyłączanych GPO i następnie dopasowywać je tak, aby spełniały oczekiwane cele.

Zasady pierwszeństwa są przedstawione graficznie w przystawce „Gorup Policy Management”. Możemy je przeglądać, po wybraniu z listy interesującego nas kontenera i przejściu w głównym oknie na zakładkę „Linked Group Policy Objects”, pokazanym na Rys.2.

Rys.2. Przyłączone obiekty GPO. 

Rys.2. Przyłączone obiekty GPO.

Na powyższym rysunku widzimy, że do jednostki organizacyjnej „Finanse” są przyłączone dwa różne obiekty zasad grup (GPO1 i GPO2). Za pomocą widocznych strzałek mamy możliwość zmiany kolejności obiektów przyłączonych bezpośrednio do OU. Tutaj ważna uwaga - kolejność, tak naprawdę powinna zostać nazwana pierwszeństwem, ponieważ im niższy numer związany z konkretnym GPO, tym jest ono ważniejsze, z kolei im wyższy numer, tym GPO staje się mniej istotne. Tak, więc w naszym przykładzie, ponieważ GPO1 ma przypisany niższy numer niż GPO2, to jest ono ważniejsze i jeśli jakaś zasada w obu obiektach zostanie skonfigurowana w różny sposób, to wdrożona zostanie zasada zawarta w GPO1. Zobaczmy, jakich informacji dostarcza nam kolejna zakładka – „Group Policy Inheritance”, widoczna na Rys.3.

Rys.3. Ważność obiektów zasad grup.

Rys.3. Ważność obiektów zasad grup. 

Tutaj możemy zobaczyć kolejność oraz pierwszeństwo przetwarzania GPO w odniesieniu do danego kontenera. Uwaga, jak można przeczytać na rysunku, w tym oknie nie ujrzymy GPO przypisanych do lokacji, a jedynie GPO przypisywane do domeny oraz jednostek organizacyjnych. Jak więc odczytywać informacje z takowego okienka? Parametr „Precedence” określa pierwszeństwo rozumiane, jako ważność/istotność w procesie przetwarzania zasad grup, gdzie zasada bardziej istotna będzie wdrażana zamiast zasady mniej istotnej w przypadku wystąpienia konfliktu. W rzeczywistości kolejność przetwarzania obiektów GPO będzie odwrotna do przypisanego atrybutu pierwszeństwa. (Wyższy numer pierwszeństwa przetwarzany wcześniej, niż niższy numer pierwszeństwa).  Odnosząc się jeszcze raz do prezentowanego przykładu – Do domeny mamy dołączony domyślny obiekt zasad grup, który jest przetwarzany najpierw, zanim przetworzone zostaną obiekty przypisane do jednostki organizacyjnej. Do OU „Finanse” przypisane mamy dwa obiekty zasad grup, z których istotniejszy jest „GPO1”. Stąd też, zasady w domyślnej GPO zostaną zastosowane do jednostki „Finanse” tylko wtedy, gdy nie będą w konflikcie z GPO2 ani GPO1. Zasady z GPO2 zostaną wdrożone w przypadku konfliktu z domyślnym GPO, natomiast zasady zdefiniowane w GPO1 będą wdrożone nawet wtedy, gdy są w konflikcie z GPO2 lub domyślnym GPO.

Warto też pamiętać, że obiekty GPO przypisane do domeny głównej, nie są dziedziczone przez domeny podrzędne.

Wiemy już, w jaki sposób domyślnie są przetwarzane zasady grup. Istnieją jednak sytuacje, w których chcielibyśmy na wyższym poziomie zdefiniować jakąś ważną zasadę, która nie może być nadpisana przez żaden inny obiekt GPO, nawet, jeśli byłby przypisany na poziomie kontenera i pozostawał w konflikcie z naszą zasadą. Czy można coś takiego zrobić w prosty sposób? Oczywiście, że można! Wystarczy wykorzystać „wymuszenie” – Rys.4.

Rys.4. Wymuszenie zasad grup. 

Rys.4. Wymuszenie zasad grup.

W momencie ustawienia przyłączonego GPO w stan wymuszenia, przyjmuje on pierwszeństwo w procesie przetwarzania zasad grup, a więc zasady zdefiniowane w wymuszonym GPO będą ważniejsze od innych, mających wpływ na obiekty Active Directory. Nie należy zapominać, że wymuszenie ma takie same skutki również dla potomnych jednostek organizacyjnych oraz obiektów. Co więcej, wymuszenie będzie stosowane niezależnie od tego, czy włączono opcję blokowania dziedziczenia (o której w dalszej części artykułu).

Wróćmy do naszego laboratorium. Jak teraz, po wymuszeniu na domenie obiektu zasad grup „Security1” zmieni się sytuacja w odniesieniu do jednostki organizacyjnej „Finanse”? Otóż zakładka „Linked Group Policy Objects” nie zmieni się w ogóle, ponieważ nie przyłączyliśmy do naszej OU żadnych nowych GPO. Zmianie ulegnie natomiast zakładka „Group Policy Inheritance”. Jak widzimy na Rys.5, wymuszony na domenie obiekt zasad grup zyskał pierwszeństwo nad przyłączonymi bezpośrednio do jednostki organizacyjnej GPO.

 Rys.5. Ważność zasad grup, po wymuszeniu GPO.

Rys.5. Ważność zasad grup, po wymuszeniu GPO.

Mamy już przećwiczone zachowanie, gdy wymuszamy wdrożenie konkretnych zasad w środowisku. Zajmijmy się teraz sytuacją, kiedy zależy nam na wykluczeniu jakiejś części naszej domeny, z przetwarzania konkretnych zasad.

Do realizacji zadania w Windows Server 2012 (Windows Server 2008 oraz 2008 R2 też się nadają)  możemy wykorzystać kilka funkcji. Pierwszą z nich jest wyłączanie danego obiektu GPO. Aby tego dokonać musimy w przystawce Group Policy Management wybrać intersujący nas obiekt zasad grup i przejść do zakładki „Details”. Na Rys.6. możemy zauważyć, że dostępne są cztery ustawienia:

  • Wszystkie ustawienia wyłączone
  • Wyłączone ustawienia dotyczące komputera
  • Wszystkie ustawienia włączone
  • Wyłączone ustawienia dotyczące użytkownika.

Wyłączenie ustawień jest tu rozumiane, jako ich nie przetwarzanie, a nie ustawienie wszystkich zasad w stan „wyłączone”. Moim zdaniem owe opcje są na tyle jasne i intuicyjne, że nie wymagają ich rozpisywania. Owa funkcjonalność ukazuje swoje szczególne zalety w procesie rozwiązywania problemów związanych z zasadami grup. Ponadto możemy przygotować infrastrukturę GPO, które pozostawiamy wyłączone, ale w pewnych sytuacjach możemy je błyskawicznie włączyć bez konieczności tworzenia i przyłączania struktur zasad grup.

Rys.6. Wyłączanie GPO.

Rys.6. Wyłączanie GPO.

Poznaliśmy już pierwszy sposób, w jaki możemy ograniczać stosowanie pewnych zasad grup, jednak nie ukrywajmy, że ten sposób nie jest ani elastyczny, ani nie oferuje zbyt wielu funkcjonalności w dziedzinie determinowania docelowych hostów.

Przetestujmy więc kolejną możliwość, jaką oferuje Windows Server 2012 - wspominane wcześniej blokowanie dziedziczenia. Tutaj już na wstępie uwaga, że blokowanie dziedziczenia powinno być stosowane w bardzo ograniczonym stopniu (o ile w ogóle), ponieważ w znacznym stopniu komplikuje intuicyjną ocenę dziedziczenia i pierwszeństwa zasad grup.

Powracając jeszcze na chwilę do dziedziczenia. Obiekty zasad grup są dziedziczone zgodnie z kolejnością podaną w rozdziale „Jak są przetwarzane zasady grup?”. Są również dziedziczone przez kolejne poziomy jednostek organizacyjnych. To znaczy, jeśli będziemy mieć GPO przyłączone do jednostki „Kierownictwo”, która zawiera w sobie jednostki „Dyrektorzy” i „Rada nadzorcza”, to obie jednostki podrzędne również odziedziczą GPO przypisane do jednostki macierzystej. Przejdźmy więc do naszego środowiska testowego i zablokujmy dziedziczenie w naszej OU „Finanse” – Rys.7.

 Rys.7. Blokowanie dziedziczenia zasad grup.

Rys.7. Blokowanie dziedziczenia zasad grup.

Podobnie jak w pierwszym przypadku, modyfikacjom ulegnie tylko zakładka „Grup Policy Inheritance” – Rys.8.

 Rys.8. Ważność GPO, po zablokowaniu dziedziczenia.

Rys.8. Ważność GPO, po zablokowaniu dziedziczenia.

Analizując otrzymany wynik – Zablokowaliśmy dziedziczenie nadrzędnych obiektów, nie zmieniając zasad w bezpośrednio przyłączonych GPO. Zauważmy, że jak wspominałem podczas omawiania wymuszania zasad, zablokowanie dziedziczenia nie wpłynęło na owy, wymuszony wcześniej obiekt. Wpłynęło natomiast na niewymuszone GPO przyłączone na wyższych poziomach – „Update12” oraz „Default Domain Policy”, które teraz nie będą przetwarzane w odniesieniu do „Finansów”. Zwróćmy uwagę, że z zastosowaniem blokowania dziedziczenia nie mamy możliwości blokowania selektywnego. To znaczy, albo blokujemy wszystkie GPO nadrzędne albo nie blokujemy żadnego – mimo wszystko trochę kiepsko…, dlatego przyjrzyjmy się innym rozwiązaniom.

Jak wiemy, obiektów zasad grup nie można przyłączać bezpośrednio do grup ani użytkowników, można natomiast zmodyfikować zakres działania zdefiniowanych zasad z wykorzystaniem właśnie grup zabezpieczeń, względnie pojedynczych kont użytkowników. Jak to możliwe? Otóż zasady GPO są stosowany tylko i wyłącznie wobec obiektów Active Directory, które posiadają prawo stosowania tychże zasad – „Allow Apply Group Policy” (W prostym edytorze uprawnień - prawo odczytu „Read”). Domyślnie wszyscy uwierzytelnieni użytkownicy Active Directory mają ww. prawo, dlatego wobec nich są wdrażane zasady grup – Rys.9.

Rys.9. Prawo odczytu i zastosowania zasad grup.

Rys.9. Prawo odczytu i zastosowania zasad grup.

Jak należy wykorzystać tę wiedzę, do odpowiedniego odfiltrowania obiektów, które nie mają przetwarzać GPO? Generalnie możliwe są dwa podejścia:

  1. Usunięcie grupie uwierzytelnionych użytkowników (Authenticated Users) prawa stosowania zasad grup. Następnie dodanie stosownych grup zabezpieczeń, której członkowie mają przetwarzać zasad z GPO i ustawienie im prawa stosowania tychże zasad.
  2. Dodanie stosownych grup zabezpieczeń, której członkowie nie mają przetwarzać zasad z GPO i ustawienie im prawa odmowy stosowania tychże zasad (Deny Apply Group Policy).

Który wariant jest lepszy? Zdecydowanie pierwszy, ponieważ ustawienie jakiejś grupie prawa na „Odmów” będzie odmawiać członkom tej grupy owego prawa, nawet gdybyśmy dodali osobno konto użytkownika z tej grupy z ustawieniem prawa „Pozwól”. Skutkuje to zmniejszeniem przejrzystości i utrudnieniem późniejszego rozwiązywania problemów związanych z zasadami grup. Przejdźmy do środowiska testowego i spróbujmy pozmieniać domyślne ustawienia filtrowania zabezpieczeń.

Na Rys.10. przedstawiony został stan domyślny – Zasady z obiektu zasad grup są stosowane tylko wobec grupy uwierzytelnionych użytkowników. Nam zależy na tym, aby owe zasady były stosowane jedynie wobec członków grupy „Finanse” – Rys.11. Aby tego dokonać przejdźmy w drzewie do kontenera obiektów zasad grup (Group Policy Objects) i wybierzmy pierwszą zakładkę „Scopes”. Widzimy teraz, do jakich jednostek nasz GPO został przypisany oraz jakie grupy będą przetwarzać zasady znajdujące się w tym GPO. W celu uzyskania interesującego nas stanu końcowego Klikamy w sekcji filtrowania zabezpieczeń przycisk „Dodaj” i odszukujemy grupę zabezpieczeń „Finanse”, zatwierdzamy. Następnie zaznaczamy grupę użytkowników uwierzytelnionych i klikamy „Usuń”. Gotowe!

Rys.10. Domyslne prawa odczytu i stosowania GPO. 

Rys.10. Domyślne prawa odczytu i stosowania GPO.

Rys.11. Zmodyfikowane prawa odczytu i stosowania GPO.

Rys.11. Zmodyfikowane prawa odczytu i stosowania GPO.

Edycji praw odczytu i stosowania zasad grup można dokonywać również z poziomu przyłączonego GPO w danym kontenerze, w podobny sposób jak opisałem wyżej, natomiast raczej nie powinno się operować na „linku” do obiektu, tylko na samym obiekcie. Dodatkowo, jeśli skorzystamy z drugiego wariantu filtrowania, to w części filtrowania bezpieczeństwa nie zobaczymy stosownego wpisu mówiącego o odmowie praw, stąd też nie polecam wspomnianego rozwiązania.

Znamy już sposób na filtrowanie w odniesieniu do konkretnych grup użytkowników lub urządzeń. Co zrobić w przypadku, gdyby nasz GPO służył do zdalnej instalacji oprogramowania, ale chcielibyśmy je zainstalować tylko i wyłącznie na hostach spełniających określone parametry? Można do tego celu zastosować filtry WMI, termin, który bardziej spostrzegawczy zauważyli na prezentowanych wcześniej zrzutach ekranu. Czym są filtry WMI? Zacznijmy od samego WMI – jest to technologia zarządzania infrastrukturą pozwalająca na monitorowanie i kontrolę obiektów w zarządzanym przez nas środowisku. Samo filtrowanie odbywa się w oparciu o określone parametry, na przykład taktowanie CPU, ilość pamięci RAM, system operacyjny i wiele innych. Sama składnia filtrowania WMI przypomina prostą składnię SQL, czyli „SELECT co FROM skąd WHERE określony_warunek”. Przykładowo, jeśli chcemy wdrożyć nasze GPO tylko do komputerów, na których jest zainstalowany Windows XP Professional z SP3, to musimy stworzyć filtr widoczny na Rys.12, który zastosujemy do odpowiedniego GPO – Rys.13.

Rys.12. Przykładowy filtr WMI.

Rys.12. Przykładowy filtr WMI.

Rys.13. Zastosowanie filtrowania WMI.

Rys.13. Zastosowanie filtrowania WMI.

O czym należy pamiętać? Jeden obiekt zasad grup może być filtrowany tylko i wyłącznie z użyciem jednego filtra WMI, nic nie stoi jednak na przeszkodzie, żeby stworzyć skomplikowany i wymyślny filtr, który będzie w 100% spełniał nasze oczekiwania… Nic, oprócz szybkości jego wykonywania ;)

Jest to bardzo dobre narzędzie, jednak ma też swoje minusy. Po pierwsze tworzenie filtrów wymaga znajomości różnych klas i składni właściwości ich obiektów. Oczywiście można w Internecie znaleźć wiele przykładowych filtrów i opisów, ale zapamiętanie tych wszystkich właściwości byłoby niezłym wyzwaniem, chociaż z użyciem specyficznych narzędzi programistycznych nie jest to problemem nie do przejścia. Po drugie filtr WMI nie są przetwarzane przez systemy Windows 2000 i starsze (wbrew pozorom i takie maszyny można jeszcze znaleźć działające). Po trzecie i najistotniejsze mają pewien okresowy wpływ na wydajność systemów, przez które są przetwarzane (Patrz – proces przetwarzania zasad grup w domenie).

Ostatnią omówioną metodą modyfikowania procesu przetwarzania zasad grup będzie określanie celu preferencji na poziomie obiektu. Preferencje zostały wprowadzone w systemie Windows Server 2008. Możemy je znaleźć w edytorze zasad grup, zarówno w węźle ustawień urządzenia, jak i węźle ustawień użytkownika. Pozwalają na łatwą i przyjemną realizację wielu zadań, które we wcześniejszych systemach wymagały tworzenia odpowiednich skryptów. W GPP (Group Policy Preferences) możemy chociażby zmapować konkretnym użytkownikom określone dyski sieciowe Rys.14. czy utworzyć później, na pulpicie skróty do tych dysków.

 Rys.14. Przykładowa preferencja zasad grup (GPP).

Rys.14. Przykładowa preferencja zasad grup (GPP).

Wartą uwagi funkcjonalnością, która została wprowadzona wraz z GPP jest określanie celu preferencji na poziomie obiektu (ILT - ang. Item-level Targeting). Dzięki niej, w jednym obiekcie zasad grup możemy zdefiniować wiele różnych celów. Aby móc określić właściwości celu, musimy przejść w naszej preferencji na zakładkę „Common” i zaznaczyć pole wyboru „Item-level Targeting” – Rys.15, po czym otworzyć edytor zasad celu - Rys.16.

Rys.15. Włączenie ILT.

Rys.15. Włączenie ILT.

Rys.16. Właściwości ILT.

Rys.16. Właściwości ILT.

 Na powyższym rysunku widzimy, że w prosty sposób mamy możliwość wybrania właściwości, po której będziemy filtrować cele ustawionych przez nas preferencji zasad grup. Kryteria są dość oczywiste, więc nie będziemy się na nich skupiać. Zamiast tego spróbujemy zdefiniować prosty cel ustawionej przez nas GPP. Wybierzemy kryterium adresu IP tak, aby nasz dysk był mapowany na komputerach o IP z zakresu 192.168.0.55 – 192.168.0.70 – Rys.17.

Rys.17. Prosty filtr ILT.

Rys.17. Prosty filtr ILT.

Możliwości ILT nie kończą się jednak na zdefiniowaniu jednej prostej reguły. Możemy, bowiem przejść do opcji obiektu (ang. Item Options) – Rys.18. i wskazać, czy nasz dysk ma być mapowany do adresów IP ze zdefiniowanego zakresu, czy też do wszystkich komputerów, oprócz zakresu, który właśnie zdefiniowaliśmy. Ponadto, jeśli stworzymy więcej reguł określania celu (na przykład po minimalnej ilości pamięci RAM, miejsca na dysku, systemu operacyjnego itd.), to uzyskamy możliwość określenia warunków logicznych zachodzących między poszczególnymi regułami. Do wyboru mamy logiczne AND oraz logiczne OR. Rys.18. Opcje obiektów filtra ILT.

Rys.18. Opcje obiektów filtra ILT.

Chociaż warunki logiczne wydają się proste i intuicyjne, to jednak bardzo często sprawiają kłopoty, zwłaszcza przy definiowaniu bardziej wymyślnych reguł. Dlatego chciałbym poświęcić kawałek niniejszego artykułu na powtórzenie wiadomości związanych z tym zagadnieniem, w kontekście określania celów GPP.

W przypadku warunków logicznych, posługujemy się zdaniami logicznymi, reprezentowanymi najczęściej przez zdanie oznajmujące (np. adresy ip są z zakresu 192.168.0.55 – 192.168.0.70), które może przyjmować dwie wartości logiczne: prawdę lub fałsz („Is” lub „Is Not”). W edytorze określania celów mamy też do czynienia ze zdaniami logicznymi, złożonymi (więcej niż jeden warunek), które mogą zostać poddane działaniom logicznej alternatywy (sumy logicznej - „OR”) lub/oraz koniunkcji (iloczynowi logicznemu – „AND”).

AND przyjmuje wartość prawdy, tylko i wyłącznie wtedy, kiedy każde ze składowych zdań logicznych ma wartość prawdy, co należy rozumieć w kontekście GPP tak, że cel naszego działania musi spełniać wszystkie warunki.

OR przyjmuje wartość prawdy, jeżeli którekolwiek ze składowych zdań logicznych ma wartość prawdy, co należy rozumieć w kontekście GPP tak, że cel naszego działania musi spełniać którykolwiek z określonych warunków.

Jak można zauważyć na Rys.18, obok opcji obiektu mamy strzałki, które służą do przemieszczania zdefiniowanych reguł w górę lub w dół naszej listy. Jest to o tyle istotne, że proces określania końcowego filtra odbywa się sekwencyjnie z uwzględnieniem pierwszeństwa operacji (koniunkcja ma pierwszeństwo przed alternatywą).

Odwołując się do naszego przykładu – zdefiniowaliśmy 3 reguły: adres IP z zakresu 192.168.0.55-192.168.0.70 AND system operacyjny Windows 7 Pro OR Pamięć RAM >= 4GB. Jak będzie wyglądać proces przetwarzania i jaki uzyskamy wynik końcowy? W pierwszym kroku host docelowy musi posiadać IP z określonego zakresu. Następnie wykonywana jest koniunkcja na zdaniach wejściowych – IP i system operacyjny, a więc host docelowy musi mieć IP ze zdefiniowanego zakresu oraz dodatkowo mieć zainstalowany system Win 7 Pro. Ponieważ w przykładzie mamy jeszcze jedną regułę – ilość RAM, to zostaje poddana operacji alternatywy z wcześniejszym, wynikowym zdaniem logicznym. Suma summarum, nasz dysk zostanie zmapowany jedynie na hostach, które mają IP z zakresu 192.168.0.55-192.168.0.70 i jednocześnie zainstalowany system operacyjny Windows 7 Professional, niezależnie od tego ile posiadają pamięci operacyjnej RAM oraz na hostach, które mają, co najmniej 4GB RAM, niezależnie od tego, jaki mają przypisany adres IP i jaki zainstalowany system operacyjny.

A co w przypadku, gdybyśmy chcieli nasz filtr rozbudować tak, aby zaburzyć reguły pierwszeństwa koniunkcji nad alternatywą? Ewentualnie polepszyć czytelność naszej listy? Osoby mające do czynienia z programowaniem (inni pewnie też ) od razu wpadną na to, że trzeba wykorzystać nawiasy. Skąd jednak w Targeting Editorze wziąć nawiasy? Rozwiązanie można zobaczyć na Rys.19. Chodzi oczywiście o dodanie kolekcji, która symuluje takowy nawias, chociaż w poniższym przykładzie akurat nawias nie byłby potrzebny. Znając już funkcjonalności edytora celów jesteśmy w stanie budować naprawdę złożone filtry, Jednak trzeba dobrze poznać i zrozumieć algebrę boole’owską, aby stworzyć filtr adekwatny do naszych oczekiwań. Przy okazji pozdrowienia dla żaków uważających, że matematyka dyskretna do niczego się nie przydaje – nie-praw-da! ;)

Rys.19. Kolekcje w filtrze ILT.

Rys.19. Kolekcje w filtrze ILT. 

Podobnie jak w przypadku użycia filtrów WMI, wymagane jest wykonanie kwerendy przez hosta podczas procesu przetwarzania zasad grup, co może mieć znaczący wpływ na okresową wydajność systemu klienta szczególnie, jeśli filtrowanie odbywa się z wykorzystaniem zapytań LDAP, chociaż przeważnie ILT jest szybszy niż filtry WMI. Dodatkowo, jeśli zdecydujemy się wdrożyć ILT określające, w jakiej jednostce organizacyjnej jest nasze konto komputera, warto zainteresować się artykułem i wydaną poprawką: http://support.microsoft.com/kb/2561285 pozwalającą rozwiązać częste problemy z czasem określania przynależności komputera do OU.

Jedną z ciekawszych funkcjonalności, jaką oferuje WS2012 (właściwie PowerShell 3.0) w kontekście zasad grup, jest zdalne wymuszenie aktualizacji zasad grup. Można tego dokonać z użyciem funkcji widocznej na Rys.20. w stosunku do adekwatnej jednostki organizacyjnej. Po użyciu owej funkcjonalności automatycznie zostanie przeliczona liczba komputerów, co do których mają zostać wprowadzone zmiany, natomiast same wymuszenie na hostach docelowych będzie miało domyślnie miejsce w przeciągu 10 minut (ma to związek z rozkładaniem obciążenia w czasie).

 Rys.20. Zdalne odświeżanie zasad grup.

Rys.20. Zdalne odświeżanie zasad grup.

Oprócz wykorzystania interfejsu graficznego, możemy również użyć PowerShella w celu zdalnego odświeżenia zasad grup. Służy do tego polecenie:

 

Użycie go bez żadnych parametrów spowoduje odświeżenie zasad grup na lokalnym komputerze. Podobnie, jak w przypadku narzędzia graficznego, domyślnie odświeżenie wykona się do 10 minut. Aby wykonać odświeżenie na dowolnie wybranym komputerze w domenie należy użyć polecenia z parametrem „-Computer” i nazwą komputera docelowego:

 

Jeżeli zależy nam na natychmiastowym odświeżeniu zasad grup, musimy wykorzystać parametr „-RandomDelayInMinutes” podając wartość „0”:

 

Aby wymusić odświeżenie wszystkich zasad grup, bez względu na to czy i kiedy zostały zmienione, należy użyć parametru „-Force”:

 

Możemy również skorzystać ze znanych przełączników –Boot oraz –LogOff, które spowodują ponowne uruchomienie komputera lub wylogowanie użytkownika, jeśli będzie to konieczne z punktu widzenia wdrożenie aktualnych zasad grup. Natomiast używając trochę bardziej złożonej składni, jesteśmy w stanie wymusić odświeżenie zasad dla wszystkich komputerów w domenie:

Albo tylko dla komputerów z jednostki organizacyjnej „Finanse”:

Potężne możliwości płyną z wykorzystania parametrów obiektów komputera w Active Directory. Możemy chociażby odświeżyć zasady grup tylko na komputerach z Windows 7:

 

Pełna lista parametrów, po których możemy precyzować cele odświeżania zasad grup:Rys.21. Parametry, po których można filtrować cele zdalnego odświeżania zasad grup.

 Rys.21. Parametry, po których można filtrować cele zdalnego odświeżania zasad grup.

W gwoli wyjaśnienia procesu zachodzącego podczas odświeżania zasad grup w ww. sposób. W momencie wywołania polecenia Invoke-GpUpdate - na hoście docelowym zdalnie tworzone jest zadanie odświeżenia zasad grup w jego harmonogramie zadań. Z tego względu należy upewnić się, że na hoście docelowym uruchomiona jest usługa harmonogramu zadań. Ponadto niezbędne może się okazać dodanie nowych zasad dotyczących pakietów przychodzących na hostach zdalnych:

  • RPC
  • RPC-EPMAP
  • WMI-In

Możemy w tym celu wykorzystać predefiniowany GPO:

Rys.22. Predefiniowany GPO otwierający porty wymagane do zdalnego odświeżania zasad grup.

Rys.22. Predefiniowany GPO otwierający porty wymagane do zdalnego odświeżania zasad grup.

Trudno dziś sobie wyobrazić pracę administratora, bez obiektów zasad grup. Ta funkcjonalność oferuje ogromne możliwości konfiguracyjne hostów końcowych. Jedak wymaga dobrego poznania i zrozumienia zarówno sposobów określania celów, do których mają się odnosić zasady grup, jak i związanych z nimi konsekwencjami.

Źródło: Opracowanie własne.

Komentarze 5

Użytkownik usunięty VIP
Użytkownik usunięty
62 pkt.
Poczatkujacy
Właściciel projektów
Uczestnik projektów
Uczestnik projektów
Uczestnik projektów
Uczestnik projektów
09-01-2013
oceń pozytywnie 0
Bardzo fajny artykuł.
Marcin Krzanowicz
Marcin Krzanowicz
2131 pkt.
Guru
10-01-2013
oceń pozytywnie 0
Dziękuję. Cieszę się, że się podoba ;)
T F
T F
369 pkt.
Junior
10-01-2013
oceń pozytywnie 0
Fajny artykuł. Można sobie przypomnieć i usystematyzować wiedzę o GPO.
Rafał Kucharski
Rafał Kucharski
370 pkt.
Junior
22-01-2013
oceń pozytywnie 0
Dziękuję za ciekawy art. Czy myślałeś, aby kontynuować go? Powiedzmy "Badanie/Analiza wydajności przetwarzania GPO i GPP".
secretservice
secretservice
0 pkt.
Nowicjusz
01-11-2013
oceń pozytywnie 0
Ciekawy artykuł, tylko najgorsze jest to, że w tym portalu nie da się nic wydrukować. A nie każdy ma dar do czytania na ekranie długich tekstów. Pozdrawiam
pkt.

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.