Poate fi folosita ca si referinta pentru majoritatea seterilor din GPO.

Si merge adaugata ca si search provider in Internet Explorer.

Un must have pentru orice GPO admin.

Recunosc ca ma rodea sa aflu cum se face de vreo saptamana si am tot cautat sa vad cum se face. Mai exact sa obtii ceva de genul asta pe statiile utilizatorilor din domeniu:

Pentru cine nu observa, apare un logo customizat + nume pentru profilul de retea activ.

Se face din Group Policy – Computer Configuration\Policies\Windows Settings\Security Settings\Network List Manager Policies

Bineinteles ca e nevoie de Windows 7 sau Vista pe statiile userilor.

Nota: Post preluat de pe ITBoard (m-am gandit ca trebuie sa-l am si aici).

Cateva lucruri fundamentale care trebuie retinute despre GPO:

1. GPO-urile sunt stocate in SYSVOL (replicat pe fiecare DC). In AD exista doar un link catre GPO. Toate setarile se afla in adm-ul din SYSVOL.

2. GPO-urile nu sunt impinse de catre domain controller. Clientul citeste si aplica GPO-urile stocate in AD (aici revenim la problema cu Adminul local pe statii – daca e admin pe statie gaseste el ceva sa fenteze GPO-ul).

3. Ordinea de aplicare este urmatoarea:

- Local Policy

- Site Policy

- Domain Policy

- OUs Policy (in functie de ierarhia de OU-uri din AD, GPO-ul de pe ultimul OU din ierarhie si aplica ultimul; probabil OU-ul in care se afla userul sau computer accountul). Exista ceva metode de a influenta putin ordinea dar vorbim mai tarziu.

In caz de conflict de setari intre GPO-uri se aplica setarile din ultimul GPO aplicat (adica suprascrie ce s-a aplicat inainte)

4. GPO-urile nu se aplica pe grupuri.

5. La nivel de OU se poate seta optiunea Block Policy Inheritance. E utila atunci cand vrem sa blocam aplicarea GPO-urilor legate la nivelele de mai sus (OU, domeniu, site).

6. La nivel de GPO putem seta No Override (e acelasi lucru cu Enforced in toolurile mai noi). Mai exact setarile din GPO-ul cu aceasta optiune, nu vor fi suprascrise de setarile din GPO-urile de la nivelele de mai jos. Tehnic mi se pare ca GPO-ul cu No Override se aplica ultimul.

7. Cand cele doua optiuni de mai sus intra in conflict are prioritate No Override.

Cum restauram un GPO (Group Policy Object)? Considerand cazul in care GPO-ul nu mai poate fi citit sau setarile lui au fost modificate si sunt eronate. Simplu. Din backup,nu?
Ei, dar nu e chiar asa de simplu. Hai sa vedem mai intai ce optiuni avem.

1. GPO-ul era documentat, asa ca il pot sterge si reface de la zero folosind setarile din documentatie (care documentatie? )

2. Incepand cu Windows 2003, Group Policy Management Console are si optiune de a face backup la GPO-uri. Restauram folosind backup-ul facut cu GPMC.

3. Restauram folosind un system state backup de pe un domain controller.

Si acum e partea interesanta. Cazul numarul 3. Sa restaurez tot system state-ul pentru un GPO? Nu. Doar GPO-ul. Pasii sunt urmatorii:

- restore de system state; dar in alternate location. Adica intr-un folder temporar, undeva pe server (de preferat DC; nu e recomandat ca informatiile din system state sa plece de pe domain controller)

- cu GPMC aflam GUID-ul GPO-ului

- in locatia in care am facut restore la system state cautam folderul policies din sysvol. Atentie ca aici nu mai are exact structura care o stim de pe domain controller. E posibil ca locatia sa fie de forma d:\temp\sysvol\c_\windows\sysvol\domain\policies\. Copiem continutul politicii din folderul cu GUID-ul gasit mai sus.

- acum ca am localizat politica dupa GUID, tot ce trebuie sa mai facem este sa stergem continutul folderului din SYSVOL si sa copiem continutul din backup (un simplu paste la ce am copiat mai sus).

Si cam atat … nu restart de DC-uri sau alte avioane cum am vazut prin alte articole pe net.

PS: cred ca un titlu bun era si GPO Rollback.

