De Loopback Group Policy

Afgelopen week had ik een mooie uitdaging in een groot AD domein. Nou ja, uitdaging. Zeg maar gerust een digitale puzzel van 1000 stukjes. Het AD domein had nog enige structuur maar de group policies waren een stuk minder gestructureerd. Na wat uitzoekwerk toch wat meer structuur gebracht. Dit betekend meer globale policies en veel minder losse policies. De ruim 200 group policies hadden we teruggebracht naar 120 group policies. Echter werkte alles nog niet naar behoren. Het probleem zat hem in de loopback policies welke op diverse locaties waren toegepast. Het globale idee van de loopback policy is me wel duidelijk maar omdat dit wat meer verdieping vereiste heb ik exact uitgezocht hoe de loopback policy te werk gaat. En dat wil ik jullie uiteraard niet onthouden.

De loopback policy zorgt vaak voor verwarring. Wat doet het exact en hoe beïnvloed dat de andere policies. Hier komen we zo aan toe. Laten we eerst eens kijken waar we de loopback policy kunnen vinden.

Binnen de Group Policy Microsoft Management Console (MMC) klik je op Computer Configuration en je vouwt deze tree verder uit via: Administrative Templates – System – Group Policy. Hier vindt je de “Configure User Group policy loopback processing mode”.

Door deze modus te activeren wordt de loopback functionaliteit geactiveerd. Nou, wat wil dit exact zeggen.

De loopback policy zorgt ervoor dat alleen settings worden doorgevoerd op basis van de computer. User policies gebaseerd op user niveau worden nu niet doorgevoerd. De loopback policy wordt dus voornamelijk gebruikt om usersettings toe te passen op computer objecten zonder dat de usersettings gekoppeld zijn aan de policies welke gekoppeld zijn aan de OU van de ingelogde gebruiker.

Deze functie is vooral handig in grote organisaties. Bij een klein domein heb je gemakkelijk de volledige controle over alle groepsbeleidsinstellingen in het domein, inclusief de mogelijkheid om een goed en gescheiden computer- en gebruikersbeleid te maken en aan te passen. Als je echter een grote Active Directory omgeving hebt met bijvoorbeeld meerdere domeinen en sites kan het zijn dat je slechts de groepsbeleidsobjecten van één domein of alleen van een enkele OU kunt beheren. Het kan dan zomaar zijn dat je geen controle hebt over de rechten welke toegekend zijn aan gebruikersaccounts maar wel controle hebt over het beleid dat is toegewezen aan een computers OU.

Een loopback policy wordt dan ook vaak gebruikt bij terminal servers. Stel je voor dat een user inlogt welke op de OU waarin het user account zich bevindt een policy heeft staan om “redirection” te activeren. Het kan zomaar zijn dat je dit op je terminal server niet wilt hebben. In dat geval zet je op de GPO welke gebonden is aan de terminal server de loopback policy aan. Deze user setting zal nu niet doorgevoerd worden op de terminal server. De loopback policy kan ook gebruikt worden om alle medewerkers op een specifieke fysieke locatie toegang te geven tot een specifieke printer welke alleen op die locatie beschikbaar is.

Ok, dan nu iets meer uitleg.

Een group policy heeft 2 onderdelen:

• User Configuration – Deze policies worden toegepast als de gebruiker waarmee ingelogd wordt deze policies toegewezen heeft gekregen. Dit is ongeacht op welke computer ingelogd wordt. Alleen user objecten kunnen settings uit “user configuration” verwerken.
• Computer Configuration – Deze policies worden toegepast als men inlogt op de computer waar deze policy op van toepassing is. Dit is ongeacht welke gebruiker er inlogt. Alleen computer objecten kunnen settings uit “computer configuration” verwerken.

Stel je voor dat je 2 policies hebt. 1x een policy genaamd “C” welke is toegepast op de computer OU en 1 welke genaamd is “U” welke is toegepast op de user OU. Beide policies hebben zowel regels in de Computer als in de User configuration staan.

Als er een gebruiker inlogt met een gebruikersnaam welke zich in de user OU bevindt (U policy) op een PC welke zich in de computer OU bevindt (C policy) dan zullen de policies als volgt worden toegepast:

• User Configuration – U Policy
• Computer Configuration – C policy

De gebruiker krijgt dus de user configuration van de user policy (U) en de computer configuration van de computer policy (C).

Op het moment dat we de loopback policy activeren op de C group policy zal de gebruiker de volgende configuraties toegewezen krijgen:

• User Configuration – C Policy
• Computer Configuration – C policy

De loopback policy geeft je echter 2 opties, namelijk “Merge” en “Replace”. Bovenstaande scenario is waar als de loopback policy op “Replace” staat. Hierbij wordt de configuratie vervangen. Als de policy op “Merge” had gestaan dan werden de policy configurations als volgt toegepast:

