How to change active network profile name and icon.
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.
Black Tuesday – Feb 2010
Se apropie. Sunt anuntate 13 buletine – 26 de vulnerabilitati, multe cu remote code execution. Pazea!
Angajeaza cineva un sysadmin?
Un prieten de-al nostru de pe ITBoard e in cautarea unei noi oportunitati (a se citi job). Probabil il stiti dupa nickname-ul BabaCloanta sau mai nou Dr.House. Si ar trebui sa mai stiti si ca e foarte bun.
Are cineva vreo oferta?
Ce trebuie sa stim despre Group Policy.
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.
Vista & Windows 7 – This connection requires an active Internet connection
Combinatia Windows Vista sau 7 + wlan + vmware player sau workstation instalat – poate duce la mesajul de eroare din titlu atunci cand incercati sa initiati o conexiune VPN din meniul Connect To. Rezolvarea clasica e sa te duci in Network Connections din Control Panel si sa initiezi conexiunea de acolo.
O alta varianta intalnita pe net ar fi sa umbli in network binding order si sa speri ca nu o sa se mai intample.
Eu am mai descoperit ca daca restartezi serviciul WLAN Auto Config lucrurile revin la normal (conexiunea la WLAN se va pierde pentru cateva secunde). Tot e mai bine decat un reboot.
More about Windows 7 Homegroups
In articolul anterior am discutat despre cum setam un homegroup. Acum sa discutam despre cateva detalii ale acestui feature.
First of all, trebuie retinut ca Network Location-ul pentru adaptorul de retea trebuie sa fie Home Network. Altfel nu va merge. La fel trebuie retinut ca se comporta “ciudat” atunci cand sunt mai multe adaptoare de retea pe sistem (multihomed), chiar si VMWare.
Second, un calculator care este membru in domeniu nu va putea crea un homegroup. Va putea joina un homegroup si accesa resursele partajate dar nu va putea partaja resurse. Microsoft s-a gandit ca nu ar fi bine ca cineva sa se duca acasa cu sistemul de la lucru si acolo sa-si partajeze informatiile. Personal mi se parea mai bine daca lasau la alegerea administratorului. Daca user-ul vrea tot o sa o faca pana la urma.
Urmatoarele setari din Group Policy permit dezactivarea accesului la un homegroup:
Computer Configuration\Policies\Administrative Templates\Windows Components\HomeGroup\Prevent the computer from joining a homegroup
Ce am mai descoperit: exista un grup folosit de acest feature numit Homeusers.
Cand joinam un sistem sau cand cream un homegroup, automat o sa avem un user in plus pe sistem numit HomeGroupUser$. Acest user va fi folosit pentru accesul pe sisteme remote si banuiesc ca va avea parola pe care o partajam (sau macar ceva derivat de la acea parola). Il vom intalni in permisiunile NTFS de pe resursele partajate.
Acum partea interesanta. Nu conteaza ce sistem a initiat homegroup-ul, atata timp cat mai exista inca un sistem membru el exista. Insa in momentul in care pleci din workgroup, grupul local Homeusers si userul HomeGroupUser$ sunt stersi, iar ACL-urile pe resurse raman. Ceva de genul:
Voi sti ce a fost partajat pentru ca fiecare folder va avea un lacatel in dreptul lui.
Inca ceva. Totul depinde de doua servicii Homegroup Listener si HomeGroup Provider.
Daca sunt oprite, optiune de homegreoup nu va aparea nici macar in Explorer.
Si cam atat pentru astazi. Daca mai aveti informatii despre acest topic nu ezitati sa le postati.
Forget about Workgroup. We have Homegroup in Windows 7
Homegroup-ul reprezinta probabil una din cele mai utile feature-uri din Windows 7 destinate home user-ilor. Dupa ani si ani si multe versiuni de Windows in sfarsit s-au gandit sa faca ceva sa imbunatateasca modul in care sunt partajate resursele intr-o retea de tip home.
Si asa a aparut homegroup-ul, un model de sharing in care nu mai folosesti user/pass sa te conectezi la resurse ci doar o parola pentru a joina la acel homegroup. Membrii homegroup-ului pot partaja resursele transparent fara a mai fi nevoie de alta autentificare.
Mai jos o sa prezint in imagini cum se configureaza si cum puteti partaja informatii in cadrul unui homegroup.
Setam homegroup-ul din Network and Sharing Center.
Personal nu imi place sa aleaga Windows-ul ce sa sharuiasca pentru mine, asa ca nu selectez nimic acum.
O sa aveti nevoie de parola de mai jos pentru a va conecta cu alte sisteme la homegroup. Parola poate fi vazuta si mai tarziu, sau chiar schimbata in cazul in care securitatea homegroup-ului este compromisa.
Acum ca am setat homegroup-ul ne ducem pe al doilea calculator si incercam sa joinam la acest homegroup. O facem tot din Network and Sharing Center.
Si cam asta e tot.
Iata si cum partajam informatia in cadrul unui homegroup:
Daca folderul a fost partajat atunci vom observa informatia urmatoare in partea de jos a ferestrei Explorer.
De pe celelalt sistem accesam share-ul accesand optiunea Homegroup care apare in partea stanga in explorer.
In lista sistemelor din homegroup vor aparea numai cele care au ceva partajat. Daca doar le-ati introdus in homegroup fara a si partaja ceva, nu vor aparea.
Voi continua intr-un articol urmator si cu alte detalii despre acest feature. Stay tuned!
Protecting AD OUs from accidental deletion
Incepand cu Windows 2008, in consola Active Directory Users and Computers exista o optiune care protejeaza OU-urile de la stergerea accidentala:
Iata ce se intampla cand vrem sa-l stergem:
Ca sa puteti sterge un OU, trebuie sa debifati “protect object from accidental deletion”. E bine gandita optiunea; am intalnit cazuri in care unii admini au sters containere intregi cu toate obiectele din ele si a trebuit sa apelez la restore din backup.
Dar ce facem daca folosim Windows 2003? Nici o problema, exista solutie si aici.
Setam Deny pe Delete si Delete Subtree in Advanced security settings.
Iar pe containerul parinte (in cazul meu e domain root) setam Deny pe Delete All Child Objects.
Iata ce se intampla cand incercam sa stergem Organizational Unit-ul.
Operatiunea afecteaza doar OU-ul Test_Delete, fara a afecta obiectele din el (inclusiv OU-uri) si recomand a fi setat pe containerele top level cu foarte multe obiecte.
Despre DNS poisoning.
In ultimii ani am intalnit destul de des termenul DNS Poisoning (DNS Pollution sau DNS Cache Poisoning) si am vazut si ceva security hotfixuri legate de aceasta tehnica. Cineva m-a intrebat de curand cum functioneaza. E o tehnica destul de veche dar interesanta. Sa explicam pe scurt:
1. Incercam sa facem o interogare pe domeniul dnstest.winadmin.ro
2. Serverul autoritar pentru inregistrarea dnstest.winadmin.ro este unul din NS-urile care imi tine zona winadmin.ro
3. Si aici intervine smecheria. Serverul meu raspunde ceva de genu: nu am inregistrarea dnstest, dar am delegat-o catre NS-ul www.google.com. Si ca sa nu te mai chinui ia si IP-ul lui www.google.com si tine-l in cache.
- va imaginati ca IP-ul returnat nu duce in nici un caz la google.
- daca serverul DNS are incredere in raspuns si cachuieste informatia – we are fucked up.
4. Probabil ca nu vom reusi sa accesam dnstest.winadmin.ro dar asta nu e important pentru atacator.
5. Nu are rost sa mai spun unde se vor duce cererile urmatoare catre www.google.com.
Foarte multe servere DNS au fost redirectate in acest fel tocmai pentru ca permiteau recursion. Azi am putea spune ca e destul de safe daca esti patch-uit bine, insa asteptam DNSSEC care o sa rezolve astfel de hibe.
DNS-ul e treaba serioasa. De asta nici nu recomand companiilor sa foloseasca forward catre serverele providerului.
PS: remember China Golden Shield Project?
Environment variables in Windows
Dupa cum probabil stiti, exista doua tipuri de variablie de sistem, user & system. User – sunt vizibile numai in profilul utilizatorului in care sunt definite; si system – accesibile de catre intreg sistemul.
Folosing comanda SET putem vedea toate variabilele la care avem access in sesiunea noastra:
De exemplu variabila LOGONSERVER ne spune ce server ne-a autentificat. In cazul unei statii joinate la un domeniu Active Directory putem vedea DC-ul folosit pentru logon. Altfel apare numele statiei locale.
Insa probabil cea mai folosita variabila din lista de mai sus este PATH. Si hai sa incercam sa ii modificam valoarea (de exemplu mai adaugam calea c:\Andrei\). Putem face acest lucru in doua moduri: interfata grafica si prompt. Din prompt se face cam asa:
SET PATH=%PATH%;c:\Andrei\
Insa cea mai buna varianta in Windows de a seta variabilele de sistem este sa folosim interfata grafica:
Si asta pentru a propaga variabilele in sistem. Prin varianta din command prompt, noua valoare va fi vazuta doar in contextul acelui command prompt, insa din GUI schimbarile vor fi vazute de orice proces nou din system. Iar explicatia pentru acest comportament o gasiti aici http://support.microsoft.com/kb/104011 (din prompt nu se trimite acel mesaj catre applicatii pentru a le anunta sa foloseasca noua valoare).
Pentru applicatii care ruleaza folosind conturi system e posibil sa fie totusi nevoie de un reboot.
Si pot sa va mai spun ca unele variabile merg setate din regitry.
System le gasim aici: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.
Iar user: HKEY_CURRENT_USER\Environment
Sunt stocate ca Expandable String Value. Regedit-ul din Windows 7 stie by default de REG_EXPAND_SZ. In versiunile mai vechi era nevoie de regedit32 pentru a edita aceste valori.
Sper ca informatia sa va fie de folos sau macar sa va faca un scurt refresh la capitolul Environment Variables.
PS: mai tine cineva minte Autoexec.bat? 