[ Pobierz całość w formacie PDF ]
.Chcąc to zmienić, należy otworzyć deskryptor zabezpieczeń dla GPO i dodać odpowiedniej grupie uprawnienia do stosowania Zasad grup.lProszę dobrze uświadomić sobie, czym jest obiekt Zasad grup.GPO jest obiektem Active Directory, który można przydzielić do jednego lub więcej kontenerów SDOU, przy czym z jednym kontenerem SDOU można powiązać wiele GPO.To znaczy, GPO jest obiektem zawierającym specyfikację pewnych zasad, które można zastosować do jednego lub wielu kontenerów SDOU — i na odwrót.Zasady grup to bardzo elastyczne narzędzie, którego można używać w różnych kombinacjach, co pozwala na spełnienie różnorodnych wymagań przedsiębiorstwa.Najważniejszym środkiem ostrożności jest używanie najprostszych możliwych kombinacji tych możliwości i rozważne planowanie ich użycia.Podczas planowania Zasad grup należy przynajmniej trzymać się bardzo ścisłych wytycznych, dotyczących obszarów zarządzania — czy stosować model scentralizowany, model delegowania administracji czy kombinację obu.Potrzebne są tutaj również decyzje dotyczące delegowania pełnomocnictw i rozdziału zadań administracyjnych.Następny podrozdział koncentruje się na tych zagadnieniach.Obszar zarządzaniaPodczas projektowania Active Directory i wyboru metod stosowania Zasad grup w organizacji należy przemyśleć i podjąć decyzje o tym, jak potraktować poniższe zagadnienia:lAdministracja centralna czy rozproszona.llDelegowanie pełnomocnictw.llRozdział zadań administracyjnych.llElastyczność projektu.llWpływ projektu na wydajność.lPierwsze cztery czynniki mogą być obrócone w pytania, jak potraktować zasadnicze założenia projektu, jak poniżej:lCzy zastosować projekt warstwowy czy monolityczny.llCzy stosować w projekcie pojedyncze zasady, czy zestawy.llCzy projektować według podziału na role czy na zespoły.llCzy użyć delegowania OU z zarządzaniem centralnym czy rozproszonym.lProjekt warstwowy czy monolityczny?Przy podejmowaniu decyzji o podstawowym schemacie GPO, zasadniczo mamy wybór pomiędzy tworzeniem GPO według warstw (na każdym poziomie hierarchii SDOU stosowane odrębne GPO) a tworzeniem GPO według modelu monolitycznego (pojedynczy GPO dla każdego kontenera, obejmujący większość zasad dotyczących obiektów w danym kontenerze).Projekt warstwowy (patrz rysunek 10.3) jest bardziej elastyczny i udostępnia bardziej szczegółowe zabezpieczenia — ponieważ większość zasad jest dziedziczonych, przez co zazwyczaj wystarcza ich zmiana w jednym miejscu; podczas gdy projekt monolityczny (patrz rysunek 10.4) jest łatwiejszy do zrozumienia i obróbki.Rysunek 10.3W warstwowym projekcie GPO można stosować GPO na kilku (lub wszystkich) poziomach organizacji SDOUBase GPOPodstawowy GPOEngineering GPOGPO działu technologicznegoResearch GPOGPO działu badawczegoSales GPOGPO działu sprzedażyRysunek 10.4W monolitycznym projekcie GPO dla każdego obiektu SDOU można zamiast dziedziczenia stosować odrębny GPO; wspólne ustawienia powtarzane są we wszystkich GPONo GPOBrak GPOEngineering GPOGPO działu technologicznegoResearch GPOGPO działu badawczegoSales GPOGPO działu sprzedażyW warstwowym projekcie GPO w pierwszej kolejności należy utworzyć podstawowy GPO, przeznaczony do zastosowania w domenie i zawierający wspólne ustawienia zasad dla użytkowników i komputerów w tej domenie.Następnie można tworzyć dodatkowe GPO, dopasowane do wymagań każdej jednostki funkcjonalnej (OU).W projekcie warstwowym wystarczy zmienić jeden lub kilka GPO, aby wymusić zmiany.Administracja jest przez to uproszczona kosztem szybkości logowania i ryzyka pogubienia się w szczegółach.Można ponadto oddelegować zarządzanie poszczególnych GPO do lokalnych administratorów.W monolitycznym projekcie GPO należy dążyć do umieszczenia wszystkich zasad grup w jak najmniejszej liczbie GPO (w idealnym scenariuszu, w pojedynczym GPO).Projekt taki daje najkrótszy czas logowania, ponieważ dla każdego użytkownika przetwarzanych jest mniej GPO.Jego wadą jest stosunkowy brak elastyczności, ponieważ delegowanie pełnomocnictw jest zasadniczo niemożliwe.Ponadto trudniej jest zaprowadzić zmiany zasad na skalę korporacji, oraz panować nad anarchią, która czyha w zakamarkach każdej instalacji (z powodu nieodłącznego ryzyka dokonania odmiennych zmian w GPO dotyczących tego samego typu obiektu, jak również ryzyka gwałtownego wzrostu ilości GPO, przeznaczonych do obsługi wyjątków na poziomie OU).Wybór projektu zasad jednorodnych lub mieszanychDecydując o projekcie stosowania zasad, można wybierać pomiędzy projektem zasad jednorodnych i projektem zasad mieszanych.Projekt zasad jednorodnych (patrz rysunek 10.5) umożliwia centralizację i precyzyjny podział delegowania administracyjnego, natomiast projekt mieszany (patrz rysunek 10.6) pozwala na szybsze przetwarzanie i ułatwia rozwiązywanie problemów.Rysunek 10.5W projekcie zasad pojedynczych każdy GPO zawiera zasady jednego typuSoftware GPOGPO oprogramowaniaSecurity GPOGPO zabezpieczeńSalesDział sprzedażyRysunek 10.6W projekcie zasad wielokrotnych w każdym GPO znajdują się wszystkie stosowane zasadySalesDział sprzedażySoftware, Script and Security GPOGPO oprogramowania, skryptów i zabezpieczeńW projekcie zasad jednorodnych w każdym GPO umieszczane są tylko zasady jednego typu.Na przykład, zasady instalacji oprogramowania i zasady skryptów posiadałyby odrębne GPO.W tego typu projekcie można ograniczyć dostęp do każdego GPO do mniejszej liczby administratorów (ponieważ odrębnymi zasadami często zajmują się różni pracownicy)
[ Pobierz całość w formacie PDF ]