• + User Configuration – U Policy
• User Configuration – C Policy
• Computer Configuration – C policy

Met de “Merge” optie worden de user configuration settings uit beide policies (C + U) samengevoegd en toegepast. Als er zich echter een conflict voordoet tussen de user configurations dan zal de setting van de user configuration in de C policy worden doorgevoerd. Als “Merge” is ingeschakeld wint de setting in de user configuration van de C policy het dus van de U policy.

GPO Normale volgorde van uitvoeren

Om een wat geavanceerder voorbeeld te geven is het goed om even wat verder uit te zoomen. In bovenstaande voorbeeld hadden we slechts 2 relevante OU’s en op iedere OU werd 1 policy toegepast. Dat is relatief simpel. Maar voor een wat complexer voorbeeld moeten we even gaan kijken naar de complete volgorde waarin GPO’s worden uitgevoerd.

Group Policies worden normaliter als volgt uitgevoerd waarbij de settings van hoog naar laag worden doorgevoerd. Als er een conflict is tijdens de uitvoering van settings dan wint de setting in een lagere OU het van de hogere OU omdat deze later wordt uitgevoerd. De volgorde volgt dus de boomstructuur:

• Local Group Policy (op de computer)
• Site GPO
• Domain GPO
• Parent OU GPO
• Actual OU GPO

Als er zich vervolgens meedere group policies bevinden in een OU dan is de “link order” belangrijk voor de uitvoering. Group policies worden uitgevoerd met een link order van hoog naar laag. De group policy met link order 1 wordt later uitgevoerd dan nummer 5 en als settings conflicteren werken dus de settings van de group policy op nummer 1.

Group policies worden standaard geërfd. Als een policy op een hoger niveau een computersetting heeft dan wordt deze toegepast op alle computers in onderliggende OU’s. Uiteraard kun je dit blokkeren door op en OU “inheritance” te blokkeren:

Vervolgens kunnen we ook nog een policy forceren:

Wanneer een policy geforceerd wordt, worden de settings uitgevoerd zelfs als “block inheritance” op een OU is ingesteld. Enforcement gaat dus boven blocking. Ook zal bij een conflict tussen de settings in 2 policies altijd de “enforced policy” winnen.

Nu een wat geavanceerde scenario:

• Domain OU – Policy 1 (P1) met computer configuration en user configuration.
• Parent OU – Policy 2 (P2) met computer configuration en user configuration.
• User OU – Policy 3 (P3) + Policy 4 (P4) met user configuration.
• Computer OU – Policy 5 (P5) met computer configuration en user configuration.

User OU en Computer OU zijn directe OU’s onder “Parent OU”. In dit voorbeeld zijn dus 5 policies in place. Policy 3 heeft lagere link order dan policy 4. We gaan ervan uit dat de user die inlogt, inlogt met een user account uit de “User OU” op een computer in de “Computer OU”.

Zonder loopback worden deze in de volgende volgorde doorlopen:

• P1 – user configuration
• P2 – user configuration
• P3 – user configuration
• P4 – user configuration
• P1 – computer configuration
• P2 – computer configuration
• P5 – computer configuration

Indien er in bovenstaande voorbeeld conflicten optreden (user of computer) dan overruled de policy die het verste onderaan staat de andere policy omdat deze als laatste wordt uitgevoerd.

We zien ook in dit voorbeeld dat bij een conflict altijd de computer configuratie de user configuratie overschrijft. Dus als P2 en P5 een conflict hebben dan overruled de setting in P5.

Nu het volgende scenario met loopback geactiveerd in “replace” mode:

• Domain OU – Policy 1 (P1) met computer configuration en user configuration.
• Parent OU – Policy 2 (P2) met computer configuration en user configuration.
• User OU – Policy 3 (P3) + Policy 4 (P4) met user configuration.
• Computer OU – Policy 5 (P5) met computer configuration + LOOPBACK en user configuration.

Doordat loopback geactiveerd is worden de volgende policies toegepast:

• P5 – user configuration
• P1 – computer configuration
• P2 – computer configuration
• P5 – computer configuration

Maar als de loopback policy op “merge” had gestaan dan zouden de policies als volgt uitgevoerd worden:

• P1 – user configuration
• P2 – user configuration
• P3 – user configuration
• P4 – user configuration
• P5 – user configuration
• P1 – computer configuration
• P2 – computer configuration
• P5 – computer configuration

Conclusie

De toepassing van een loopback policy is dus best simpel.

Normaliter worden user policies (user configuration opties in een policy) toegepast op een gebruikersobject. De user policies die toegepast worden zijn afkomstig van de GPO’s welke actief zijn op de OU van de user + bovenliggende OU’s.

