Elementy GPO, czyli Group Policy Objects, cz. I
Jak powstają GPO
 |
Zawartość strony
 | Wstęp |
| Powstawanie GPO |
| Nowy format szablonów |
| Struktura GPC |
| Struktura GPT |
| Szablony administracyjne |
| Podsumowanie części I |
| Przeczytaj pozostałe części tego artykułu |
Wstęp
1700, 2500 – imponujące liczby, prawda? Co oznaczają? W przybliżeniu są to liczby domyślnych ustawień, które można skonfigurować w Windows XP i Vista za pośrednictwem Group Policy Objects, czyli w skrócie GPO. W Windows Server 2008 liczba ta jeszcze wzrośnie. Cóż można chcieć więcej? Chyba tylko to, żeby działały tak jak sobie to wymarzyliśmy. Ale spokojnie, w tym artykule nie poddamy drobiazgowej analizie działania każdego z ustawień. Celem tego artykułu będzie natomiast przedstawienie nieco szczegółowiej podstawowej struktury, na której GPO opiera swoje działanie. Bo to właśnie poprawne działanie tej struktury zapewnia, że każde z 2500 ustawień może również spełniać swoje zadanie. Będzie to GPO nieco od środka, ze szczególnym uwzględnieniem nowości wprowadzonych w systemach Vista i Windows Server 2008.
Powstawanie GPO
GPO, jak część osób czytających ten artykuł już pewnie wie, można tworzyć na kilku poziomach, (które to poziomy zresztą wyznaczają również kolejność ich wykonywania):
| • | lokalnym (by w Vista zapewnić większą centralną kontrolę nad GPO wprowadzono możliwość całkowitej blokady GPO lokalnych; służy temu ustawienie w GPO „Turn off local Group Policy objects processing”), |
| • | lokacji, |
| • | domeny, |
| • | jednostki organizacyjnej. |
Poziomy te określają zasięg, jak i różnicują możliwości GPO. Albowiem nie wszystko to, co możemy ustawić na poziomie np. domeny jest do zrealizowania na poziomie lokalnym. Choć w porównaniu do poprzednich systemów, w Windows Vista i tak usunięto pewne niedoskonałości.
Tworząc GPO lokalnie w Vista mamy większą swobodę w określaniu, kogo ono ma dotyczyć. Dzięki temu nie musimy już stosować różnych rozwiązań „zastępczych”, jak choćby opisanego w artykule: http://support.microsoft.com/kb/325351.
Ponieważ Vista przyniosła ze sobą pewne zmiany w zakresie lokalnych GPO, przypomnijmy zatem pokrótce, na czym one polegały, zanim przejdziemy do omawiania GPO z punktu widzenia jego struktury.
W edytorze zasad możemy wybrać, czy dane GPO ma obejmować: komputer, administratorów, użytkowników niebędących administratorami, czy też konkretnego użytkownika.
Nagięto nieco podstawową zasadę, że GPO nie jest stosowane do grup. A zrobiono to w odniesieniu do administratorów i do użytkowników niebędących administratorami. Prawdopodobnie dlatego, że przynależność do obu grup równocześnie ewidentnie się wyklucza.
Powstałe w ten sposób GPO w zależności, kogo dotyczyło, można znaleźć w Vista już nie jak w poprzednich systemach tylko w katalogu Windows\system32\GroupPolicy, ale w katalogach:
| • | \windows\system32\GroupPolicy – ustawienia dotyczące komputera jak i wszystkich użytkowników; |
| • | \windows\system32\GroupPolicyUsers – ustawienia dotyczące poszczególnych użytkowników jak i grup wspomnianych powyżej (administratorów i użytkowników niebędących administratorami). |
Ponieważ teraz zasad GPO może być kilka, przy ich stosowaniu zostaje zachowana pewna kolejność:
| • | lokalne zasady komputera; |
| • | lokalne zasady obowiązujące wszystkich użytkowników; |
| • | lokalne zasady obejmujące administratorów lub użytkowników innych niż administratorzy; |
| • | lokalne zasady obowiązujące konkretnego użytkownika. |
W przypadku konfliktu ustawienia stosowanej zasady, ustawiona jako ostatnia wygrywa.
Dodatkowo szablony administracyjne i administracyjne admx oraz odpowiednio powiązane pliki językowe adml znajdują się w katalogu \windows\PolicyDefinitions. Teraz te dwa rodzaje szablonów, tak jak kiedyś szablony adm, pozwalają nam kontrolować ustawienia rejestru.
Nowy format szablonów
Jak wspomniano, w Vista zmienia się format stosowanych szablonów administracyjnych. Nowe szablony admx oparte o XML zapewniają o wiele większą elastyczność edycji, jak i w połączeniu z adml pozwalają na szybkie konwersje językowe. Jeśli jednakże dalej z jakiś szczególnych powodów pozostawimy stare szablony adm, Vista również będzie w stanie z nich skorzystać. Ale obowiązuje tu jedna wyjątkowa zasada, dotycząca tzw. szablonów domyślnych. Jeśli będzie to szablon domyślny, to Vista ustawień takiego szablonu nie zobaczy.
Wspomniane wcześniej szablony admx zresztą nie tylko znajdują zastosowanie na poziomie lokalnym, ale również oczywiście mogą być wykorzystane na poziomie lokacji, domeny czy jednostki organizacyjnej w przypadku Windows Server 2003 czy też Windows Server 2008. I właśnie tutaj, na tych trzech poziomach, można wykorzystać pełne możliwości GPO.
Prześledźmy, zatem na przykładzie jednego z tych poziomów, co się tak naprawdę dzieje, gdy tworzone jest nowe GPO. Następujący ciąg zdarzeń można podzielić dwutorowo: na te związane z częścią GPT (Group Policy Template) i częścią GPC (Group Policy Container).
Struktura GPC
Część GPC danej zasady możemy znaleźć w strukturze AD w kontenerze o nazwie System\Policies. Znajdują się tu numery GUID poszczególnych GPO (z późniejszym podziałem na część komputera i użytkownika). Jest to miejsce gdzie GPO przechowuje konfigurację związaną z Active Directory.
GPC wskazuje też na powiązaną z nim część GPT. Każde GPC zawiera pewne atrybuty (widoczne po użyciu opcji ADSI Edit), z których najbardziej charakterystyczne to:
| • | versionNumber – określa numer wersji GPO jednocześnie dając możliwość określenia stopnia synchronizacji z częścią GPT; |
| • | gPCMachineExtensionNames - lista zastosowanych CSE, odnosząca się do ustawień komputera (więcej o znaczeniu CSE w dalszej części artykułu); |
| • | gPCUserExtensionNames – lista zastosowanych CSE, odnosząca się do ustawień użytkownika (więcej o znaczeniu CSE w dalszej części artykułu); |
| • | gPCFileSysPath – wskazuje położenie części GPT w katalogu sysvol; |
| • | gPCWQLFilter – wskazuje na zastosowany filtr WMI. |
Rys. 1. Atrybuty Group Policy Container.
Atrybuty te pozwalają określić zarówno stan danego GPO, jak i powiązania z innymi elementami niezbędnymi do jego przetworzenia.
Zacznijmy od numeru wersji, czyli atrybutu „versionNumber”. Na jego podstawie można określić liczbę zmian w części użytkownika i komputera. Załóżmy, że liczba zmian dotycząca użytkownika to 2, a komputera 8. Po sprowadzeniu do formatu heksadecymalnego otrzymujemy: 00020008 co dziesiątkowo daje 131080, czyli dokładnie liczbę na rysunku powyżej.
Liczbę tą można przekształcić na postać dziesiętną korzystając ze wzoru:
wersja = 65536 * (liczba zmian w części użytkownika) + liczba zmian w części komputera
czyli:
numer wersji=65536*2+8= 131080
Rys. 2. Group Policy Management Console.
Widzimy tu liczbę zmian w części użytkownika i komputera, z podziałem na część GPC czyli tu symbolizowaną skrótem AD i część GPT czyli tu sysvol.
Oprócz kontenera Policies możemy również znaleźć kilka innych powiązań ze składnikami GPO a mianowicie:
| • | atrybut gPLink – skojarzony z takimi obiektami jak domena, lokacja czy jednostka organizacyjna, określający listę GPO skojarzonych z danym obiektem, wymienionych w kolejności w jakiej są wykonywane; |
| • | gPOptions – określa czy dany obiekt ma włączone dziedziczenie, czy też jest ono zablokowane; |
| • | Default Domain Policy zawierający kontener AppCategories, będący częścią mechanizmu związanego z gałęzią GPO Software Installation; |
| • | IP Security – wskazuje ustawienia IPSec powiązane z GPO; |
| • | WMIPolicy – określa filtry WMI, które mogą być użyte do GPO; GPO jest z nimi powiązane za pośrednictwem atrybutu gPCWQLFilter; dokładnie filtry te znajdują się w kontenerze System/WMIPolicy/SOM. |
Struktura GPT
Tyle na razie o GPC. Część GPT określa już konkretne ustawienia komputera lub użytkownika. Reprezentowana jest w katalogu \\domain_name\Sysvol\domain_name\Policies poprzez podkatalog o nazwie odpowiadającej numerowi GUID nowego GPO. I w nim znowu podobnie jak w części GPC można znaleźć podkatalogi, odpowiednio w odniesieniu do części ustawień użytkownika i komputera.
Struktura ta wygląda następująco:
| • | GPT.ini – najważniejszą rzeczą w nim umieszczoną jest numer wersji; jest to numer obliczany analogicznie jak w przypadku atrybutu versionNumber części GPC; ewentualne rozbieżności w wartościach tych numerów, jak już wspomniano, wynikają zwykle z odrębnego procesu synchronizacji dla obu części GPO; i tu jeszcze dodatkowa uwaga, iż w przypadku GPO lokalnego zawiera dodatkowo:
| ||||||||||||
| • | Machine:
| ||||||||||||
| • | User:
| ||||||||||||
| • | \User\Microsoft\IEAK – ustawienia Internet Explorer; | ||||||||||||
| • | \Microsoft\RemoteInstall – przechowuje opcje związane z instalacją za pośrednictwem RIS (odpowiedzialny jest za to plik OSCfilter.ini). |
Szablony administracyjne
Jednym z najważniejszych elementów stosowanych w GPO są szablony administracyjne. W poprzednich systemach szablony te przechowywane były w folderze Windows\inf.
W Vista zaszły w odniesieniu do nich pewne zmiany. Oprócz już wspomnianych wcześniej, możliwe staje się też wykorzystanie tzw. centralnego punktu składowania szablonów. Wymaga to umieszczenia na kontrolerze domeny w katalogu %systemroot%\sysvol\domain\policies\PolicyDefinitions odpowiednich szablonów admx, a następnie utworzenia w tymże katalogu podkatalogów powiązanych z odpowiednimi wersjami językowymi. Przy edycji GPO w pierwszej kolejności, Vista automatycznie posłuży się tymi szablonami. Dopiero gdyby takiego centralnego punktu nie było, system posłuży się szablonami lokalnymi.
Takie podejście do szablonów administracyjnych zmniejsza wielkość katalogów przechowujących GPO. Dotychczas użyte w danej zasadzie szablony stawały się częścią GPO, zwiększając tym samym rozmiar GPO. Ponieważ folder sysvol podlega replikacji, generowało to dodatkowe nakłady z nią związane. A tak naprawdę, szablony po ich zastosowaniu w celu edycji ustawień nie są nam już do niczego potrzebne (poza ewentualną oczywiście dalszą edycją). Same ustawienia, które z ich pomocą skonfigurowaliśmy, jak wspomniano wcześniej, znajdują się w pliku registry.pol.
Po co więc niepotrzebnie mnożyć szablony duplikując je w każdym GPO?
Podsumowanie części I
Tyle na temat podstawowych powiązań GPC i GPT. Nie można jednak pominąć faktu, że przy tworzeniu GPO możemy dużo dalej zaingerować w pewne domyślne mechanizmy wykonywania GPO. Można tego dokonać na przykład przez ustawienie „Enforcend” (wymusza stosowanie ustawień danego GPO) lub „Block inheritance” (blokuje dziedziczenie GPO). Działanie GPO może również być modyfikowane przez odpowiednie nadawanie uprawnień do stosowania GPO (konieczne do zastosowania to „Apply” i „Read”) oraz poprzez odpowiednie filtry WMI, czy też zastosowanie tzw. sprzężenia zwrotnego (ang. loopback). Możliwości jak widać jest dość dużo i dlatego ich omówienie to szerszy temat, wymagający raczej odrębnego artykułu.
Przeczytaj pozostałe części tego artykułu
| • |
 | Barbara Wróbel |