Windows 10 – WiFi Random Hardware Addresses
In Windows 10 tocmai am observat o noua optiune ce tine de privacy & security. Si anume Random Hardware Addresses.
Atentie ca aceasta optiune apare doar pe placile de retea WiFi suportate ce au aceasta functionalitate in driver:
In teorie, cineva ar putea sa urmareasca miscarile unui device pe baza adresei MAC. Dar daca device-ul schimba adresa MAC de fiecare data cand acceseaza o retea WiFi noua, atunci am scoate din ecuatie aceasta problema.
Odata conectat la o retea WiFi, sistemul de operara va tine minte adresa folosita si o va folosi si la urmatoarele conectari (util atunci cand accesul se face si pe baza adresei MAC).
Mai multe detalii puteti gasi in link-urile de mai jos:
http://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-on.html
https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf
Quest Migration Manager for AD – SIDHistory Mapping
O situatie intalnita cateodata in scenariile de migrare de Active Directory este atunci cand din diverse motive proiectul a fost intrerupt iar software-ul folosit pentru a migra obiectele din AD nu mai exista.
Cum continuam migrarea? Daca ar fi vorba doar de migrat obiecte din AD ar fi simplu, dar ce facem atunci cand migram servere si statii de lucru, unde trebuie sa procesam ACL-urile?
In mare, in procesul de migrare, cand un obiect este migrat din domeniul sursa in domeniul target, undeva intr-o baza de date a soft-ului de migrare se stocheaza informatii ce leaga obiectul din sursa de obiectul din target. Un exemplu foarte simplu ar fi ceva gen: SID-ul X din Domeniul A corespunde cu SID-ul Y din Domeniul B. Iar in momenul in care ne apucam sa procesam un server sau o statie de lucru softul de migrare o sa inlocuiasca SID-ul X cu SID-ul Y. Asta asa in mare.
Dar ce faci cand baza aia de date cu informatiile astea de matching nu mai exista?
Singura solutie pe care o cunosc este prin a folosi Quest Migration Manager for AD. Si functioneaza chiar si daca prima parte a migrarii a fost facut cu un alt software, chiar si ADMT. Conditia este sa se fi folosit SID History in migrare (si de regula este folosit).
Agentul folosit de Quest pentru a procesa ACL-urile de pe sisteme se numeste Vmover si este parte a RUM (Resource Update Manager). Acesta foloseste un mapping file (vmover.ini) ce contine SID-urile sursa si target. Cand agentul intalneste un ACE cu un user din sursa intr-un ACL, il modifica pe baza informatiilor din acel mapping file cu userul din domeniul target.
In cazul nostru, fisierul vmover.ini generat nu va avea informatiile necesare pentru translatarea permisiunilor, dar folosind optiunea SIDHistory Mapping, putem spune agentului sa caute informatiile necesare in domeniul target.
In fisierul vmover.ini se afla si cateva informatii de configurare. Acolo va trebui specificat SIDHistory=Yes si detaliile de conectare la DC exact ca in articolul de mai jos:
Odata setata aceasta optiune, cand Vmover va intalni un user din domeniul sursa setat pe o resursa, ii va obtine SID-ul, se va conecta la domeniul target, va cauta prin toate valorile SID History si asa va localiza userul din domeniul target ce corespunde cu userul din domeniul sursa. Informatia asta va fi adaugata in fisierul vmover.ini, astfel ca data urmatoare cand intalneste acest user intr-un ACL, procesul de translatare va fi super rapid.
Alte cateva resurse pe aceasta tema gasiti in link-urile de mai jos:
https://support.software.dell.com/migration-manager-for-ad/kb/85365
https://documents.software.dell.com/snippets/PrintableVersion.ashx?id=1027
How to purge Kerberos tickets for a different session using KLIST
Cam orice admin cu experienta ar trebui sa stie cum functioneaza Kerberos si de existenta utilitarului KLIST. In ultimele versiuni de Windows nu mai trebuie instalat nimic, este deja livrat cu sistemul de operare. Pentru cei ce nu sunt familiari, o sa amintesc scenariul clasic in care adaugi un user intr-un grup ce ii da acces la o resursa (sa zicem file share), dar accesul nu functioneaza decat daca userul face logoff/logon. Iar asta se intampla pentru ca in ticketul Kerberos nu exista si SID-ul noului grup, asta fiind motivul pentru logoff/logon (refresh). Asta asa foarte pe scurt si fara prea multe detalii tehnice.
Sa revenim la KLIST. Cu acest tool puteti face refresh la ticketele TGT/TGS si astfel sa updatati group membershipul in timp real fara a mai fi nevoie de logoff/logon. Ca o nota separata, refresh-ul la ticketele Kerberos nu rezolva toate probleme de acces, dar in multe cazuri se pare ca functioneaza. Documentatia oficiala a tool-ului o gasiti aici:
https://technet.microsoft.com/da-dk/windows-server-docs/management/windows-commands/klist
In documentatie si mai peste tot pe internet este prezentat cazul in care faci renew la sesiunea curenta sau la computer account-ul local. Dar sunt scenarii in care ai nevoie sa faci refresh la cache-ul unui serviciu sau al unui alt cont logat pe sistem.
Pentru contul curent comanda este:
klist purge
Iar pentru local system account:
klist –li 0:0x3e7 purge
Ambele comenzi trebuiesc rulate dintr-un shell elevat. 0x3e7 reprezinta ID-ul contului localsystem. Pentru a face refresh la alte conturi, trebuie sa aflam ID-ul.
Incepand cu Windows 2012/8 puteti afla ID-ul tot cu KLIST:
klist sessions
Mai departe puteti accesa o alta sesiune folosind ID-ul, ca in exemplul de mai jos:
In caz ca rulati pe ceva mai vechi de Windows 2012/8 va fi nevoie de powershell si WMI. Ca sa nu mai reinventez roata, exista deja comanda in Powershell aici:
https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=56
gwmi Win32_LogonSession | % { $one = $_ ; $one.GetRelated(‘Win32_Account’) | Select Domain, Name, SID, @{ n = ‘LogonSessionHEX’ ; e = { ‘0x{0:X}’ -f ([int] $one.LogonId) } }, @{ n = ‘LogonSessionDEC’ ; e = { $one.LogonId } } , @{ n = ‘LogonType’ ; e = { $one.LogonType } } }
Output-ul arata ceva de genul asta:
Mai departe puteti filtra dupa o sesiune a unui anume user, sau dupa tipul sesiunii, folosind LogonType. Pe acestea le gasiti explicate aici: http://www.windowsecurity.com/articles-tutorials/misc_network_security/Logon-Types.html
De exemplu sesiunile RDP vor avea Logon Type 10 si serviciile vor avea Logon Type 5. Pentru a filtra dupa tipul sesiunii adaugati urmatoarele la comanda de mai sus: |? {$_.LogonType -eq 10}
Sau |? {$_.LogonType -eq 10} daca ne uitam dupa servicii:
Sau folosind |? {$_.Name -eq "aungureanu"} putem filtra dupa numele user-ului. Inlocuiti aungureanu din exemplul meu cu numele user-ului dorit:
Nota: in exemplul de mai sus puteti vedea doua sesiuni de acelasi tip (RDP) pentru acelasi user. Asta se intampla datorita UAC; fiecare user are doua tickete, unul limitat si altul elevat. Cu exceptia administratorului builtin care by default primeste doar un token elevat.
Tineti minte: KLIST si refreshul la ticketele Kerberos nu rezolva toate problemele de autentificare. Tot Logoff/Logon este recomandat. KLIST este doar un workaround pentru situatii urgente.
Auditing Special Groups in Windows
Special Groups este o functionalitate prezenta in Windows incepand cu 2008/Vista si de care am uitat sa scriu pana acum. Dar nevoia m-a facut sa ajung sa folosesc asa ceva recent, asa ca a fost nevoie sa imi amintesc.
Ca sa fac un rezumat al functionalitatii. Special Groups iti ofera posibilitatea de a detecta cand membrii unui anumit grup se logheaza si unde. Nu exista un grup anume, numit Special Groups. Tu definesti ce si unde auditezi. Pasii necesari ca sa faci asta:
1. Audit Logon/Logoff Special Logon – by default activat incepand cu Windows Server 2008/Vista
2. Un grup in care sa adaugi userii pe care vrei sa ii monitorizezi (poate fi grup din Active Directory sau local)
3. SID-ul grupului respectiv adaugat in registry pe masinile ce vor fi monitorizate, in urmatoarea locatie:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Audit\SpecialGroups
Nota: In exemplul de mai sus am adaugat SID-ul grupului Administrators (este un SID Well Known – adica e acelasi pe orice sistem)
Nota 2: Mai multe SID-uri pot fi adaugate, delimitate prin ;
Odata configurat, data viitoare cand un user ce face parte din grupul cu SID-ul adaugat in registry se va loga pe sistemul respectiv, Event ID 4964 va fi logat in Security Log:
Va las pe voi sa va ganditi cum faceti deployment la setarile in registry si ce grupuri sa monitorizati dar va dau si cateva example de scenarii cand puteti folosi Special Groups:
– detectarea conturilor de Domain sau Enterprise Admin ce se logheaza acolo unde nu ar trebui. De exemplu pe enduser workstations. Puteti seta monitorizarea special groups pe statiile de lucru, ori adaugand SID-ul acestor grupuri in registry pe statii, ori adaugand userii DA/EA intr-un grup special definit pentru monitorizare.
– detectarea cazurilor cand cineva se logheaza ca Admin local pe anumite statii sau servere
– identificarea masinilor unde anumite service accounts sunt folosite (in multe cazuri am vazut service accounturi lasate active doar pentru ca nimeni nu mai stie unde sunt folosite)
Dar bineinteles ca toate scenariile de mai sus necesita si un sistem bine pus la punct de colectare a logurilor de pe sistemele respective. Da, chiar si de pe statii. Nu mai este ceva anormal in ultimul timp.
Mai jos aveti si link-ul catre KB-ul oficial cu descrierea Special Groups:
https://support.microsoft.com/en-us/kb/947223
Again about troubleshooting AD Powershell queries – This operation returned because the timeout period expired,Microsoft.ActiveDirectory.Management.Commands.GetADUser
I was previously writing about some timeouts when getting data from Active Directory using Powershell cmdlets. Another thing that usually pops up when dealing with large amounts of data in AD is a default timeout of 2 minutes for each page search. This means that the time spend by the server to retrieve a page of results can’t take longer than 2 minutes. So in order to get rid of this error you’ll probably need to adjust the page size using the ResultPageSize parameter. Set that to a lower value so that the server can fill up a page and return it to you faster. Another way will be to improve your filter or target specific objects or OUs so that the amount of data searched is smaller.
The Powershell help also have some good comments about this:
Timeout Behavior
The following statements specify timeout conditions within the Active
Directory module and describe what can be done about a timeout them.
The default Active Directory module timeout for all operations is 2
minutes.
For search operation, the Active Directory module uses paging control
with a 2-minute timeout for each page search.
Note: Because a search may involve multiple server page requests the
overall search time may exceed 2 minutes.
A TimeoutException error indicates that a timeout has occurred.
For a search operation, you can choose to use a smaller page size, set
with the ResultPageSize parameter, if you are getting a TimeoutException
error.
If after trying these changes you are still getting a TimeoutException
error, consider optimizing your filter using the guidance in the
Optimizing Filters section of this topic.
Optimizing Filters
You can enhance the search filter behavior by using these guidelines.
Avoid using the Recursive parameter as it intensifies resource usage of
the search operation.
Avoid using bitwise AND operators and bitwise OR operators. For more
information, see the Supported Operators section of this topic.
Avoid using the logical NOT operator.
Break down your search into multiple queries with narrower conditions.
https://technet.microsoft.com/en-us/library/hh531527(v=ws.10).aspx
Also check the ADWS docs on how to change the MaxPullTimeout timeout value:
Specifies the maximum allowed time-out value that a client computer can set when it retrieves one page of search results. Set this parameter to a higher value if slow wide area network (WAN) traffic results in a time-out value for returning one page of search results that is longer than two minutes
Note
The ADWS service processes search requests from client computers in the following manner:
A client submits a search request.
The ADWS service establishes a search context and returns a search context ID to the client computer.
Using this search context ID, the client computer issues a page request to extract the search results specifying how many LDAP objects can be returned per page.
MaxPullTimeout controls the maximum amount of time a client can ask the ADWS service to spend retrieving a page of results, while MaxEnumContextExpiration is the maximum time that the search context can be kept open.
https://technet.microsoft.com/en-us/library/dd391908(v=ws.10).aspx
And if you still don’t understand what a “page” is, here’s the MSDN documentation:
https://msdn.microsoft.com/en-us/library/aa367011(v=vs.85).aspx
Hope this makes everything clear and some of you will be able to fix their problematic queries.
How to restart graphics driver on Windows 10
Un shortcut de care am auzit recent si care functioneaza pe Windows 10 este LSHIFT+LCTRL+WIN+B. Se pare ca aceasta combinatie de taste initiaza restartul driverului video iar din ce am testat sistemul se comporta ca si cum ar restarta driverul video. Totusi nu exista nici o urma prin loguri despre ceea ce se intampla in spate.
Oricum merita retinut pentru situatiile in care exista o problema cu driverul video iar sistemul nu mai afiseaza nimic.
Visual Studio for Mac
Cineva cred ca a facut anuntul cam devreme, pentru ca la scurt timp fusese sters. Noroc ca pagina mai exista in cache.
Forget about the old pagefile, Windows 10 memory compression is here.
Memory compression nu e ceva chiar atat de nou si am vazut tehnica asta folosita si in alte produse, nu numai Windows cu mult inainte de Windows 10. De fapt in Windows totul a inceput cu Windows 7 si Ready Boost. Chestia e ca tehnologia s-a maturizat si modul in care functioneaza Memory Manager-ul in Windows s-a schimbat treptat, compresia a inceput sa fie folosita din ce in ce mai agresiv, iar utilizarea page file-ului s-a diminuat semnificativ.
Tineti minte ca parca din cand in cand vine cate o versiune de Windows care ruleaza mai rapid decat vechea versiune, pe acelasi hardware? Ei bine, genul asta de optimizari fac posibila aceasta crestere de performanta. Si mi se pare foarte important sa stim cum evolueaza tehnologia si cum noile sisteme de operare folosesc resursele hardware.
Dupa cum am spus, nu este ceva nou doar ca Microsoft a implementat treptat aceasta tehnologie si parca abia acum in Windows 10 se vad cu adevarat beneficiile. Pe scurt, ce se intampla cu paginile de memorie nefolosite ce apartin unui proces? Memory Managerul face o inspectie, le trece pe un Modified List si in momentul in care are timp si resurse le trimite intr-o noua locatie numita Compression Store. Dupa cum ati ghicit, acest Compression Store se afla in memorie, deci toate operatiunile de read/write sunt incredibil de rapide. Ganditi-va ca a preluat rolul pagefile-ului, dar in RAM si pe deasupra mai este si comprimat, adica ocupa mult mai putin spatiu.
In continuare mai exista si pagefile-ul normal, si cu toata compresia din memorie se poate ajunge la situatii cand resursele sunt atat de limitate incat nu mai exista loc in RAM. In cazul asta datele din compression store pot ajunge in page file-ul de pe disk, dar tot comprimate, adica mult mai putine operatiuni de I/O cu disk-ul.
Nota: In realitate e ceva mai complicat de atat si se intampla mult mai multe lucruri, dar sper ca am reusit sa rezum esentialul (nu cred ca intereseaza pe nimeni ca pot exista mai multe compression store-uri sau ca si paginile de memorie ale compression store-ului pot ajunge in modified list).
Iar daca nu ati observat in ultimele build-uri de Windows cand va uitati in task manager gasiti si o referinta la “compressed”:
Deci ce vedeti ca fiind in use, reprezinta memoria folosita activ de procese si drivere, plus ce se afla in compression store. Iar daca va duceti cu mouse-ul pe zona folosita de memorie din grafic veti vedea si cat anume din acea valoare este reprezentata de compression store. Pana la anumite builduri de Windows 10, in task manager, in lista de procese exista “System and compressed memory” si toata lumea tipa ca de ce “System” ocupa atat de multa memorie si cauta moduri sa dezactiveze acest mod de operare. Ce pot sa spun? Tehnici de cartier, de aprozar, pentru cei ce nu inteleg schimbarile din noul OS. “System” parea ca ocupa atat de mult pentru ca acel Compression Store rula in contextul System 
.
Din Windows 10 Anniversary Edition, lucrurile s-au schimbat legat de modul in care e afisata informatia in Task Manager iar datele despre Compression Store nu le mai vedeti in lista de procese. In schimb puteti rula din Powershell urmatoarea comanda:
Get-Process –Name “Memory compression”
Normal, valoarea de aici de la Working Set (WS) trebuie sa corespunda cu ce vedeti mai sus in interfata grafica din Task Manager. Doar ca eu am rulat comanda la ceva timp dupa ce am facut screenshot-ul de mai sus si datele s-au schimbat semnificativ.
Una peste alta, toate chestiile astea combinate aduc un plus enorm de performanta sistemului si nu mai e doar marketing ci se vede in lucrul de zi cu zi cand folosesti un astfel de OS.
Daca ma intrebati de Windows Server 2016, din ce am observat eu pana acum, Memory Compression nu este folosit si nici nu am gasit nimic pana acum despre viitorul acestei functionalitati in Windows Server. Cred ca totusi este doar o problema de timp pana cand tehnologia se va roda putin si abia apoi o vom vedea la lucru si pe platformele de tip server.
Google Cloud Platform, EC2 and Windows Server 2016
Citisem anuntul recent al celor de la Google despre disponibilitatea Windows Server 2016 in Google Cloud Platform (GCP) si surpriza a fost sa aflu ca iti dau si 300$ trial credit sa ii cheltuiesti in primele 60 de zile. Si nu pare a fi o capcana in care iti dai cardul si dupaia te trezesti ca ai de plata cine stie ce sume:
Sper totusi sa se tina de cuvant.
Interfata necesita putin timp de acomodare dar nu e un show stopper.
Si pentru ca am scris in titlu si EC2, gasiti acum Windows 2016 si pe Amazon EC2:
https://aws.amazon.com/about-aws/whats-new/2016/10/amazon-ec2-now-supports-windows-server-2016/
Insa nu am auzit de nici o oferta de genul celei de mai sus.
Cred ca e un moment bun acum sa testati GCP si Windows 2016 in acelasi timp.
Intro to handling errors in Powershell–default variables
In majoritatea cazurilor, adminii nu prea ajung in zona de error handling, pentru ca multe din interactiunile cu Powershell se rezuma la a compune comenzi intr-o singura linie iar errorile le trateaza ad hoc.
Dar chiar si atunci e bine sa stii cate ceva despre mecanismele din Powershell care te pot ajuta. Cel mai simplu examplu ar fi cazul in care am dori sa listam toate erorile aparute in sesiunea curenta de powershell (poate ca cineva a rulat CLS pentru a-si ascunde urmele si ne lasa pe noi sa ne chinuim fara sa ne spuna rezultatul incercarilor lui).
In fiecare sesiune erorile sunt stocate automat intr-o variabila default numita $error. Ca exemplu incerc sa import un modul inexistent:
Pasul urmator este sa sterg consola ruland CLS. Dar ruland $error, pot vedea mesajul de eroare aparut mai devreme si orice alt mesaj de eroare aparut in sesiunea curenta:
$error este un array ce by default este setat sa stocheze pana la 256 de intrari. Ultima intrare in array poate fi accesata cu $error[0]:
Dimensiunea maxima a $error poate fi vazuta si modificata prin variabila default $MaximumErrorCount:
Pentru a vedea cate erori sunt stocate pentru sesiunea curenta apelam $error.count:
Iar pentru a sterge orice urma de erori folosim $error.clear():
De retinut ca este important ca la finalul unui script sa poti verifica daca au aparut erori, eventual sa le salvezi si foarte important sa stergi continutul variabilei $error, pentru ca la o executie urmatoare sa capturezi doar erorile aparute ca urmare a ultimei executii si nu tot ce aparut pana atunci.
Si tot in aceasta categorie mai exista o variabila ce trebuie retinuta si anume $LastExitCode. Aceasta variabila este importanta pentru cand apelam comenzi sau scripturi externe si stocheaza codul de erorare returnat de comanda apelata. Stim ca trebuie sa fie 0 pentru o executie cu succes. Orice e diferit de 0 poate reprezenta o problema. Nota: In propriile scripturi putem seta codul returnat la exit.
Iata de exemplu o insiruire de comenzi in care incerc sa opresc servicii folosind NET START/STOP:
Observati ca la inceput variabila $lastexitcode este neinitializata, apoi ia valoarea zero iar mai tarziu se schimba in 2 cand incerc sa pornesc un serviciu inexistent.
Cam atat in acest scurt intro si sper sa va ajute si sa va dea idea despre cum puteti monitoriza si observa erorile din sesiunile sau scripturile Powershell.