Sunt incluse, atat pentru computere, cat si pentru useri, extensii care ne permit sa configuram anumite setari pentru care obisnuiam (de fapt eram nevoiti) sa folosim scripturi. De exemplu, folosind Group Policy Preferences, putem seta parola userului local Administrator sau adauga un user in grupul de administratori locali pe toate computerele sau pe o parte din ele, putem mapa Network Drives, putem face deploy de imprimante, putem configura Power Options, Folder Options, Registry settings si multe altele.

Toate aceste setari se pot aplica pe toate computerele, pe toti userii sau in functie de filtrele pe care le aplicam folosind Item-Level Targeting. Putem filtra aplicarea politicii dupa numele computerului sau al userului, dupa apartenenta la un grup sau OU, dupa sistemul de operare si multe alte criterii.

Pentru a putea folosi Group Policy Preferences, avem nevoie de urmatoarele:

- Pe computerele din domeniu trebuie instalat KB943729 – Group Policy Client-Side Extensions, disponibil pentru Windows XP minim SP2, Windows Server 2003 minim SP1, Windows Vista; XMLLite pe statiile cu Windows XP (KB915865) si Windows 2003 ( KB914783).

- Un server/statie de lucru cu Windows Server 2008/2008 R2 sau Windows Vista/7 cu RSAT.

In ciuda numelui, Group Policy nu se aplica grupurilor ci utilizatorilor si calculatoarelor in functie de containerul (OU), domeniul sau site-ul in care se afla. Si totusi cum putem controla aplicarea Group Policy in functie de un grup de securitate? Raspunsul este prin intermediul “security filtering”.

Obiectele de tip Group Policy au, ca orice alt obiect din Active Directory, un set de liste de control al accesului (ACL) care determina permisiunile. Prin intermediul acestor ACLs putem filtra accesul pentru anumite grupuri sau conturi de utilizator/computer. Care sunt ACL-urile implicite ale unui GPO?

Deschideti consola Group Policy Management:

Click pe politica dorita in partea stanga a ferestrei de browsing si selectati tab-ul Delegation:

Pentru o afisare mai familiara a permisiunilor click pe butonul Advanced:

Pentru ca un GPO sa se aplice unui cont de utilizator/computer trebuie ca acest cont, sau grupul din care face parte, sa aiba cel putin permisiunea “Allow” pentru “Read” si “Apply group policy”. Aceasta inseamna ca implicit pentru toti membrii grupului “Authenticated Users” se va aplica politica respectiva. Membrii acestui grup sunt toate conturile de utilizator sau computer care au fost autentificate de catre un Domain Controller. Desi membrii “Domain Admins” nu au permisiunea “Allow” “Apply group policy”, politica li se va aplica prin intermediul apartenentei implicite la grupul “Authenticated Users”.

In cazul in care doriti sa aplicati o politica noua pentru toti utilizatorii din domeniu, dar sa nu si pentru administratorii de domeniu (Domain Admins) aveti doua variante la dispozitie:

1. Scoateti grupul “Authenticated Users” din lista si folositi in locul lui un grup specific.

Atentie! In cazul folosirii grupului “Domain Users” contul “Administrator” nu va fi exceptat de la aplicarea politicii pentru ca face parte si din acest grup.

2. Pentru grupul “Domain Admins” activati permisiunea “Deny” “Apply Group Policy”.

In partea a doua a articolului va voi prezenta un scenariu mai complex de filtrare a Group Policy.

Tattooing??? What is that?

Termenul e cunoscut pentru cei ce citesc gpoguy.com; eu il stiu tot de acolo ca nu stiam cum sa denumesc “fenomenul”. Sa incep sa explic: ai policy aplicat peste un user sau computer, trebuie sa-l stergi, il stergi, dar setarile raman in continuare.

Cum asa? Pai probabil ca acele registry settings aplicate prin GPO nu se incadreaza in zonele din registry care sunt sterse cand policy-ul se modifica. Ceva detalii despre asta gasiti pe GPOGUY.

Azi m-am intalnit din nou cu fenomenul asta, insa fiind patit de multe ori am testat inainte si bine am facut. Exista setari chiar si in Administrative Templates care sufera de problema asta (in scenariul meu foloseam W2K3 si XP pe client):

Deci, simpla stergere sau dezactivare a policy-ului nu o sa-mi scoata setarile de proxy din IE de pe statii. E nevoie sa las policy-ul aplicat si sa fac Uncheck la optiunea “Enable proxy settings”.

Concluzia: testati de fiecare data setarile aplicate prin GPO; si la add si la remove.

Da, recunosc că poate fi folositor uneori, dar pe mine personal mă enervează Am avut probleme cu shutdown-ul în Server 2008, când primul buton era setat să facă shutdown. Dar din 2008 R2 butonul de Shut Down a fost schimbat cu Log Off. Cred că prea mulți au dat shut down la servere întâmplător

