Mechanizm loopback, czyli w tłumaczeniu polskim mechanizm sprzężenia zwrotnego nie jest czymś szczególnie nowym. Jest jednak na tyle według mnie oryginalny, że sądzę, iż warto mu się bliżej przyjrzeć.
Dlaczego? Bo tak naprawdę łamie podstawową zasadę GPO (Group Policy Objects), która mówi, że komputery przetwarzają to co w gałęzi GPO „Computer configuration" a użytkownicy to co w gałęzi „User configuration".
Mechanizm loopback, czyli w tłumaczeniu polskim mechanizm sprzężenia zwrotnego nie jest czymś szczególnie nowym, bo obsługiwany jest już począwszy od systemów Windows 2000 Server i Professional. Jest jednak na tyle według mnie oryginalny, że sądzę, iż warto mu się bliżej przyjrzeć.
Dlaczego? Bo tak naprawdę łamie podstawową zasadę GPO (Group Policy Objects), która mówi, że komputery przetwarzają to co w gałęzi GPO „Computer configuration" a użytkownicy to co w gałęzi „User configuration".
A wszystko to po to, by jak sugeruje już tytuł tego artykułu „wszyscy byli równi" - choć i tak jak to w życiu bywa na końcu okaże się, że niektórzy mogą być „równiejsi" ;)
Działanie
Przejdźmy zatem do tego na czym polega mechanizm loopback. W dużym skrócie na tym, że komputerowi wydaje się, że jest użytkownikiem i dlatego przetwarza część GPO związaną z gałęzią „User configuration". Standardowo ta część GPO przetwarzana jest wyłącznie w odniesieniu do użytkownika.
Jak możemy wykorzystać efekty tak nietypowego zachowania? W jednym prostym celu, by zapewnić, że dane ustawienie standardowo odnoszące się do użytkownika na wybranym komputerze zawsze będzie miało tę samą wartość bez względu na to kto się zaloguje.
Miejscem wprost wymarzonym, gdzie coś takiego może się przydać jest na przykład środowisko usług terminalowych. Jeśli chcemy, by logując się do konkretnego serwera terminalowego, wszyscy użytkownicy mieli te same ustawienia związane na przykład z widocznością elementów menu start loopback nam to umożliwi.
Ale dosyć teorii, bo żeby naprawdę zrozumieć jak działa loopback trzeba na niego spojrzeć praktycznie. Najlepiej do tego posłużą konkretne przykłady, dzięki którym prześledzimy dwa tryby działania loopback:
- Replace (tryb zastępowania)
- Merge (tryb scalania)
Obydwa z nich możliwe są do skonfigurowania za pomocą ustawienia GPO w gałęzi Computer Configuration -> Administrative Templates -> System -> Group Policy ->User Group Policy loopback processing mode.
Polisę z tym GPO należy następnie podpiąć pod kontener zawierający konto komputera podlegającego loopback.
Wcześniej jednak, w celu prześledzenia przykładowego działania, określmy strukturę naszych GPO.
Powyżej jednostka organizacyjna „użytkownicy" zawiera konta użytkowników, natomiast jednostka „komputery" konta komputerów. Pod obie jednostki podpięto odpowiednio polisy: GPO_komputery oraz GPO_użytkownicy. Dodatkowo przy przetwarzaniu polis uwzględnimy domyślną polisę domenową "Default Domain Policy".
Ważne jest też, aby pamiętać, że loopback nie wpływa na przetwarzanie ustawień gałęzi „Computer configuration" - te wykonywane są według standardowych zasad działania zasad grup. W poniższych rozważaniach analizujemy wyłącznie przetwarzanie gałęzi "User configuration".
Replace
Pierwszą możliwą, prostszą opcją jest Replace - kiedy to konfiguracja przypisana pod komputer całkowicie nadpisuje konfigurację użytkownika.
W tej sytuacji polisy dotyczące użytkowników nie są przetwarzane. W zamian za to przetwarzane są ustawienia gałęzi „User configuration" z GPO komputera. W takim przypadku polisy są wykonywane w poniższej kolejności:
- Default Domain Policy
- GPO_komputery (ustawienia z „User configuration"!)
I na tym kończymy przetwarzanie. GPO powiązane z użytkownikiem już nas nie interesuje - jest całkowicie pomijane w przetwarzaniu.
Czyli już całkiem "praktycznie" mamy ustawione następująco polisy:
1. GPO_komputery:
User Group Policy loopback processing mode - Replace
Prohibit access to the Control Panel - Enabled
2. GPO_użytkownicy
Prohibit access to the Control Panel - Disabled
Remove Recycle Bin icon from desktop - Enabled
Wynik przetwarzania powyższych polis to:
User Group Policy loopback processing mode - Replace
Prohibit access to the Control Panel - Enabled
Merge
W przypadku drugim - Merge - gdy konfiguracja komputera łączy się z konfiguracją użytkownika najpierw przetwarzane są GPO użytkownika, a dopiero potem komputera - w przypadku konfliktu ustawienia „User configuration" GPO komputera mają wyższy priorytet. Wynika to z domyślnej zasady działania polis, która mówi, iż ustawienia GPO przetwarzanego jako ostatnie wygrywają.
Po włączeniu loopback w trybie merge, w tej samej strukturze, przetwarzanie odbywa się w kolejności:
- Default Domain Policy
- GPO_użytkownicy
- Default Domain Policy
- GPO_komputery (ustawienia z „User configuration"!)
Warto zauważyć, że w przypadku „Merge" tworzy się jeszcze jedna nietypowa a wręcz niebezpieczna sytuacja (jeśli wcześniej nie przewidzimy jej efektów). Jak widać powyżej jedna z polis, a mianowicie "Default Domain Policy", wykona się dwa razy. Za drugim razem złamie schemat działania GPO związany z kolejnością przetwarzania, co w pewnej sytuacji może przynieść niepożądany efekt.
Zobaczmy dlaczego. Otóż gdyby zawierała ona ustawienie GPO sprzeczne z analogicznym w polisie GPO_użytkownicy to ustawienie to by wygrało. Wynika to z tego, że po raz drugi wykonywana jest później od polisy GPO_użytkownicy przez co nadpisuje ustawienia tej polisy w sytuacji konfliktu. Normalnie takie nadpisanie ustawień polisy o niższym priorytecie ustawieniami polisy w strukturze domeny przecież wyższej miałoby miejsce tylko w sytuacji zastosowania opcji „Enforce". Tutaj i bez ustawionego "Enforce" możemy w wyniku działania polis w trybie loopback Merge uzyskać taki niespodziewany rezultat. Należy więc uważać.
Ponownie na przykładzie powyższych ustawień zobaczmy wynik działania tym razem Merge. Mamy ustawione:
GPO_komputery:
User Group Policy loopback processing mode - Merge
Pozostałe ustawienia bez zmian i w wyniku otrzymujemy:
User Group Policy loopback processing mode - Merge
Prohibit access to the Control Panel - Enabled
Remove Recycle Bin icon from desktop - Enabled
Przypadki specjalne
Jak widać działanie loopback jest dość bezwzględne, bo dotyczy wszystkich użytkowników na danym komputerze, w tym domyślnie stosuje się również do administratorów domenowych.
Administrator domenowy to jednak zwykle osoba, która choć nieraz stanowcza dla użytkowników, sama ograniczenia źle znosi ;).
Co zatem zrobić by administrator domenowy poczuł się wyjątkowo logując się na serwer poddany loopback? Trzeba go z działania tego mechanizmu wykluczyć. W pierwszej chwili brzmi prosto. Po chwili namysłu jednak uświadamiamy sobie, że chyba nie tak łatwo to zrobić skoro ustawienia ograniczające użytkownika są podpięte nie pod kontener zawierający użytkowników a komputery.
Jest tu jednak pewien haczyk :), wynikający z dość zaskakującego mechanizmu uprawnień niezbędnych do przetwarzania polisy komputera w takim przypadku.
Otóż pomimo że GPO dotyczy komputera (na naszym przykładzie GPO_komputery) to jego przetwarzanie odbywa się z wykorzystaniem praw użytkownika, który się loguje.
Czyli jeśli na przykład użytkownik Jaś Fasola loguje się na serwer terminali to, by ustawienia „User Configuration" polisy GPO_komputery, przetwarzane na skutek jego zalogowania zadziałały, Jaś musi mieć odpowiednie uprawnienia do tej polisy. Uprawnienia te to jak w przypadku każdej zwykłej polisy „Read" i „Apply". Domyślnie ma je, bo należy do grupy "Authenticated users", która to grupa standardowo ma je przypisane.
A teraz załóżmy, że wspomniany użytkownik to administrator domenowy (wiem, wizja dość przerażająca ;), który nie chce by do niego stosowały się ustawienia „User Configuration" polisy GPO_komputery. Chyba już jasne co zrobić by mu to umożliwić? Wystarczy odebrać mu prawo „Apply" do tej polisy. Polisa nie zostanie zastosowana - Jaś szczęśliwy :) - cel osiągnięty.
Na koniec jeszcze jedna kwestia. Jeśli ktoś czytał uważnie, zauważył pewnie, że pisząc „administrator", za każdym razem było dodawane słówko "domenowy". Stało się tak z jednego prostego powodu. Loopback nie dotyczy użytkowników lokalnych (w tym też również oczywiście administratorów lokalnych). I znowu to kwestia uprawnień, czyli tego, że użytkownicy lokalni nie mają przyznanego prawa "Apply" ("Read" zresztą też) do polisy w looback. Stąd tak ważne jest by jeśli stosujemy mechanizm loopback, koniecznie w tym celu wykorzystywać konta domenowe użytkowników.
Podsumowanie
Jak widać mechanizm loopback, pomimo że możliwy do włączenia poprzez jedno proste ustawienie w GPO ma pewne specyficzne aspekty działania, które trzeba przemyśleć przed wdrożeniem. Chyba jednak warto, by móc potem w środowisku serwera terminalowego czy stacjach typu "kiosk" ograniczać do woli użytkowników nie robiąc jednak krzywdy na przykład sobie. :)
Autor:
Barbara Wróbel (basiaw7)
(MCT, MCITP: Enterprise Administrator, MCSE+M+S)
Redaktor portalu wss.pl Trener w ABC Data Centrum Edukacyjne. Prowadzi blog. Członek SE Club.