Unde este stocata calea catre profil in registry

 

Postul acesta l-am replicat de pe ITBoard, pentru ca intentionez sa public o serie de articole unde va fi nevoie de aceasta informatie.

In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>

http://support.microsoft.com/kb/324734

Cheia din registry ProfileImagePath se refera la locatia profilului pe disk. E foarte utila in cazul migrarilor, cand user account-ul isi schimba sid-ul si agentul de migrare nu reuseste sa translateze profilul. Sau cand joinezi statia in domeniu si vrei sa pastrezi vechiul profil. Si cazuri mai sunt multe.

Poti chiar sa folosesti acelasi profil pentru 2 conturi – de domeniu si local.

 

Pe scurt: Modifici calea catre profil. Dai permisiuni pe folderul cu profilul pentru userul care se logheaza.

Links & shortcuts in Windows

 

Ideea sa scriu despre tipurile de link-uri in Windows mi-a venit de la povestea cu folderul WINSXS. Dar ca sa nu ma lungesc o sa incep sa explic cat mai pe scurt. Un link reprezinta un mod alternativ de a accesa o resursa iar in cazul de fata vorbim despre foldere si fisiere.

In Windows exista 4 tipuri de link-uri pe care o sa le descriu mai jos:

Explorer Shortcuts – Le intalnim foarte des, in special pe desktop 🙂 si le cream din Windows Explorer. Sunt fisiere interpretate de Explorer cu extensia LNK care ne redirecteaza catre fisierul sau folderul dorit.

Junction points – au aparut in Windows (mai exact in NTFS) de pe vremea lui NT si fara a exista foarte multe modalitati de a le utiliza pentru utilizatorul de rand. Reprezinta un obiect in file system care redirecteaza catre un folder aflat in alta parte (dar numai pe sistemul local; poate fi si pe alt volum). Sunt in continuare folosite si in Vista si Windows 7. Vezi C:\Documents and Settings:

Symbolic links – se deosebesc de Junction Points prin faptul ca pot redirecta si catre fisiere, nu numai foldere si suporta si locatii remote (e nevoie de cel putin Vista pe source & target). Pot fi create cu MKLINK si sunt vizibile la DIR:

Stergerea link-ului nu afecteaza in nici un fel informatia originala.

Hard links – reprezinta un pointer in filesystem catre datele aflate pe disk (reprezentand un fisier). Diferenta intre hard links si celelalte linkuri e ca pointeaza direct catre date, nu catre o cale din filesystem. Pot fi create mai multe hard link-uri catre acelasi fisier si in felul acesta poate fi accesat prin mai multe nume. Totul este transparent pentru utilizator insa orice modificare va afecta acelasi set de date. Fisierul este marcat ca sters doar atunci cand toate linkurile catre el sunt sterse. Sunt permise astfel de linkuri numai catre fisire (nu si foldere).

Sunt vizibile si pot fi create numai cu MKLINK (sau apeland API-urile).

 

Articolul reprezinta numai un punct de pornire. Pentru mai multe detalii check www.google.com

Cum verificam bifa “Allow inheritable permissions” (in Active Directory)

 

Stiu ca foarte multi administratori de Active Directory s-au lovit de problema asta. In special cand preiei administrarea unui domeniu de la altcineva sau cand obiectele care le ai in domeniul tau au venit printr-o migrare.

Bifa din imaginea de mai jos se refera la mostenirea permisiunilor de pe containerul care contine obiectul (sau pot fi mai multe nu numai unul).

E nevoie ca aceste permisiuni sa se propage la obiectele din container, pentru ca la nivel de container se fac delegarile de permisiuni. Sa luam exemplul in care delegam permisiunea de a reseta parole unui admin regional pentru toti userii care se afla intr-o anumita locatie, mai exact toti userii care se afla intr-un anumit container (OU).

Daca obiectele din containerul meu nu au bifa de care pomeneam mai sus activa, delegarea nu o sa functioneze. By default bifa e activa, insa pe parcursul vietii unui obiect in AD, se poate schimba. Cateodata poate fi facuta manual sau de anumite procese – gen cazul cand un user este adaugat in grupul Domain Admins, iar cand este scos nu este pusa la loc.

 

Cum putem sa fortam activarea acestei bife sau sa vedem daca este activa? In cazul unui singur utilizator e simplu, problema apare atunci cand avem zeci sau sute de utilizatori (poate chiar mai multi dar ne oprim aici) de modificat sau verificat.

Ca de obicei VBScript ne sare in ajutor. Mai jos avem un exemplu de script care verifica toti userii dintr-un anumit OU din AD si activeaza optiunea Allow inheritable permissions.

 