Een computer krijgt normaliter alleen computer polcies (computer configuration opties in een policy) toegepast op een computersobject. De computer policies die toegepast worden zijn afkomstig van de GPO’s welke actief zijn op de OU van de computer + bovenliggende OU’s.

Wanneer “loopback processing” actief is (en de loopback policy dus is geactiveerd) dan kunnen user policies (user configuration settings in een policy) toegepast worden op een computerobject. Wanneer de “replace” optie gebruikt wordt dan worden alle user policies (user configuration settings in de policies welke aan het user object gekoppeld zijn) wel doorgevoerd maar worden deze overruled door de user settings in de computer policy.

GPO Best Practices

Als je bovenstaande in overweging neemt dan spreekt het voor zich dat je voorzichtig moet omgaan met het inschakelen van “loopback processing”. Er zijn voorbeelden waarin deze setting ontzettend handig is maar door de loopback policy op meerdere locaties te activeren ontstaat een onoverzichtelijk geheel. Wanneer wordt welke setting toegepast, uit welke policy is deze afkomstig en waarom worden bepaalde settings niet doorgevoerd.

Zo zijn er nog een aantal andere “best practices” als het gaat over de inrichting van GPO’s. Ik hanteer altijd onderstaande 12 regels:

• 1. Gebruik de “Default Domain Policy” voor de settings die altijd op elke gebruiker en elke computer van toepassing zijn. Verwerk alle afwijkende settings in separate policies.
• 2. Maak een OU structuur schema. Begin aan de tekentafel en werk de OU structuur goed uit. Als alles goed uitgedacht is dan werk je de OU structuur uit. Een goede OU structuur versimpeld het toepassen van policies en brengt meer duidelijkheid over de opbouw van de organisatie en de verschillende objecten.
• 3. Geef de policy een duidelijk naam
• 4. Gebruik user configuration en computer configuration setings niet door elkaar in 1 policy
• 5. Probeer het aantal policies te beperken naar het minimum
• 6. Disable het verwerken van user of computer configuration wanneer deze niet wordt toegepast. Dit komt de verwerkingssnelheid ten goedde.

  

• 7. Spring zuinig om met het toepassen van “loopback processing” en het toepassen van “block inheritance” of “enforced” opties. Documenteer de gevallen waarin dit vastgelegd wordt.
• Documenteer de gevallen waarin policies toegepast worden of juist niet toegepast worden d.m.v. de “Delegation” tab, dus op basis van specifieke gebruikers of groepen. Deze policies zijn dus niet van toepassing op alle objecten in de onderliggende OU’s.
• 8. Gebruik de “Default Domain Policy” voor de settings die altijd op elke gebruiker en elke computer van toepassing zijn. Verwerk alle afwijkende settings in separate policies.
• 9. Maak een OU structuur schema. Begin aan de tekentafel en werk de OU structuur goed uit. Als alles goed uitgedacht is dan werk je de OU structuur uit. Een goede OU structuur versimpeld het toepassen van policies en brengt meer duidelijkheid over de opbouw van de organisatie en de verschillende objecten.
• 10. Probeer zo min mogelijk “overkoepelende” policies zoals de “default domain” policy te maken. Omdat “inheritance” standaard toegepast wordt is het lastig om in kaart te krijgen welke policies er toegepast worden als er veel bovenliggende policies in place zijn.
• 11. Disable nooit een policy. Als een policy niet meer relevant is verwijder je deze. Als een policy nog even bewaard moet blijven of actief moet blijven op andere OU’s dan verwijder je de link op de OU. Een disabled policy wordt niet heel duidelijk weergegeven wat verwarring kan veroorzaken en wordt ook niet meer toegepast op de OU’s waar deze wel nodig is.
• 12. Implementeer “change management” op de policies. Op die manier breng je in kaar wie wat mag wijzigen en wat de wijzigingen exact geweest zijn. Als er dan iet mis gaat is het voor iedereen een kleine moeite om te ontdekken wat de laatste changes geweest zijn.

De loopback policy is een simpel concept maar gaat aardig diep omdat het activeren van loopback processing de complete structuur omgooit. Daarom, pas loopback processing alleen toe als je hier een hele goede reden toe hebt. In sommige situaties is het een livesaver.

Hopelijk heb ik het begrip “loopback policy” met deze post iets kunnen verduidelijken en heb je iets aan mijn 12 tips m.b.t. het inrichten van GPO’s. Bij interesse maak ik binnenkort een post over het maken van een “security” group policy. Ik hoor graag of hier interesse voor is. Group policies kunnen je namelijk enorm helpen om je computers en je netwerk veiliger te maken.

Vond je deze post interessant laat dan een leuke reactie achter, geef een like of deel hem zelf verder op je sociale netwerk. Leuke reacties houden me enthousiast om dit soort blogs te blijven schrijven 🙂 Tot de volgende post!