Bun, să revin la ce vreau să spun. După ce am instalat un server, îi scot traker-ul respectiv, ca să nu mă mai întrebe ce vreau să fac când apăs butonul Shut Down. Cum fac asta? Simplu:

1. Dau un Windows+R (Run) și scriu gpedit.msc.
2. În Computer Configuration, Administrative Templates, System, fac dublu click pe Display Shutdown Event Tracker.
3. Selectez Disabled și dau OK.

   

4. Închid GPO Editor. Gata.

Data viitoare când o să dau Shutdown la un Server 2008, o să facă Shutdown fără să mă mai întrebe nimic. Serverul 2003 însă o să-mi mai dea o fereastră, dar măcar nu va fi nevoie să spun de ce vreau shutdown sau restart…

Scriptul cu extensia ps1 se copiaza in folderul scripts asociat cu politica si se adauga cu Add, fara powershell.exe in fata.

Pe sistemul meu de test am avut setat deja Set-ExecutionPolicy Unrestricted. Dupa asta am setat sistemul si pe AllSigned si scriptul ruleaza fara probleme

Prima data ar trebui sa pomenesc cate ceva despre modul in care organizam informatiile in AD. Si aici intervin Organizational Unit-urile care sunt containere in care grupam obiectele din AD. Iar modul in care proiectam structura de Organizational Unit-uri poate fi orientat catre delegarea administrarii sau catre aplicarea de Group Policy. Nu exista nici un design batut in cuie, fiecare companie isi poate face structura de Organizational Unit-uri dupa bunul plac, insa e de retinut: nu ghidati acest design dupa departamentele din firma, sedii, functii etc, ci dupa modul in care va administrati infrastructura. Cu cat mai simpla structura cu atat mai bine. Nu vorbim de OU design acum, ci de GPOs.

In exemplu de azi am ales varianta cu OU pentru fiecare locatie (ex: Bucuresti), impartit in doua – Users si Computers. Scopul este de a activa setarea care spune userului daca s-a logat folosind cached credentials in cazul in care DC-ul nu e disponibil.

Dar ca exemplu o sa pun un screenshot cu o structura de OU-uri facuta dupa tipul resurselor nu dupa locatie ca sa se poate face diferenta (in continuare o sa mergem tot pe modelul geografic).

Acum, pentru a lucra cu GPO objects pe containerele nou create e necesar sa deschidem GPMC:

Si sa facem un GPO nou sau link la unul deja existent:

Odata creeat, GPO-ul poate fi gasit in containerul Group Policy Objects si tot de acolo poate fi dezactivat sau numai anumite portiuni User sau Computer settings (in cazul in care o parte din setari nu sunt folosite intr-un GPO – gen GPO care contine numai setari legate de Computer Settings – user configuration settings pot fi dezactivate pentru a grabi procesul de aplicare a politicilor).

Sa ne uitam putin si in detaliile acestui GPO. Nu uitati sa le si documentati pentru ca si ceilalti administratori sa stie la ce foloseste si pentru a evita GPO-uri redundante.

De remarcat acel Unique ID dupa care putem localiza policy-ul in folderul SYSVOL. User version si Computer version reprezinta numarul modificarii – eu am facut doar una in computer settings (utile atunci cand sunt probleme de replicare a politicilor intre site-uri).

In settings vedem exact ce contine politica:

Acuma o sa fac o scurta pauza, asta pentru ca am pomenit de SYSVOL. Asta e locul unde sunt stocate politicile si sursa multor probleme pana la Windows 2008. Asta pentru ca mecanismul de replicare al SYSVOL in W2K/W2K3 e FRS care nu merge foarte bine. Fiecare politica nou creata mai adauga cativa MB la acel folder; deoarece fisierele ADM sunt stocate cu fiecare politica in parte pentru a permite editarea politicii de pe orice sistem cu orice OS si localizat in orice limba. Incepand cu Windows 2008 si Vista a fost introdus concepul de ADMX Central Store in care sunt stocate toate fisierele ADMX, acestea fiind disponibile pentru toate GPO-urile si nemaifacand parte din fiecare GPO separat. Chiar si cand DC-ul e 2008, daca editam GPO-ul de la o masina cu XP, acesta o sa adauge fisierele ADM la politica. Asa ca atentie mare la numarul de politici si dimensiunea folderului SYSVOL.

