In continuare si in Windows 2008, daca nu folosim Fine Grained Password Policies, se aplica setarile din politica de domeniu.

Nu de putine ori am vazut admini incercand sa seteze Accounts Policy in politica ce se aplica pe containerul Domain Controllers – Default Domain Controllers Policy. Setarile puse acolo nu au nici un efect. Si o sa explic si de ce.

Da, stiu, putem seta pe un alt OU care contine computer accounturi, Accounts Policy, dar setarile se vor aplica si vor avea efect doar pentru conturile locale, iar cele de domeniu folosite pe acele masini nu vor fi afectate. Cum domain controllerele nu au conturi locale, mecanismul asta nu se aplica. Domain controllerele citesc Accounts Policy numai din politica de domeniu si ignora orice altceva setat intr-o politica legata de containerul Domain Controllers sau alt OU.

In afara de Accounts Policy se mai citesc din politica de domeniu si urmatoarele aflate Security Settings/Local Policies/Security Options:

Accounts: Administrator account status
Accounts: Guest account status
Accounts: Rename administrator account
Accounts: Rename guest account
Network security: Force logoff when logon hours expire

Pentru intrebari va astept pe forum.

http://www.microsoft.com/downloads/en/details.aspx?familyId=bcfb1955-ca1d-4f00-9cff-6f541bad4563&hash=OkpenMTOuklGLUEBSmULWEznkYipiBpwPa%2bkzUuBBZtZpkpC2KU7KupxSzyMzvJaFxajFRbpaQeCgXxEuHBKSQ%3d%3d

O sa ma rezum doar la modul “monitor” care poate fi activat cu gplogview.exe –m.

In acest mod se pot loga la consola toate activitatile legate de procesarea GPO, fie background refresh, fie fortata cu gpupdate.

Output-ul merge salvat si in XML sau HTML.

Ca exemplu sa luam cazul in care am o politica care face deployment la o aplicatie si intamplator un computer (sa spunem ca este un laptop si userul se deplaseaza frecvent) peste care este aplicata acea politica se afla intr-o locatie unde nu am domain controller, iar politica este incarcata de la serverul din sediul central peste o conexiune WAN. In functie de latimea de banda a conexiunii, procesarea GPO-ului si instalarea aplicatiei poate dura cateva secunde/minute sau o vesnicie.

Tocmai aici intervine acest mecanism numit GPO Slow Link Detection. Daca sistemul detecteaza ca latimea de banda intre el si domain controller este mai mica decat 500Kb (by default dar merge modificat) atunci nu mai proceseaza anumite parti din GPO. Cele mai importante ar fi: Application Deployment, Scripts, Folder Redirection. Mai multe detalii gasiti aici.

Cei ce s-au ocupat de administrarea AD ceva mai mult timp si au prins 2000 si XP probabil sunt familiari cu ce se intampla atunci cand tai ICMP-ul pe linkurile WAN. Nu se mai aplica GPO-urile; asta pentru ca XP si 2000 fac slow link detection folosind un algoritm bazat pe ICMP. Intregul mecanism de detectie, bazat pe ICMP este descris in KB227260.

In Vista si Windows 7 lucrurile s-au schimbat, si nu mai este folosit algoritmul bazat pe ICMP. In schimb intra in joc serviciul NLA (Network Location Awarnes) care estimeaza latimea de banda dintre client si domain controller. Cum anume face asta (ma refer la algoritm) – habar nu am si nici nu cred ca e documentat pe undeva. In schimb pot sa povestesc in mare ce face si mai ales sa explic de ce nu genereaza trafic suplimentar in comparatie cu metoda pe ICMP (in multe documente tehnice ale MS e specificat ca nu genereaza trafic suplimentar insa nu explica si de ce).

Pana sa apuce sa proceseze GPO-ul, clientul mai schimba cateva replici cu domain controllerul, gen: localizarea celui mai apropiat DC, autentificare, ceva RPC calls, cateva interogari LDAP, etc. Tot acest trafic, pana sa se ajunga la procesarea GPO-ului, este monitorizat de NLA, iar rezultatul este oferit serviciului Group Policy la momentul procesarii politicilor.

Daca linkul este suficient de rapid atunci HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\IsSlowLink este setat pe 1, in caz contrar pe 0.

Totusi, Slow Link Detection poate fi dezactivat. Dezactivarea se face tot prin Group Policy din ComputerConfiguration\Administrative Templates\System\Group Policy\Group Policy Slow Link Detection. By default setarea este pus pe 0, dar asta nu inseamna ca este dezactivata; inseamna ca o sa funtioneze cu setarea standard de 500Kbps.

Atentie: Aceasta optiune o gasiti si in User Configuration si in Computer Configuration. Deci slow link detection se face separat pe cele doua rubrici. A se mai vedea si optiunea Do not detect slow network connections din User Profiles.

Daca totusi vrem sa lasam optiunea activa dar sa fortam aplicarea unor parti din GPO chiar si peste link-uri lente, se poarte face si asta. Din aceeasi rubrica (ComputerConfiguration\Administrative Templates\System\Group Policy\) in GPO gasim si setari pe componente cum ar fi Scripts Processing Policy:

Mai multe detalii gasiti si aici http://support.microsoft.com/kb/227369/. Atentie ca in acest KB se mentioneaza ca optiunea “script policy processing” (exemplul meu) se refera numai la USER LOGON/LOGOFF Scripts. KB-ul este destul de vechi si nu am gasit nimic pentru versiunile mai noi de Windows, iar de reprodus asa ceva e destul de complicat.

Si probabil ca am mai putea deszvolta acest subiect insa scopul meu a fost sa fac un recap al acestei optiuni si sa pun intr-un singur loc ceva mai multe informatii despre subiect. Pentru restul va astept la discutii pe forum.

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.