‘Script created by Andrei Ungureanu
‘www.winadmin.ro

On Error Resume Next

Const ADS_SCOPE_SUBTREE = 2
Const SE_DACL_PROTECTED = 0

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Size Limit")= 10000

objCommand.Properties("Page Size") = 10000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE

objCommand.CommandText = _
"<LDAP://ou=accounts,dc=itboard,dc=local>;"_
& "(objectCategory=user);sAMAccountName,distinguishedname;subtree"

Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst
Do Until objRecordSet.EOF

userDN = objRecordSet.Fields("distinguishedName").Value
set objObject = getobject("LDAP://" & userDN & "")
Set objntSD = objObject.Get("nTSecurityDescriptor")

intNTSDControl = objNtSD.Control

If intNTSDControl <> 35844 Then
    ‘ Enable "allow inheritable permissions".
    intNTSDControl = intNTSDControl And SE_DACL_PROTECTED
    objntSD.Control = intNTSDControl
    objObject.Put "nTSecurityDescriptor", objntSD
    objObject.SetInfo
    WScript.Echo "Obiectul " & userDN & " a fost modificat"
End If

objRecordSet.MoveNext
Loop

Calea LDAP://ou=accounts,dc=itboard,dc=local trebuie inlocuita cu locatia in care avem obiectele ce trebuiesc scanate. Merge specificat chiar si domain root insa nu recomand asa ceva. Recomand ca inainte sa folositi scriptul, sa il verificati pe un mediu de test.

PS: scriptul merge modificat foarte usor si doar pentru a arata starea bifei Allow inheritable permissions.

 

Cum aflam cine este logat pe o statie? (via Active Directory)

Sunt convins ca fiecare admin are metoda lui de a verifica cine este logat pe o statie.

Ca sa dam cateva exemple  :

– Sesiune de RDP catre statia respectiva (dupa validare suntem intrebati daca vrem (sau nu) sa deconectam userul).

– Query WMI pe statie.

– Diverse tool-uri third party

-Scripturi In-house

M-am tot gandit in ultima vreme la o metoda mai eleganta de a centraliza aceste informatii. Am tot analizat acest proces si de la un sheet in excel am ajuns la concluzia ca ar fi mai util sa fie in AD, mai ales ca fiecare dintre noi il foloseste mai tot timpul. Asa ca m-am gandit ca ar fi bine sa fac un script.

Acest script va verifica din sesiunea locala variabilele de sistem %username% si %computername% iar daca ele sunt identice cu cele din AD (aici ma refer la common name-ul asociat obiectelor) atunci va modifica attributul description pentru obiectul aferent statiei cu un string formatat din script.

Acesta se va aplica la user logon printr-un GPO, sau setat ca logon script din Active Directory User and Computers in tabul profile.

Inainte de a incepe cu analiza scriptului voi sublinia pasi logici de implementare:

1. Script

2. Modificarea securitatii pe OU-ul care contine statiile.

3. Creare GPO, sau setat ca logon script din Active Directory User and Computers in tabul profile.

4. Testare

5. Aplicare politica

In acest articol voi prezenta doar pasii 1 si 2.

 

1. Script

Codul scriptului este colorat in gri pentru o preluare mai rapida in pagina.

 

‘Created by Mihai Marius 2009
‘

Set wshShell = WScript.CreateObject( “WScript.Shell” )
Local_ComputerName = wshShell.ExpandEnvironmentStrings( “%COMPUTERNAME%” )
Local_UserName = wshShell.ExpandEnvironmentStrings( “%USERNAME%” )

 

Set objSysInfo = CreateObject( “ADSystemInfo” )
AD_ComputerName = objSysInfo.ComputerName
AD_UserName = objSysInfo.UserName

 