ADMX-urile pentru a incepe cu central Store la gasiti in %windir%\PolicyDefinitions

Ok, mergem mai departe. Am facut un GPO numit “Setari computere Bucuresti” si ne-am dat seama ca de aceleasi setari avem nevoie sa fie aplicate si peste OU-ul Ilfov. Avem 2 optiuni – mai facem un GPO, sau putem face un link catre acelasi GPO – “Setari computere Bucuresti” (eh, in cazul asta am putea sa-l redenumim si sa scoatem numele Bucuresti).

Si am vazut ca nu e nevoie sa facem GPO-uri pentru fiecare OU nou, ci putem face link-uri catre unele deja existente (si putem avea politici generice pentru toti userii, sau politici care isi au rolul numai intr-un anumit site).

Acum ca am vazut cum facem un GPO si cum il legam de un OU, hai sa vedem si ce setari ar trebui sa i se aplice unui user din domeniu. Pentru ca am avut la dispozitie doar un DC pe care eram logat cu userul administrator nu am avut multe optiuni. Putem obtine aceste informatii folosing Grpup Policy Results din consola, specificand userul si sistemul pe care se logheaza:

Sau daca vrem sa vedem exact ce s-a aplicat pe acel user (nu ce ar trebui ca in cazul de mai sus) folosind GPRESULT /R (valabil in Vista, 7, 2008; pe celelalte nu e nevoie de /R, mai putin Windows 2000 unde se face cu secedit) de pe statia unde userul e logat:

Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001

Created On 10/12/2009 at 12:36:32 AM

RSOP data for ITBOARD\Administrator on DC1 : Logging Mode
———————————————————-

OS Configuration:            Primary Domain Controller
OS Version:                  6.1.7600
Site Name:                   Default-First-Site-Name
Roaming Profile:             N/A
Local Profile:               C:\Users\Administrator
Connected over a slow link?: No

COMPUTER SETTINGS
——————
    CN=DC1,OU=Domain Controllers,DC=itboard,DC=net
    Last time Group Policy was applied: 10/12/2009 at 12:33:49 AM
    Group Policy was applied from:      DC1.itboard.net
    Group Policy slow link threshold:   500 kbps
    Domain Name:                        ITBOARD
    Domain Type:                        Windows 2000

    Applied Group Policy Objects
    —————————–
        Default Domain Controllers Policy
        Default Domain Policy

    The following GPOs were not applied because they were filtered out
    ——————————————————————-
        Local Group Policy
            Filtering:  Not Applied (Empty)

    The computer is a part of the following security groups
    ——————————————————-
        BUILTIN\Administrators
        Everyone
        BUILTIN\Pre-Windows 2000 Compatible Access
        BUILTIN\Users
        Windows Authorization Access Group
        NT AUTHORITY\NETWORK
        NT AUTHORITY\Authenticated Users
        This Organization
        DC1$
        Domain Controllers
        NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
        Denied RODC Password Replication Group
        System Mandatory Level

USER SETTINGS
————–
    CN=Administrator,CN=Users,DC=itboard,DC=net
    Last time Group Policy was applied: 10/11/2009 at 11:40:43 AM
    Group Policy was applied from:      DC1.itboard.net
    Group Policy slow link threshold:   500 kbps
    Domain Name:                        ITBOARD
    Domain Type:                        Windows 2000
    Applied Group Policy Objects
    —————————–
        N/A

    The following GPOs were not applied because they were filtered out
    ——————————————————————-
        Default Domain Policy
            Filtering:  Not Applied (Empty)

        Local Group Policy
            Filtering:  Not Applied (Empty)

    The user is a part of the following security groups
    —————————————————
        Domain Users
        Everyone
        BUILTIN\Administrators
        BUILTIN\Users
        BUILTIN\Pre-Windows 2000 Compatible Access
        NT AUTHORITY\INTERACTIVE
        CONSOLE LOGON
        NT AUTHORITY\Authenticated Users
        This Organization
        LOCAL
        Domain Admins
        Group Policy Creator Owners
        Schema Admins
        Organization Management
        Enterprise Admins
        Denied RODC Password Replication Group
        High Mandatory Level

In cazul de mai sus se poate vedea ca in cazul Computerului au fost aplicate 2 GPO-uri – Default Domain Policy si Default Domain Controllers Policy. In cazul Userului acestea nu au fost aplicate pentru ca nu contineau nici o setare.

GPRESULT e utila si pentru a vedea din ce grupuri face parte utilizatorul dupa logon.

Cam atat in acest post insa nu ne oprim aici cu politicile …