Set objUser = GetObject(“LDAP://” & AD_UserName)
Set objComputer = GetObject(“LDAP://” & AD_ComputerName)

 

    If Local_UserName = objUser.CN and Local_ComputerName = objComputer.CN Then

Text_Desc = “Userul ” & objUser.CN & ” s-a connectat  la ” & Now & “.”

objComputer.Description = Text_Desc
objComputer.SetInfo

Set wshShell = Nothing
Set objSysInfo = Nothing
Set objComputer    = Nothing
Set objUser = Nothing

Else

Set wshShell = Nothing
Set objSysInfo = Nothing
Set objComputer    = Nothing
Set objUser = Nothing

    End If

WScript.Quit

Acum sa analizam codul si sa oferim cateva informatii.

Set wshShell = WScript.CreateObject( “WScript.Shell” )
Local_ComputerName = wshShell.ExpandEnvironmentStrings( “%COMPUTERNAME%” )
Local_UserName = wshShell.ExpandEnvironmentStrings( “%USERNAME%” )

Initializam un shell pentru sesiunea locala de unde extragem variabilele de sistem %computername% si %username%.

Valorile returnate vor fi declarate ca Local_ComputerName  si Local_UserName.

 

Set objSysInfo = CreateObject( “ADSystemInfo” )
AD_ComputerName = objSysInfo.ComputerName
AD_UserName = objSysInfo.UserName

Cream o instanta a clasei ADSystemInfo, pentru a utiliza obiectele din AD care fac referinta la statie si utilizator. Este important de subliniat valoarea acestei clase deoarece ea ne returneaza DN-ul (distinguished name) obiectelor util in pasul urmator.

 

Set objUser = GetObject(“LDAP://” & AD_UserName)
Set objComputer = GetObject(“LDAP://” & AD_ComputerName)

Query LDAP pentru a utiliza atributele din AD asociate statiei si utilizatorului.

 

If Local_UserName = objUser.CN and Local_ComputerName = objComputer.CN Then

Text_Desc = “Userul ” & objUser.CN & ” s-a connectat  la ” & Now & “.”

O functie de validare intre valorile locale si valorile asociate obiectelor in AD. M-am gandit sa fac un double check ale acestor valori pentru a nu modifica campul description daca nu ele nu sunt identice.

Daca valorile sunt egale atunci se formateaza textul pentru descriere. Intial m-am gandit sa trec doar utilizatorul dar am vazut pe net si alte abordari de forma: “Userul x s-a logat la data z ora y” si m-am gandit ca acesta abordare ar fi mai utila pentru debugging.

 

objComputer.Description = Text_Desc
objComputer.SetInfo

Set wshShell = Nothing
Set objSysInfo = Nothing
Set objComputer    = Nothing
Set objUser = Nothing

Setam textul formatat pentru atributul description al obiectului ce reprezinta statia. Eliminam obiectele care au fost incarcate in memoria sistemului .

Else

Set wshShell = Nothing
Set objSysInfo = Nothing
Set objComputer    = Nothing
Set objUser = Nothing

    End If
WScript.Quit

Daca valorile nu sunt egale atunci eliminam obiectele care au fost incarcate in memoria sistemului dupa care terminam functia si iesim din script.

 

2.Modificarea securitatii pe OU-ul care contine statiile.

In acest pas voi descrie modul in care putem modifica securitatea OU-ului in care se regasesc obiectele care fac referinta la statiile din domeniu, pentru a permite doar modificarea campului description.
Fara aceste permisiuni de modificare acest script nu va functiona pentru useri simpli (ma refer desigur la Domain Users).

In exemplul meu voi folosi  OU-ul Comp iar permisiunile le voi asocia groupului Domain Users. Ar fi de preferat sa utilizam un alt group ca sa nu-l folositi pe cel default, pentru a limita expunerile la eventuale atacuri.

Deschidem consola de Active Directory Users and Computers –> Selectam OU-ul Comp –> click dreapta Security si selectam Advanced –> Add –> Introducem Domain Users si selectam OK –> selectam tabul Properties.

In campul Apply onto selectam “Computer objects” si selectam Write Description.

Poza arata exact pasi enumerati mai sus.

 

Click OK, three times.

Dupa aplicarea scriptului in campul description al unei statii ar trebui sa arate asa:

 

Sfat: Inainte de aplicarea acestei politci ar fi bine sa faceti cateva teste pentru a nu perturba activitatea.

 

Troubleshooting: In cazul in care nu ati configurat corect , partea de permisiuni pe OU, veti primi un mesaj de eroare (pe sesiunea clientului) de forma :

Cum migram un Windows Print Server ?

Sa zicem ca vrem sa inlocuim actualul nostru Windows 2000/2003 Print Server cu unul nou, din diverse motive : defecte hardware, erori iremediabile ale sistemului de operare, etc. Cum procedam ca sa nu trebuiasca sa reinstalam toate imprimantele de retea pe noul server? Solutia e sa facem un backup pe vechiul server si un restore pe noul server, folosind un mic utilitar, Microsoft Print Migrator. Acesta nu necesita instalare, poate fi rulat direct.

Ce trebuie sa facem inainte de backup : daca nu mai avem in companie clienti Windows NT 4.0, trebuie sa dezinstalam driverele aditionale pentru acest tip de clienti. De ce? Deoarece clientii Windows NT 4.0 folosesc Kernel-Mode Drivers, a caror instalare e blocata incepand cu Windows Server 2003. Motivul : o eroare a unui Kernel-Mode Driver duce la blocarea intregului server.

Daca totusi mai aveti clienti Windows NT 4.0, trebuie ca pe noul server sa permiteti instalarea driverelor Kernel-Mode. Cum faceti acest lucru ? Fie din “Group Policy – Administrative Templates – Printers – Disallow installation of printers using kernel mode drivers “ – setati pe Disabled , fie direct in registry , astfel: deschideti un Notepad, copiati urmatoarele :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers]

“KMPrintersAreBlocked”=dword:00000000 ,

salvati fisierul cu extensia .reg si rulati-l pe noul server. Este necesar si un restart. Daca nu faceti acest lucru, restore-ul va esua.

Si acum sa trecem la treaba. Pe vechiul server rulam printmig.exe cu dublu click. Acesta va afisa imprimantele instalate, drivere,porturi, etc, asa cum vedeti imaginea de mai jos.

Din meniul Actions, dam click pe backup, alegem numele si locatia unde dorim sa salvam fisierul de backup, dam click pe Open si va incepe procesul de backup. Fisierul rezultat il copiem pe noul server, deschidem printmig.exe, si alegem Restore din meniul Actions (procedura de restore poate fi executata si de pe vechiul server, specificand ca Target server \\nume-server-nou, dar eu am preferat sa o fac local, merge mai repede, mai ales daca ai multe imprimante). Selectam fisierul de backup, daca vrem alegem sa nu apara ferestre de avertizare si daca e cazul, sa fie convertite porturile LPR in Standard TCP/IP Port Monitor. Dam click pe Open pentru inceperea procesului de restore.

Dupa terminarea procesului, verificati daca toate imprimantele au fost restaurate.

In cazul in care numarul de imprimante instalate de pe noul server este mai mic, identificati-le pe cele care lipsesc si instalati-le manual. Astfel de probleme pot aparea mai ales daca migrarea se face catre un server cu sistem de operare mai nou (multe imprimante functioneaza, de exemplu, si pe Windows 2003 cu driverele de 2000, unele insa nu; in orice caz, un update de drivere este recomandat).

De asemenea, e posibil ca third-party port monitors, cum e acesta, de exemplu,

sa nu poata fi migrate. In acest caz, trebuie sa le instalati manual.

Alte erori care pot aparea in cursul operatiunii sunt cele de legate de Kernel-Mode drivers, despre care am vorbit la inceputul articolului.

Procedura descrisa mai sus este valabila pentru migrarea pana la Windows 2003 R2 inclusiv. Daca doriti sa migrati la Windows 2008, procedati astfel :

– Adaugati rolul Print Services si deschideti consola Print Management din Administrative Tools;

– Click dreapta pe Print Servers, Add/Remove Servers, scrieti numele serverului de la care doriti sa migrati, adaugati-l in lista si OK. Serverul va aparea in consola de Print Mangement.

– Dati click dreapta pe numele serverului adaugat si selectati “Export printers to file”.

Urmati pasii necesari pentru a exporta datele intr-un fisier cu extensia .printerExport.

– Importati imprimantele pe noul server cu click dreapta pe numele noului server si “Import printers from a file”;

– Selectati fisierul exportat anterior si urmati pasii necesari pentru a-l importa.

– Este foarte posibil ca importul sa se finalizeze cu erori, datorate incompatibilitatii unor drivere, dar aveti posibilitatea sa le identificati rapid, in Event Viewer, si sa le remediati.

Ce ar mai fi de spus ?

– In cazul in care scoateti din retea serverul vechi puneti numele lui serverului nou, ca sa nu trebuiasca sa mai lucrati si pe partea de clienti. Daca nu puteti, va trebui sa redeploy-ati imprimantele pentru clienti.

Tip : Folositi Group Policy Preferences, Item-level targeting.

– Atat printmig.exe cat si utilitarul din Windows 2008, printbrm.exe, se pot rula si din linie de comanda.

– Eu nu as migra de la Windows NT 4.0 la orice versiune superioara, as prefera sa reinstalez toate imprimantele. De multe ori pierzi mai mult timp ca sa remediezi niste erori decat daca faci totul de la zero.

– Nu am facut si nici nu am testat migrarea de la x32 la x64, asa ca nu stiu daca functioneaza.

Setarea mediului de test/dev virtual pentru soluţii Sharepoint: Part I – Setarea mediului virtual şi instalarea sistemului de operare

În articolul introductiv ziceam că mediul de test va fi setat pe doua servere virtuale VMWare. In cele ce urmează voi parcurge pas cu pas procedura de crearea a unui template pentru serverul virtual și instalarea sistemului de operare windows server 2008 r2 pe acesta. Țin să menționez că nu e necesar de parcurs procedura de două ori, este suficent crearea unui template din care in continuare vom clona fiecare server in parte.

Crearea unei mașini virtuale template.

În interfața de administrare VMware Infrastructure Web Access facem click pe meniul Virtual Machine > Virtual Machines > Add New Virtual Machine. Ca urmare VMWare pornește un wizard pentru crearea a mașinilor virtuale. Fixăm următorele caracteristici:

1. Name and Location Name:”w2k8r2x64 server template 26oct2009″
2. Guest Oprating System Operating System:Windows operating system, Version: Microsoft Windows Server 2008 (64bit).
3. Memory and Processors Memory Size:1024MB; Processors Count:2.
4. Hard Disk Capacity:18GB; File Options: Allocate all disk space now; Policies > Write Caching: Optimize for performance.
5. Network Adapter Network Connection:Bridged.
6. CD/DVD Drive Use and ISO Image > ISO Name:7600.16385.090713-1255_x64fre_server_eval_en-us-GRMSXEVAL_EN_DVD.iso.
7. Floppy Drive: Don’t add a floppy drive
8. USB Controller: Don’t add an USB controller

Pe ultima pagina de wizard confirmăm parametri specificați:

În următoarele clipe VMWare va crea mașina virtuală, alocândui resursele necesare. Procesul poate dura mai multe minute și depinde in mare măsură de performanța sistemului de stocare.

Instalarea şi configurarea sistemului de operare Windows Server 2008 r2.

Startăm masina virtuală tocmai creată și așteptăm bootarea de pe imaginea de disk atașată pe CD ROM. În continuare se va lansa wizardul de instalare Windows Server 2008r2.

Pe pagina Select the operating system you want to install, putem alege între Standard și Enterprise (Full Installation). Eu mi-am pus Standard.

În pagina următoare suntem de acord cu Licence Agreement-ul

In Wich type of installation do you want ? facem click pe Custom.

În Where do you want to install Windows, click Next. Wizardul îşi va face singur treaba de creare şi formatare a partiţiei.

Așteptăm până se pargurg următoarele etape:

In final serverul se restartează și propune fixarea unei parole pentru contul administratorului local. Parola trebuie sa corespundă unor cerințe minime de complexitate de altfel nu va fi acceptată. Nu ezitați să fixați o parola mai complexă cu cel puțin 8 caractere fără cuvinde de dicționar bla bla bla … știți și voi. Eu mi-am pus una standard pentru mine in astfel de cazuri: asdfgh1!.

Se recomandă ca după înstalarea sistemului de operare să fie instalat si pachetul VMWare Tools. Prin VMWare tools vom obținem o perfomanță grafică și o experiență de interacțiune cu consola VMWare la serverul virtualizat mai bună. Vom mai avea și suportul pentru Shared Folders și drag and drop operations. Așadar, pe pagina de administrare VMWare, fixam masina virtuală in Inventory, după care facem click pe Install VMWare tools... aflat in fereastra status pe dreapta paginii. In clipa următoare pe server (și poate fi observat in consola serverului) pornește un proces standard de instalare cu un wizard maxim de simplu, nu avem decit să-l parcurgem rapid prin citeva click-uri pe Next. În final restartăm serverul. Suplimentar, mai putem imbunătăți calitatea interacțiunii prin consola VMWare cu fixarea la maximum a parametrului Hardware acceleration în Display Adapter Troubleshooter pentru driverul VMWare SVGA:

Cu toate că consola VMWare oferă o experiență satisfăcătoare in interacțiunea cu serverul virtualizat, personal, prefer totuși să-l accesez pe acesta prin Remote Desktop, lăsând consola doar pentru cazurile in care stația de lucru și masina virtuală nu au o legătură de rețea (ca de ex. in cazul in care rețeaua virtuală se află în spatele unui NAT sau este complet izolată).

In cele ce urmează vom realiza unele configurări pe sistemul de operare. Toate acestea pot fi inițiate din fereastra Initial Configuration Tasks:

1. Activate windows – trebuie facut in cel mult 10 zile, în caz contrar serverul va trece in shut down după fiecare oră. Activarea e un wizard simplu pe care îl treci prin click consecutiv pe Next.
2. Set time zone – pentru Moldova e UTC+2 Minsk.
3. Configure Networking – configuram accesul la rețeaua LAN corporativă. Faptului că cartela de rețea pe serverul virtual funționează în regim bridge (așa cum a fost setată în wizardul de creare a masinii virtuale – vezi mai sus), ne permite accesul direct la resursele rețelei corporative de ex. DNS, DHCP sau chiar ieșire la Internet. Așa după cum vom vedea în continuare accesul la Interntet va fi util pentru update-ul serverului. Așadar, dacă in rețeaua corporativă nu funcționează un serviciu DHCP, fixam static parametri TCP/IP (adresa IP, default gateway, DNS servers) specifici pentru rețeaua intranet.
4. Enable Remote Desktop. În fereastra System Properties > Remote bifam Allow connections from computers running any version of remote desktop software (less secure) sau varianta cu more secure :).
5. In final facem click pe Download and Install Updates. Pe pagina Windows Update activam Automatic Update. După care pornește procesul automat de descărcare și instalare a pachetelor de updates.

Clonarea mașinii virtuale.

După un restart cerut, trecem in shutdown masina virtuală. Până acum am creat un șablon de server așa că in continuare il vom clona de mai multe ori in funcție de cite mașini virtuale avem nevoie. Cu părere de rău, VMWare Server 2 nu are funcții integrate pentru clonare masinilor virtuale (VMWare Workstation le are 🙂 ), de aceea vom fi nevoiti se executăm manual câteva operațiuni:

1. 1. Localizăm folderul in care se păstrează fișierele VMWare (*.vmdk, *.vmx, *vmxf) pentru template-ul masinii virtale tocmai create.
   1. Copiem tot conținutul folderului (deși nu vom avea nevoie de toate fișierele) intr-un folder nou.
   2. Din consola de administrare VMWare Infrastructure Web Access, adăugăm masina clonată la lista de mașini gestionate (inventory) Virtual Machine -> Add Virtual Machine to inventory ->Add Existing Virtual Machine
   3. Schimbam numele masini virtuale cu un text ce il reprezintă. In exemplul meu am schimbat din w2k8r2x64 server template 26.oct.2009 in vm-dcsql (vm-wssdev). In meniul Commands pentru masina tocmai adăugată la listă facem click pe Configure VM după care in fereastra VM Configuration schimbăm corespunzător Virtual Machine Name.
   4. Startăm mașina virtuală. La intrebarea: msg.uuid.altered:This virtual machine may have been moved or copied.In order to configure certain management and networking features VMware Server needs to know which.Did you move this virtual machine, or did you copy it? Răspundem I _copied it, așa VMWare va asigura un ID și un MAC nou pentru masina virtuală.
   5. Ne logăm pe mașina virtuală după care schimbăm Computer Name (System Properties > Computer Name Change … > Computer Name) și configurația IP. În caz contrar la startarea următoarei mașini virtuale clonate, cu siguranță vor apărea mai multe mesaje de conflict.
   6. Repetam 1-6 și pentru cealaltă masină virtuală.

Rem: Procedurile descrise in articolul de față sunt specifice sistemului de virtualizare VMWare Server 2, dacă utilizați alte aplicații de virtualizare folosiți procedurile specifice acestora. Important este ca in final să obțineți aceleași două servere virtualizate.

Așadar, pe moment avem pregătite două masini virtuale cu sistem de operare instalat și suntem gata să trecem la faza următoare in care vom seta serviciile de rețea și backendul mediului de test/dev sharepoint.

Rezumând, până acum am parcurs urmatoarele faze:

1. Crearea unui model de masina virtuală pe VMWare Server 2
2. Instalarea sistemului de operare Windows Server 2008 r2
3. Instalare VMWare Tools
4. Configurare sistem de operare (activare, setare password, timezone, regional settings, enable remote desktop, set up TCP/IP settings )
5. Updatarea sistemului de operare
6. Clonarea masinii virtuale, plus reconfigurare Computer Name și TCP/IP.

Misterul din spatele optiunii “Automatically detect settings”

 

Chiar citeam intr-un alt articol aici pe site despre o problema cauzata de aceasta optiune din Internet Explorer:

Sfatul meu e urmatorul: daca nu stiti nimic despre aceasta optiune si aveti doar o vaga banuiala, atunci nu o folositi. O sa incerc sa explic acum cum functioneaza acest proces de detectie automata a setarilor (sa vedem si ce setari).

Optiunea “automatic configuration” se refera la capabilitatea browserului de a-si autoconfigura setarile pentru serverele proxy. Acest lucru se face prin rularea unui javascript script care se afla pe un server web. Scriptul mai este numit si Proxy Auto Config (PAC) si o descriere a formatului o gasiti aici. In screenshotul de mai sus se vede ca exista si optiunea sa specificati manual locatia scriptului.

Partea de “automatic” se bazeaza pe protocolul WPAD (Web Proxy Auto Discovery protocol) care este responsabil pentru localizarea scriptului de autoconfigurare. In acest scenariu scriptul trebuie sa se numeasca wpad.dat. Scriptul poate fi localizat de browser prin doua metode:

1. Optiunea DHCP 252 (atentie ca nu toate browserele suporta aceasta optiune iar pe unele OS-uri nu toti userii o pot folosi (W2K); documentati-va inainte).

La nivel de DHCP putem distribui locatia scriptului de configurare (wpad.dat) pentru toti clientii serverului. Valoarea optiunii arata ceva in genul:

http://servername.domain.local:80/wpad.dat

In functie de serverul de la care isi iau IP, sau scopul din care li se aloca IP, clientii pot primi fisiere de configurare diferite. Avantajul optiunii DHCP este ca ai ceva mai multa flexibilitate asupra locatiei in care se afla scriptul (inclusiv port).

2. DNS. Din ce am vazut pana acum, e cea mai populara metoda.

Metoda se bazeaza pe existenta inregistrarii WPAD in zona DNS din care face parte clientul. Sa luam exemplu in care calculatorul meu are setat ca primary DNS suffix zona domain.local. In momentul in care pornesc browserul, acesta va cauta inregistrarea DNS WPAD in zona domain.local (wpad.domain.local).

Mai exact va incerca sa downloadeze scriptul de aici: http://wpad.domain.local/wpad.dat. In caz ca nu reuseste va mai incerca:

http://wpad.local/wpad.dat 

Daca ierarhia mea DNS ar fi fost mai mare, ar fi existat mai multe cautari. In caz ca nu il gaseste browserul va functiona fara setarile proxy (sau cu cele specificate manual).

Atentie: optiunea DHCP 252 are prioritate in fata cautarii in DNS a inregistrarii WPAD.

 

Concluzia:  Automatic configuration bazat pe protocolul WPAD si PAC poate fi folosit pentru a schimba setarile de proxy ale sistemelor din retea indiferent ca acestea se afla intr-un domeniu Active Directory sau nu. (Active Directory chiar complica implementarea WPAD in unele scenarii single domain; in acest caz e recomandata folosirea GPO). Daca nu ai serverul cu scriptul WPAD, hostul in DNS sau optiunea in DHCP – DISABLE IT.

Cum schimbam TCP/IP settings cu netsh

Daca n-avem la indemana vreun vbscript si nu ne pricepem sa facem unul, ne putem descurca foarte usor si cu netsh.

Pentru a seta adresa IP statica folosim urmatoarea comanda :

netsh interface ip set address name=”Local Area Connection” static 192.168.1.10 255.255.255.0 192.168.1.1

Comanda necesara pentru a seta “preferred DNS server” este

netsh interface ip set dns “Local Area Connection” static 192.168.1.5

iar pentru “alternate DNS server” :

netsh interface ip add dns “Local Area Connection” 192.168.1.6

Daca folosim si WINS :

netsh interface ip set wins “Local Area Connection” static 192.168.1.6

Cum facem sa rulam toate aceste comenzi,sau o parte din ele, fara prea mult efort (asta e pentru lazy admins, ca mine): foarte simplu, deschidem un notepad, copiem toate comenzile dorite, fiecare pe cate o linie si salvam fisierul cu extensia bat. Cu un dublu click pe fisierul bat se vor rula local toate comenzile.

Pentru a trece de pe static pe dhcp e si mai simplu :

netsh interface ip set address “Local Area Connection” dhcp

iar pentru dns :

netsh interface ip set dns “Local Area Connection” dhcp

Si tot pentru lazy admins : cu psexec.exe (din PSTOOLS) putem modifica setarile TCPIP si de la distanta :

Ex:

psexec.exe \\computer netsh interface ip set address name=”Local Area Connection” static 192.168.1.10 255.255.255.0 192.168.1.1

sau :

Psexec.exe \\computer netsh interface ip set dns “Local Area Connection” dhcp

Sau putem rula comanda sau comenzile pe mai multe computere astfel:

Psexec.exe @computers.txt –c setari.bat

Computers.txt contine numele sau adresele IP ale computerelor vizate

Setari.bat contine comenzile pe care vrem sa le rulam. Se pot face diverse combinatii. Desigur, nu putem seta IP static la o lista de computere, sau nu stiu eu.

Ca sa fie mai usor, cele doua fisiere le copiem in acelasi folder cu psexec.exe, pentru a nu mai trebui specificata calea catre ele.

Desi cred ca stiti deja, va mai aduc si eu aminte ca rularea remote a comenzilor trebuie facuta cu credentialele unui user care are drepturi de administrator pe computerele vizate.

Sper sa fie de ajutor.

Microsoft November Security Updates – Review

 

Postul asta vine cam tarziu, insa mai bine mai tarziu decat niciodata. O sa incercam ca in viitor sa avem asa ceva pentru fiecare serie de update-uri de securitate scoase de Microsoft.

 

Bulletin No.	Description	Impact	Client Severity Rating	Server Severity Rating
MS09-063	Vulnerability in Web Services on Devices API Could Allow Remote Code Execution (973565)	Remote Code Execution	Critical	Critical
MS09-064	Vulnerability in License Logging Server Could Allow Remote Code Execution (974783)	Remote Code Execution	N/A	Critical
MS09-065	Vulnerabilities in Windows Kernel-Mode Drivers Could Allow Remote Code Execution (969947)	Remote Code Execution	Critical	Critical (depinde,explicam mai jos)
MS09-066	Vulnerability in Active Directory Could Allow Denial of Service (973309)	Denial of Service	N/A	Critical
MS09-067	Vulnerabilities in Microsoft Office Excel Could Allow Remote Code Execution (972652)	Remote Code Execution	Critical	Depinde
MS09-068	Vulnerability in Microsoft Office Word Could Allow Remote Code Execution (976307)	Remote Code Execution	Critical	Depinde

 

Primul din lista este MS09-063 care datorita unei vulnerabilitati in WSDAPI afecteaza Vista si 2008 Server (inclusiv Core). Se poate folosi Windows Firewall pentru a inchide porturile pe care asculta acest serviciu.

Urmatorul se refera numai la Windows 2000 server pentru ca afecteaza serviciul License Logging – credeam ca toata luma a oprit acest serviciu pana acum.

Si acum vine cireasa de pe tort, MS09-065, in care sunt mai multe probleme dar cea mai mare e ca datorita unor elemente din kernel care proceseaza fonturile, un atacator ar putea face remote remote code execution pe masina “victimei”. Trebuie totusi sa redirectioneze victima catre o pagina web in care are continut special facut pentru acest scenariu (e doar un mod, exista si altele). Aici putem comenta putin severity rating-ul pentru servere: daca nu browsezi de pe server, sansele sa fii afectat sunt minime. Windows 7 si 2008 R2 nu sunt afectate. Atentie ca exista probleme cu acest update. Check here: http://support.microsoft.com/kb/969947

PS: 2008 Server core e afectat si el 🙂

Urmatorul se refera strict la Active Directory, ADAM sau AD LDS, facand exceptie AD & AD LDS de pe Windows 2008 R2. Sfatul meu e sa testati update-ul si sa-l instalati.

Ultimele doua se refera strict la Office si sunt importante pe partea de client. Macuserii sunt afectati si ei. Pe servere, daca nu rulezi produsele descrise in buletin, nu esti afectat.

Tacamul complet il gasiti aici: http://www.microsoft.com/technet/security/bulletin/ms09-nov.mspx

 

Si acum cate putin din teoria conspiratiei: mi se pare suspect ca imediat dupa lansarea Windows 7 apar update-uri care sa demonstreze ca 7 & R2 sunt mult mai secure. Pai produsele astea erau in development de mult timp si au fost gata din vara. Daca producatorul a identificat problemele si le-a corectat in noile versiuni, de ce nu a scos patchurile in acel moment? La fel si cu BSOD-ul din SMBv2. E oare o strategie de marketing pentru a impinge clientii catre un anumit produs? Nu stiu, e doar un gand care mi-a venit acum in minte.

Insa un lucru e clar – http://isc.sans.org/diary.html?storyid=7573. Povestea de aici e pe bune si afecteaza numai Windows 7 si 2008 R2.  Indiferent ca dezactivati SMBv2 sau nu.

VMWare Player – alternativa la Virtual PC/XP Mode

 

Pentru cei ce nu stiau, exista si un frate mai mic al lui Workstation numit VMWare Player. Si e free. Pana de curand era foarte limitat deoarece nu aveai optiunea sa faci masini virtuale noi ci numai sa le rulezi. Ca workaround-uri existau diverse tool-uri pentru a genera fisierele de configurare si fisierele vmdk.

Noua versiune arata asa:

Adica s-a rezolvat cea mai mare problema 🙂

Suport de pana la 4proc pe VM si 32GB Ram.

Beneficiaza de multe din funtionalitatile lui Workstation, insa are si multe lipsuri – debugging, team, clone, nici snapshoturi nu am vazut. In schimb poti importa masina virtuala XP Mode si poti scapa de Virtual PC care arata cam asa:

Cel putin interfata e clar mai buna la VMWare decat la VPC. La inceput nu reauseam sa imi dau seama nici cum sa dau power off in VPC.

 

Si stie si de Unity 🙂

Download la: http://www.vmware.com/products/player/

Nu uitati nici de VMWare Appliances: http://www.vmware.com/appliances/